Page MenuHomePhabricator

[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values

Authored by teemperor on Aug 21 2019, 7:43 AM.



We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers

  • The return values (int/size_t) in all completion functions.
  • Our result array that starts indexing at 1.
  • WordComplete mode.

I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.

A few words why those things should be removed/replaced:

  • The return values are really cryptic, partly redundant and rarely documented. They are also completely ignored by Xcode, so whatever information they contain will end up breaking Xcode's completion mechanism. They are also partly impossible to even implement as we assign negative values special meaning and our completion API sometimes returns size_t.

    Completion functions are supposed to return -2 to rewrite the current line. We seem to use this in some untested code path to expand the history repeat character to the full command, but I haven't figured out why that doesn't work at the moment. Completion functions return -1 to 'insert the completion character', but that isn't implemented (even though we seem to activate this feature in LLDB sometimes). All positive values have to match the number of results. This is obviously just redundant information as the user can just look at the result list to get that information (which is what Xcode does).
  • The result array that starts indexing at 1 is obviously unexpected. The first element of the array is reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is that we calculate this to make the life of the API caller easier, but obviously forcing people to have 1-based indices is not helpful (or even worse, forces them to manually copy the results to make it 0-based like Xcode has to do).
  • The WordComplete mode indicates that LLDB should enter a space behind the completion. The idea is that we let the top-level API know that we just provided a full completion. Interestingly we WordComplete is just a single bool that somehow represents all N completions. And we always provide full completions in LLDB, so in theory it should always be true. The only use it currently serves is providing redundant information about whether we have a single definitive completion or not (which we already know from the number of results we get).

This patch essentially removes WordComplete mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do addCompletion("blub", "description", CompletionMode::RewriteLine)
to do the same.

For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).

I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits

Diff Detail


Event Timeline

teemperor created this revision.Aug 21 2019, 7:43 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 21 2019, 7:43 AM
teemperor updated this revision to Diff 216398.Aug 21 2019, 7:45 AM
  • Add comment that we emulate the old API by adding the common prefix as element 0.
teemperor marked an inline comment as done.Aug 21 2019, 7:47 AM
teemperor added inline comments.
1847 ↗(On Diff #216398)

Note that I moved this code to SBCommandInterpreter::HandleCompletionWithDescriptions (as it adds the common prefix in element 0).

JDevlieghere accepted this revision.Aug 21 2019, 9:38 AM

Thanks for cleaning this up, Raphael!

379 ↗(On Diff #216398)

Maybe add that this is here to emulate old behavior that our clients rely on.

This revision is now accepted and ready to land.Aug 21 2019, 9:38 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptAug 22 2019, 12:44 AM