Switch to using `hasAppliedSelf` to match the constraint system, and
flip the check to more accurately describe what we're checking which
is really "is application fully applied"?
Previously we could end up in cases where we pick the wrong
DeclContext in `TypeCheckASTNodeAtLocRequest` since we previously
weren't checking source ranges, which could result in skipping the
type-checking of an outer closure. Now that we correctly pick the
DeclContext, we should no longer hit that case, so we should be able
to fall into `getTypeForCompletion` and assert that the solution has
a type. Also while here let's upgrade that assert to a
`CONDITIONAL_ASSERT`.
FunctionRefKind was originally designed to represent
the handling needed for argument labels on function
references, in which the unapplied and compound cases
are effectively the same. However it has since been
adopted in a bunch of other places where the
spelling of the function reference is entirely
orthogonal to the application level.
Split out the application level from the
"is compound" bit. Should be NFC. I've left some
FIXMEs for non-NFC changes that I'll address in a
follow-up.
Local functions can capture variables from parent
closures, so we need to make sure we type-check
parent closures when doing completion in a local
function. Ideally we ought to be able to be more
selective about the elements of the parent closure
that we type-check, but that's a more complex change
I'm leaving as future work for now.
For unresolved member completion, we were preferring
the more general type, when we ought to be preferring
the more specific type. Additionally, for both
unresolved member and postfix completion we were
opening archetypes, which doesn't work as expected
since we don't compare requirements. Factor out
the logic that deals with merging base types for
lookup, and have it prefer either the subtype, or
the optional type in the case of optional promotion.
rdar://126168123
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Use the generalized implied result logic, and
rename to `isImpliedResult` since that's really
what we're querying here, and it needs to handle
implicit-last-exprs if enabled.
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.
We didn’t actually have any tests for this. Completions aren’t great here at the moment but since this is an underscored language feature it’s not that important at the moment.
Ignore conversion score increases during code completion to make sure we don't filter solutions that might start receiving the best score based on a choice of the code completion token.
