[SourceKit] Compute code completion type relation when wrapping a ContextFreeCodeCompletionResult in a CodeCompletionResult #40999
Conversation
|
@swift-ci Please smoke test macOS |
…evel type Preliminary work to compute the type relation when constructing a contextual code completion result.
ahoppen
force-pushed
the
pr/compute-type-relation-in-contextual-result
branch
from
e07dfff to
35cbe87
Compare
|
@swift-ci Please smoke test |
|
|
||
| /// The context in which this completion item is used. Used to compute the | ||
| /// type relation to \c ResultType. | ||
| ExpectedTypeContext TypeContext; |
There was a problem hiding this comment.
Copying ExpectedTypeContext is not trivial. Could you use a reference?
There was a problem hiding this comment.
Not super easily. If setResultTypes was never called, we don’t have a TypeContext. Currently, it just defaults to an empty ExpectedTypeContext. We could make this a pointer but this also means that we need to accept a pointer in the CodeCompletionResult initializer, which, I think, makes that API worse.
There was a problem hiding this comment.
We could make this a pointer but this also means that we need to accept a pointer in the CodeCompletionResult initializer
Can we dereference the pointer when calling CodeCompletionResult constructor?
That being said, I now feel like the ideal solution is that CodeCompletionResultBuilder only build ContextFreeCodeCompletionResult. Then, after collecting all context free results including cached results, we can loop through them to construct contextual CodeCompletionResults using ExpectedTypeContext and DeclContext.
There was a problem hiding this comment.
Ah, I just thought about it again and figured out it’s better to pass ExpectedTypeContext around using pointers instead of references anyway to match the fact that we are also using DeclContext * and not DeclContext &.
…textFreeCodeCompletionResult in a CodeCompletionResult [CodeCompletion] Make ExpectedTypeContext a class with explicit getters/setters This simplifies debugging because you can break when the possible types are set and you can also search for references to `setPossibleType` to figure out where the expected types are being set.
ahoppen
force-pushed
the
pr/compute-type-relation-in-contextual-result
branch
from
f078254 to
6bc0de9
Compare
|
@swift-ci Please smoke test |
This is the last refactoring before we can start computing type relations for global results from the code completion cache.