Currently finalization e.g. scope reset and solution minimization
is only done if component step had follow-up e.g. type variable or
disjunction step(s), but it should be done if `take` generated any
fixes as well, or component changed score in any way, otherwise
we might miss some solutions with fixes because "best score" haven't
been reset properly.
If assignment expression is not considered as a top-level candidate
it would mean that other candidates would be allowed to produce
types inconsistent with destination type of the assignment.
Resolves: rdar://problem/51413254
Currently logic to transform call into coercion uses `conformsToProtocol`
to validate that type conforms to one of the ExpressibleBy*Literal protocols.
That function doesn't handle unbound generic parameters and would result in
an infinite loop or a crash when not all of the generic parameters were
explicitly specified for one of the types in the chain e.g. `A.B(42)`
where `A` has at least one generic parameter.
Resolves: rdar://problem/50007727
If one of the generic parameters is missing let's give solver a
chance to diagnose the problem, otherwise there is a risk of failing
type resolution and not producing any diagnostics.
Resolves: rdar://problem/50099849
Introduce a fix to detect and diagnose situations when omitted
generic arguments couldn't be deduced by the solver based on
the enclosing context.
Example:
```swift
struct S<T> {
}
_ = S() // There is not enough context to deduce `T`
```
Resolves: rdar://problem/51203824
This commit adds `ConstraintSystem::getCalleeLocator`, which forms a
locator that describes the callee of a given expression. This function
is then used to replace various places where this logic is duplicated.
This commit also changes the conditions under which a ConstructorMember
callee locator is formed. Previously it was formed for a CallExpr with a
TypeExpr function expr. However, now such a locator is formed if the
function expr is of AnyMetatypeType. This allows it to be more lenient
with invalid code, as well as work with DotSelfExpr.
Resolves SR-10694.
Previously the logic to determine path to the selected overload
in such case was simplistic and only checked the name to be
of constructor, but `ConstructorMember` path is formed only if
member reference is a constructor delegation e.g. `self.init` or
`super.init` in an initializer context.
* [diag] add a diagnostic note for the fixit
* [gsb] emit a diagnostic with fixit to replace ':' with '=='
* [gsb] rename variable
* [gsb] replace dyn_cast with isa
* [test] add a test case
* [test] update tests
* [gsb] emit diagnostic for protocols as well
* [gsb] simplify if statement
* [gsb] rename a variable
* [gsb] Create a helper to remove Self. prefix and add a new test case
* [gsb] simplify checks
* [gsb] move the diagnostic code to finalize()
* [gsb] re-indent
* [gsb] fix a typo
* [gsb] pass values as copy
* [gsb] show a fixit if the subject type is a member type
* [test] update diagnostics in existing tests
* [gsb] check if the subject type has an assoc type decl
* [gsb] use requirement source
* [test] add new tests
* [gsb] use constraint struct and rename to invalidIsaConstraints
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
If generic parameter associated with missing conformance comes
from different context diagnose the problem as "referencing" a
specific declaration from affected type.
Instead of simply pointing out which type had conformance failures,
let's use affected declaration instead, which makes diagnostics much
richer e.g.
```
'List<[S], S.Id>' requires that 'S.Id' conform to 'Hashable'
```
versus
```
initializer 'init(_🆔)' requires that 'E' conform to 'Hashable' [with 'E' = 'S.Id']
```
Since latter message uses information about declaration, it can also
point to it in the source. That makes is much easier to understand when
problem is related to overloaded (function) declarations.
If fixes are allowed let solver record missing protocol conformance
requirements and assume that `conformsTo` constraint is successfully
solved, this helps to diagnose such errors without involving
heavy-weight expression based diagnostics.
Resolves: rdar://problem/40537858
Number of defaults is a fallback condition if there are no other
differences, but pontential bindings which are literal should always
be ranked lower than anything else because there is a higher chance
that such bindings are wrong because their full set might not have
been resolved yet.
Resolves: rdar://problem/39616039
Attempt to use potential bindings inferred for related types variables
discoverable through 'subtype' constraints, this helps to build a
more precise bindings domain for each type variable.
Resolves: rdar://problem/38159133
This is useful for explicit casts and type expressions, where
type loc and expression types might be different, and allows
constraint solver to avoid setting opened types to expressions
which resolves multiple crashes.
Instead of binding collection types directly let's try to
bind using temporary type variables substituted for element
types, that's going to ensure that subtype relationship is
always preserved.
Resolves: rdar://problem/35541153
Presence of some constraints (Subtype at least) requires a certain
contextual ranking of the type variables associated with them when
it comes to picking bindings, otherwise it might lead to no or
invalid solutions, because only a set of the bindings for the best
type variable is attempted.
Resolves: rdar://problem/22898292
Presence of some constraints (Subtype at least) requires a certain
contextual ranking of the type variables associated with them when
it comes to picking bindings, otherwise it might lead to no or
invalid solutions, because only a set of the bindings for the best
type variable is attempted.
Resolves: rdar://problem/22898292
`LinkedExprAnalyzer` is not always precise in collecting types of expressions,
so let's not try to impose anything upon linked operator expressions, which are
"mergable", except actually merging argument/result types together to help
constraint solver.
Resolves: rdar://problem/27700622
Currently `visitAssignExpr` always attempts to use type
derived from destination as a contextual type for assignment
source type-checking, which doesn't always lead to better
results.
Resolves: SR-5081
Fixes a problem related to presence of InOutType in function parameters
which diagnostics related to generic parameter requirements didn't handle
correctly, and improves diagnostics for unsatisfied generic requirements
in operator applications, which we didn't attempt to diagnose at all.
Resolves: rdar://problem/33477726
When a type variable binds to an (unresolved) dependent member type,
it prevents us from inferring the type variable and adds no useful
information to the system. Refuse to bind type variables to dependent
member types.
Fixes rdar://problem/32697033.
Teach preCheckExpression() about UnresolvedSpecializeExpr
where the base is a TypeExpr.
This allows us to type check expressions like
'[Outer<T>.Inner<U>]()' by folding them down to a TypeExpr
with an array type.
