Produce a tailored diagnostic when it has been established that
base type of a static member reference on protocol metatype doesn't
conform to a required protocol.
The first type represents a result of an unresolved member chain,
and the second type is its base type. This constraint acts almost
like `Equal` but also enforces following semantics:
- It's possible to infer a base from a result type by looking through
this constraint, but it's only solved when both types are bound.
- If base is a protocol metatype, this constraint becomes a conformance
check instead of an equality.
Since it's now possible to refer to static members declared on a protocol
metatype if result type conforms to the protocol we need to adjust failure
detection to identify that conformance failure means and invalid reference
in certain situations.
Since it's now possible to infer base type of an unresolved member
reference to be a protocol type we need to adjust `matchTypes` to
check conformance instead of type equality between base (represented
by a protocol) and chain's concrete result type.
To be able to infer base type in situations like:
```swift
func foo<T: P>(_: T) {}
foo(.bar)
```
Type variable used for a base type of the chain has to be allowed
to infer types from contextual protocol requirements e.g. `T: P`
in our example.
NIO exposed an issue in the new availability walkers where an implicit
check was not being performed. They were able to get this to crash by
using a defer statement - the body of which contains implicit
declarations that got run through the walker. This exposed a wider hole
in availability checking of defer statements. Namely, that it wasn't
happening.
Let's dilute the meaning of `isImplicit` in the availability walkers to
account for this desugaring.
rdar://74484150
Make both Error and CodingKey conform to ConcurrentValue, so that
thrown errors always conform to ConcurrentValue. Downgrade (to
warnings) and ConcurrentValue-related diagnostics that are triggered
by this change in existing Error and CodingKey-conforming types to
reduce the impact on source compatibility.
This improves source compatibility in cases where a marker
protocol is introduced after-the-fact (e.g., for `Error`),
and is safe because there's no runtime component to marker protocols.
The order of diagnostic emission absolutely does not matter. What this transaction was actually doing was suppressing valid diagnostics. This is a deeply unsound thing to do since if errors are emitted but Codable synthesis succeeds then invalid code can make its way past Sema.
rdar://74392492
If the completion loc was in a trailing closure arg, it only makes sense to
ignore later missing args if they have function type, as there's no way for the
user to complete the call for overload being matched otherwise.
Also fix a bug where we were incorrectly penalizing solutions with holes that
were ultimately due to missing arguments after the completion position.
Resolves rdar://problem/72412302
There is no problem with having an existential value that involves a
marker protocol. However, since there is no runtime checking for
marker protocols, ban "as?" and "is" casts to them.
Is the same argument is out-of-order in multiple solutions, let's
diagnose it as if there was no ambiguity.
Resolves: SR-14093
Resolves: rdar://73600328
If multiple solutions have exactly a fix for exactly the same invalid member
reference in key path, let's diagnose that as if there is no ambiguity there.
It's possible that different overload choices could have the same
conformance requirement, so diagnostics should be able to emit an
error in situations where multiple solutions point to the missing
conformance at the same location (both in AST and requirement list).
Resolves: rdar://74447308
This attribute marks a function has having an async alternative,
optionally providing the name of that function as a string. Intended to
be used to allow warnings when using a function with an async
alternative in an asynchronous context, to make the async refactorings
more accurate, and for documentation.
