This is an archive of the discontinued LLVM Phabricator instance.

Narrow the CompletionRequest API to being append-only.
ClosedPublic

Authored by teemperor on Jul 13 2018, 2:42 PM.

Details

Summary

We currently allow any completion handler to read and manipulate the list of matches we
calculated so far. This leads to a few problems:

Firstly, a completion handler's logic can now depend on previously calculated results
by another handlers. No completion handler should have such an implicit dependency,
but the current API makes it likely that this could happen (or already happens). Especially
the fact that some completion handler deleted all previously calculated results can mess
things up right now.

Secondly, all completion handlers have knowledge about our internal data structures with
this API. This makes refactoring this internal data structure much harder than it should be.
Especially planned changes like the support of descriptions for completions are currently
giant patches because we have to refactor every single completion handler.

This patch narrows the contract the CompletionRequest has with the different handlers to:

  1. A handler can suggest a completion.
  2. A handler can ask how many suggestions we already have.

Point 2 obviously means we still have a dependency left between the different handlers, but
getting rid of this is too large to just append it to this patch.

Otherwise this patch just completely hides the internal StringList to the different handlers.

The CompletionRequest API now also ensures that the list of completions is unique and we
don't suggest the same value multiple times to the user. This property has been so far only
been ensured by the Option handler, but is now applied globally. This is part of this patch
as the OptionHandler is no longer able to implement this functionality itself.

Diff Detail

Repository
rL LLVM

Event Timeline

teemperor created this revision.Jul 13 2018, 2:42 PM
teemperor added a reviewer: davide.
teemperor updated this revision to Diff 155515.Jul 13 2018, 3:30 PM
  • Removed some small string allocations.
davide added inline comments.
source/Commands/CommandCompletions.cpp
251–261 ↗(On Diff #155515)

Can you please merge these two functions? They're pretty much the same.

source/Commands/CommandObjectMultiword.cpp
378 ↗(On Diff #155515)

I'm not sure not calling Clear here is correct.

source/Interpreter/Options.cpp
731–741 ↗(On Diff #155515)

Why did you remove this code?

teemperor marked an inline comment as done.Jul 25 2018, 2:41 PM
teemperor added inline comments.
source/Commands/CommandObjectMultiword.cpp
378 ↗(On Diff #155515)

Not calling Clear could only influence the results if the Clear previously deleted existed completions from the list (which from what I can tell never happens and if would be a bug). It's most likely just a failsafe because we return 0 from this function (which has the match the size of match array).

source/Interpreter/Options.cpp
731–741 ↗(On Diff #155515)

The AddCompletion is already checking for duplicates, so this code becomes redundant. Actually, the only reason AddCompletion is checking for duplicates is to make this code redundant (as one can't implement duplicate filtering without read access to the match list, which we removed in this patch).

teemperor updated this revision to Diff 157368.Jul 25 2018, 2:41 PM
  • Addressed Davide's comments.
teemperor updated this revision to Diff 157370.Jul 25 2018, 2:42 PM

(Added small refactoring I forgot to add to the diff).

The patch makes sense to me, though I can't say I'm that familiar with this code.

The thing I'd really like to get rid of is the need to have return request.GetNumberOfMatches(); everywhere, but that's a fight for another day..

include/lldb/Utility/CompletionRequest.h
88–93 ↗(On Diff #157370)

Slightly shorter and more efficient:
if (m_match_set.insert(completion).second) m_matches->AppendString(completion);

  • Rebased and fixed merge conflicts.
  • Applied Pavel's suggestion for the duplicate filter (thanks!).
davide accepted this revision.Jul 27 2018, 11:26 AM

Although I'm not entirely sure whether this is safe (as in, it doesn't break anything), it's probably not worth to block this further. My understanding is that Raphael did a bunch of testing and he's willing to follow-up on eventual regressions. So, given this passes the test suite, I think it's OK for this patch to go in.

This revision is now accepted and ready to land.Jul 27 2018, 11:26 AM
This revision was automatically updated to reflect the committed changes.