[CodeCompletion] Migrate labeled trailing closure completions to solver-based #68075
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ahoppen
requested review from
bnbarham,
rintaro,
hamishknight,
CodaFi and
DougGregor
as code owners
ahoppen
force-pushed
the
ahoppen/labeled-trailing-closure-solver-based
branch
2 times, most recently
from
4733bc1 to
b48ee42
Compare
|
@swift-ci Please smoke test |
|
@swift-ci Please SourceKit stress test |
bnbarham
reviewed
Aug 23, 2023
lib/IDE/ArgumentCompletion.cpp
Outdated
| ->lookThroughAllOptionalTypes() | ||
| ->is<AnyFunctionType>()) { | ||
| // We are completing an argument after the first trailing closure, i.e. | ||
| // a mulitple trailing closure label but the parameter is not a function |
|
Note to self: The stress tester hit 4 new timeouts, which we are accepting because of the improvements this brings and because it unblocks #68080, which deletes a huge amount of code. |
ahoppen
force-pushed
the
ahoppen/labeled-trailing-closure-solver-based
branch
from
b48ee42 to
2b4c3bc
Compare
hamishknight
approved these changes
Aug 24, 2023
Comment on lines
86
to
88
| if (IdealType.isNull() != Other.IdealType.isNull()) { | ||
| IdealType = Type(); | ||
| } else if (IdealType && Other.IdealType && | ||
| !IdealType->isEqual(Other.IdealType)) { | ||
| IdealType = Type(); | ||
| } |
There was a problem hiding this comment.
Nit: Seems like this could be reduced to !IdealType || !Other.IdealType || !IdealType->isEqual(Other.IdealType)
…onsumer phase This will allow us to run two different completion kinds and deliver results from both of them. Also: Compute a unified type context for global lookup. Previously, we always used the expected type context of the last lookup. But really, we should be considering all possible types from all constraint system solutions when computing code completion results from the cache.
…er-based rdar://113472967
ahoppen
force-pushed
the
ahoppen/labeled-trailing-closure-solver-based
branch
from
2b4c3bc to
48ce1b3
Compare
|
@swift-ci Please smoke test |
|
@swift-ci Please test Windows |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In a first commit, I split
deliverResultsinto acollectResultscall that gathers all the code completion results and thentrySolverCompletionis responsible for delivering the results to the code completion consumer.When we are performing code completion after a call that already has a trailing closure, we first perform the normal postfix completion, which will give us results for operators and member access. We then rewrite the call slightly to include the code completion token as an additional argument, and run argument completion on it. This gives us the completion for the trailing closure label. Once we have collected the results from both completion kinds, we deliver them to the consumer
As a little side-quest, I realized that when computing the code completion results from the cached modules, we were always using the type context of the last lookup that we performed. I changed that slightly to compute a unified type context that contains all possible types from all constraint system solutions. We then use that unified type context to compute the type relations of the global results – this didn’t change any tests.
Oh, and one more thing: When completing after
Void, we were providing==,<=etc operators that are defined on tuples. These also showed up when completing trailing closure labels of a call that returnsVoid. Since they are never useful, I now hide operators from code completion if the left-hand-side isVoid.rdar://113472967