It's similar to disjunction constraint but represents an "and"
relationship between its elements instead of "or", so all of the
elements have to produce a solution for conjunction constraint
to be considered solved successfully.
This commit refactors the way ASTs are being built in SourceKit and how `SwiftASTConsumer`s are served by the built ASTs. `SwiftASTManager.h` should give an overview of the new design.
This commit does not change the cancellation paradigm in SourceKit (yet). That is, subsequent requests with the same `OncePerASTToken` still cancel previous requests with the same token. But while previously, we were only able to cancel requests that haven’t started an AST build yet, we can now also cancel the AST build of the to-be-cancelled requests.
With this change in place, we can start looking into explicit cancellation of requests or other cancellation paradigms.
for unapplied references when the choice is a function declaration.
This will allow the solver to prune those overload choices when it
has already found a solultion with a property (all else equal in the
score). This is already done as an ambiguity tie-breaker in solution
ranking, but adding this bit to the score will prune a lot of search
space within the solver.
Instead of passing pattern directly, let's fetch it from the pattern
binding and remove extra argument from `SolutionApplicationTarget::forUninitializedVar`.
- Explicitly limit favoring logic to only handle
unary args, this seems to have always been the
case, but needs to be handled explicitly now that
argument lists aren't exprs
- Update the ConstraintLocator simplification to
handle argument lists
- Store a mapping of locators to argument lists
in the constraint system
- Abstract more logic into a getArgumentLocator
method which retrieves an argument-to-param locator
from an argument anchor expr
Pattern matching in Swift can either be expression pattern matching by comparing two instances using the `~=` operator or using enum matching by matching the enum case and its associated types (+ tuple pattern matching, but that’s not relevant here). We currenlty only consider the expression pattern matching case for code completion. To provide enum pattern matching results, we thus need to have a `~=` operator between the code completion token and the match expression
For example, when we are completing
```swift
enum MyEnum {
case myCase(String)
}
switch x {
case .#^COMPLETE^#
}
```
then we are looking up all overloads of `~=` and try to match it to the call arguments `(<Code Completion Type>, MyEnum)`.
The way we currently get `#^COMPLETE^#` to offer members of `MyEnum`, is that we are trying to make sure that the `~=<T: Equatable>(T, T)` operator defined in the standard library is the best solution even though it has fixes associated with it. For that we need to carefully make sure to ignore other, more favourable overloads of `~=` in `filterSolutions` so that `~=<T: Equatable>(T, T)` has the best score.
This poses several problems:
- If the user defines a custom overload of `~=` that we don't prune when filtering solutions (e.g. `func ~=(pattern: OtherType, value: MyEnum) -> Bool`), it gets a better score than `~=<T: Equatable>(T, T)` and thus we only offer members of `OtherType` instead of members from `MyEnum`
- We are also suggesting static members of `MyEnum`, even though we can't pattern match them due to the lack of the `~=` operator.
If we detect that the completion expression is in a pattern matching position, also suggests all enum members of the matched type. This allows us to remove the hack which deliberately ignores certain overloads of `~=` since we no longer rely on `~=<T: Equatable>(T, T)`. It thus provides correct results in both of the above cases.
Fixes rdar://77263334 [SR-14547]
Detect situations when type of a declaration hasn't been resolved yet
(one-way constraints would use a type variable to represent a type of IUO pattern),
and use additional type variable and a constraint to represent an
object type of a future optional type.
Resolves: SR-14893
Resolves: rdar://80271666
This is a follow-up to the uninitialized variable generalization.
Pattern binding declaration has to be stored together with the
variable because all of the entries in `SolutionApplicationTarget`
form a union.
`SolutionApplicationTargetsKey` was constructing pattern binding
entries with incorrect `kind`, which led to crashes for pattern
bindings with multiple initialized entries.
