The DAP has a completion request that has been unimplemented. It allows showing autocompletion tokens inside the Debug Console.
I implemented it in a very simple fashion mimicking what the user would see when autocompleting an expression inside the CLI.
There are two cases: normal variables and commands. The latter occurs when a text is prepepended with ` in the Debug Console.
These two cases work well and have tests.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 40581 Build 40699: arc lint + arc unit
Event Timeline
lldb/tools/lldb-vscode/lldb-vscode.cpp | ||
---|---|---|
948 | max_return_elements isn't implemented, so you can just pass '-1' here. This also means you probably want to manually resize the results to no be longer than 20. | |
955 | I am not sure how VSCode works, but you probably should be aware that the results from HandleCompletionWithDescriptions are expected to replace the current token. Token is in LLDB is just a string as a list of unescaped non-quote non-whitespace characters, where the quotes are not part of the token (and will not be included in the match string you get back). You can also quote every argument in LLDB, so completions in quotes can happen everywhere. Some test that might bug out VSCode are for example "com[tab] 'com[tab] settings "se[tab] settings 'se[tab] Also the completions you get back from LLDB are *usually* complete tokens (e.g, you can safely add a space character behind for the user), but the exception to this are file paths (where we only complete the current directory). This isn't really exposed in `HandleCompletionWithDescriptions, you can't really know if adding a space is correct or not. Anyway, just be aware that if VSCode adds a trailing space to the completions, this might give wrong results for file paths. Also you can get completions in the print/expression command (where users can freely use quotes and whitespaces) which means you can get really weird situations like this: expr "";typed[tab] -> "";typedef (at least, I believe that's what we return). I think this is currently also broken in LLDB, so it might not be a big issue as long as VSCode does anything reasonable when it gets weird matches like that. |
removed the results limit of 20 because it didn't work and I verified that returning a long list is displayed well on vscode. There's no need for this limit at this point.
I also tested the cases that @teemperor mentioned and all of them work on vscode. I also added them as test cases.
Fortunately, the way completions are represented inside LLDB are exactly the same as what vscode expects
Maybe limit the matches if posssible if that works. If you type "target variable <tab>" you can complete a list of all global variables everywhere which might be quite a few.
max_return_elements isn't implemented, so you can just pass '-1' here. This also means you probably want to manually resize the results to no be longer than 20.