Number the parameters starting at 1 in order to
match other diagnostics such as
diag::missing_argument_positional, and change the
text to make it explicit that we're referring to
the parameter position (rather than argument
position).
The recursive properties now include the type alias generic parameters
and parent type, not just the underlying type. This means that a type
alias type like Foo<T>.Bar can be dependent even if its underlying type
is not dependent.
To preserve correct behavior under substitution, the parent type
of a protocol type alias must be the 'Self' generic parameter and
not the protocol's existential type.
Introduce a fix/diagnostic when there is a contextual mismatch
between source and destination types of the assignment e.g.:
```swift
var x: Int = 0
x = 4.0 // destination expects an `Int`, but source is a `Double`
```
Use the interface type of the underlying type in the GSB in as many
cases as possible except for one important one: requirement signature
computation. There, use the structural type so we don't wind up
recursively validating the requirements of an incomplete protocol.
Flush it and the early validation hack now that we can delay computing the underlying interface type on demand and have taught type resolution to honor the structural type of a typealias.
This changes the way requirement signatures are spelled as a side effect.
mismatches in function types.
This improves the diagnostic in cases where we have argument-to-parameter
conversion failures or contextual type mismatches due to inout attribute
mismatches.
When there's a module with the same name as a type in a
different module, lookup will look into the type, not the module, when
resolving members. Until that behavior is fixed, add a note showing what
lookup was trying to look into, to make the behavior more clear.
Helps rdar://54770139
This means that we no longer have the invariant that the extendedType always
contains the generic parameters. So we need to fix the assertions/test cases
for it.
This makes sure that solver is able to produce specialized
fixes in some cases e.g. existential conversions, mismatched
generic arguments, or force unwraps before fallback to
generic `cannot convert X to Y` failure.
Under non-editor mode, the fixit for inserting protocol stubs is associated with a note
pointing to the missing protocol member declaration which could stay in a separate file from
the conforming type, leading to the behavior of rdar://51534405. This change checks if
the fixit is in a separate file and issues another note to carry the fixit if so.
rdar://51534405
This check wasn't ever correct, because the fact that the the protocol comes
from another module doesn't change the fact that the type is valid for lookup
within this module. It incorrectly rejects the following, valid code:
```swift
// In A.swift
public protocol A {}
```
```
// In B.swift
import A
extension A {
typealias B = Int
func b(_ b: Self.B) {}
}
```
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
Detect and diagnose a contextual mismatch between expected
collection element type and the one provided (e.g. source
of the assignment or argument to a call) e.g.:
```swift
let _: [Int] = ["hello"]
func foo(_: [Int]) {}
foo(["hello"])
```
This PR migrates instance member on type and type member on instance diagnostics handling to use the new diagnostics framework (fixes) and create more reliable and accurate diagnostics in such scenarios.
Detect that failed requirement comes from contextual type and use
that information to determine affected declaration.
Resolves: rdar://problem/47980354
We generated a mix of "inferred" and "nested type name match"
constraints for the case where we had two nested types with the same
name and inferred that they are equal. Make them consistent by always
using nested type name match constraints. This fixes a bug where we
would get different canonical generic signatures in different source
files because we inferred the same-type constraint with different
requirement sources.
Fixes rdar://problem/48049725.
If affected declaration is a static or instance memeber (excluding
operators) and failed requirement is declared in other nominal type
or extension, diagnose such problems as `in reference` instead of
claiming that requirement belongs to the member itself.
Extend existing `RequirementFailure` functionality to support
conditional requirement failures. Such fixes are introduced
only if the parent type requirement has been matched successfully.
Resolves: rdar://problem/47871590
