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