[Lldb-commits] [PATCH] D69873: [lldb-vscode] support the completion request

[Raphael Isemann via Phabricator via lldb-commits]

teemperor added inline comments.


================
Comment at: lldb/tools/lldb-vscode/lldb-vscode.cpp:948
+    actual_column,
+    0, 20, matches, descriptions);
+  targets.reserve(matches.GetSize());
----------------
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.


================
Comment at: lldb/tools/lldb-vscode/lldb-vscode.cpp:955
+    llvm::json::Object item;
+    EmplaceSafeString(item, "text", match);
+    if (description.empty())
----------------
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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69873/new/

https://reviews.llvm.org/D69873