This change will bring lldb-vscode in line with how several other llvm tools process command line arguments and make it easier to add future options.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 46856 Build 49510: arc lint + arc unit
Event Timeline
Assuming this looks good, can I get some pointers on how and where I should add a test for this?
I based this change on the one for the LLDB driver (https://reviews.llvm.org/D54692) which added lldb/trunk/lit/Driver/TestCommands.test. Should I look into adding something similar or should I be using lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py and adding something in lldb/test/API/tools/lldb-vscode?
This is what the output for help looks like:
~/llvm-project ❯❯❯ build/Debug/bin/lldb-vscode --help [INSERT]
OVERVIEW: LLDB VSCode
USAGE: lldb-vscodeoptions
OPTIONS:
-g Alias for --wait-for-debugger
--help Prints out the usage information for the LLDB debug adapter tool.
-h Alias for --help
--port <port> What port to listen on.
-p <value> Alias for --port
--wait-for-debugger Pause the program at startup.
EXAMPLES:
The debug adapter can be started in two modes.
Running lldb-vscode without any arguments will start communicating with the
parent over stdio. Passing a port number causes lldb-vscode to start listening
for connections on that port.
lldb-vscode -p <port>
Passing --wait-for-debugger will pause the process at startup and wait for a
debugger to attach to the process.
lldb-vscode -w
%- Rename opts to options to be consistent with the lldb driver and add a test case around setting an invalid port.
I added the test file but atm the two existing arguments (--wait-for-debugger and --port) will cause lldb-vscode to hang and await some sort of action from an external process causing the test runner to hang. I added a single test case for handling an invalid port since that will cause the process to exit immediately but not certain on how to handle the other cases.
I think for these particular cases it's sufficient to check the help output and make sure the flags are there.
yeah just test for the options themselves in the help output. --wait-for-debugger is only when you need to debug lldb-vscode's initial packets with a debugger, so it is not a user facing argument. We might choose to hide this option by default. I know LLVM option parsing can do this.
- Update ldb-vscode options test to simply look for the expected flags when passing the --help option.
| lldb/test/Shell/VSCode/TestOptions.test | ||
|---|---|---|
| 8 | Missing newline | |
Thanks for the guidance!
When there are no additional concerns, would someone mind committing this change for me? I don't have commit access.
Missing newline