Candidate is viable (with some score) if:
- Candidate is exactly equal to a parameter type
- Candidate type differs from a parameter type only in optionality
- Parameter is a generic parameter type and all conformances are matched by a candidate type
- Candidate tuples matches a parameter tuple on arity
- Candidate is an `Array<T>` and parameter is an `Unsafe*Pointer`
- Candidate is a subclass of a parameter class type
- Candidate is a concrete type and parameter is its existential value (except Any)
- Don't attempt to insert fixes if there are restrictions present, they'd inform the failures.
Inserting fixes too early doesn't help the solver because restriction matching logic would
record the same fixes.
- Adjust impact of the fixes.
Optional conversions shouldn't impact the score in any way because
they are not the source of the issue.
- Look through one level of optional when failure is related to optional injection.
The diagnostic is going to be about underlying type, so there is no reason to print
optional on right-hand side.
Make sure `CouldNotInferPlaceholderType` can
produce a diagnostic for a `PlaceholderType`
locator element, and avoid emitting an extra
diagnostic for a placeholder type in an invalid
position.
If a placeholder appears on one of the side of tuple element matching
conversion, consider that conversion to be solved, because the actual
error is related to the placeholder.
These were replaced by `#file`, `#line`, etc. with SE-0028, prior to
Swift 3. We don't need this custom error message any more, and they
shouldn't be keywords. Stop treating them as keywords in the lexer.
Instead of failing constraint generation by returning `nullptr` for an `ErrorExpr` or returning a null type when a type fails to be resolved, return a fresh type variable. This allows the constraint solver to continue further and produce more meaningful diagnostics.
Most importantly, it allows us to produce a solution where previously constraint generation for a syntactic element had failed, which is required to type check multi-statement closures in result builders inside the constraint system.
The deepest expression is the one that introduced the ambiguity into
the chain, so depth and index should be deciding factors and number of
overloads - a tie-breaker, while choosing what to diagnose.
Resolves: rdar://94360230
When emitting a diagnostic, mark the TypeRepr as invalid and
return an ErrorType to ensure that the diagnostic is not
emitted again, and to muffle downstream diagnostics.
- 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
Currently `isLiteralCoveredBy` only checks for top-level type variable or hole.
That check has to be sunk down so it could be used after optionality is stripped
away (when possible), otherwise bindings like `$T0?` are (incorrectly) determined
to cover literal requirements (because conformance check always succeeds when
attempted on a type variable).
Unwrap `InOutExpr` from all parens until the outermost paren or a tuple
to correctly diagnose calls like `foo(((&bar)))` or `foo(x: (&bar))`,
and suggest a fix-it with moves `&` outside parens.
Resolves: rdar://problem/71356981
I created a second copy of each test where the output changes
after disabling parser lookup. The primary copy now explicitly
calls the frontend with -disable-parser-lookup and expects the
new diagnostics; the *_parser_lookup.swift version calls the
frontend with -enable-parser-lookup and has the old expectations.
This allows us to turn parser lookup on and off by default
without disturbing tests. Once parser lookup is completely
removed we can remove the *_parser_lookup.swift variants.
Instead of requiring sub-classes of `ContextualMismatch` to implement
`diagnoseForAmbiguity` let's implement it directly on `ContextualMismatch`
itself and check whether all of the aggregated fixes have same types on
both sides and if so, diagnose as-if it was a single fix.
`_` or discard assignment expression should only be used on the left-hand
side of the assignment expression. Incorrect uses are easy to detect during
constraint generation which also allows us to avoid complications related
to other diagnostics when `_` is used incorrectly.
Reverts apple/swift#30006. It caused a regression that we'd like to address before re-landing:
```swift
struct X {
var cgf: CGFloat
}
func test(x: X?) {
let _ = (x?.cgf ?? 0) <= 0.5
}
```
This reverts commit 0a6b444b49.
This reverts commit ed255596a6.
This reverts commit 3e01160a2f.
This reverts commit 96297b7e39.
Resolves: rdar://problem/60185506
Prioritize type mismatches over conformance failures when stdlib
types are involved because it wouldn't be appropriate to suggest
to add such a conformance, so the problem is most likely related
to something else e.g. other overload choice has a better fix.
Consider following example:
```swift
struct S {
init(_: Double) {}
init<T: BinaryInteger>(_: T) {}
}
_ = S(Double("0"))
```
In cases like that it's better to prefer failable initializer
which takes a `String` and returns `Double?` and diagnose a
problem related to missing optional unwrap instead of missing
conformances related to a `String` argument of other `Double`
initializer just because it returns a concrete type.
Since `simplifyRestrictedConstraintImpl` has both parent types and
does nested type matching it's a good place to diagnose top-level
contextual problems like mismatches in underlying types of optionals.
If a type variable representing "function type" is a hole
or it could be bound to some concrete type with a help of
a fix, let's propagate holes to the "input" type. Doing so
provides more information to upcoming argument and result matching.
* [Sema][Diagnostics] Add fixit for warning when inferring an undesirable type
* [Sema][Diagnostics] Generalize undesirable type warning to include arrays of empty tuples
https://bugs.swift.org/browse/SR-11511
