Instead of requiring result type of the member to conform to declaring protocol,
as originally proposed by SE-0299, let's instead require `Self` to be bound to
some concrete type in extension that declares a static member.
This would make sure that:
1. Members are only visible on a particular type;
2. There is no ambiguity regarding what base of the member chain is going to be.
If it has been established that member found via static member
lookup on protocol metatype doesn't have correct result type,
chain's result type the should be treated as a hole.
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.
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
* [Sema] Implementing is runtime check always true diagnostic as a fix
* [AST] Implement getWithoutThrows on function type
* [CSSimplify] Detect that checked cast types conversion is always true and record warning fix
* [test] Some additional test cases for SR-13789
* [Sema] Fixing typo on fix name
* [Sema] Move and adjust the ConditionalCast diagnostics to the fix format
* [Sema] Remove some checked cast diagnostics from check constraints and move to fix
* [Sema] Renaming checked cast coercible types fix
* [Sema] Some adjustments and rewrite on the logic for downcast record fix
* [Sema] Move logic of runtime function type to AllowUnsupportedRuntimeCheckedCast::attempt
* [Sema] Abstract checked cast fix logic to static function and minor adjustments
* [Sema] Renamings from review
Introduce `@concurrent` attribute on function types, including:
* Parsing as a type attribute
* (De-/re-/)mangling for concurrent function types
* Implicit conversion from @concurrent to non-@concurrent
- (De-)serialization for concurrent function types
- AST printing and dumping support
Currently the pattern is to collect the type variables and then unique
them. Instead of asking clients to do uniquing, let's just accept a set
as an argument.
Looking for the parent source file is going to fail when the paramter
we're interested in comes from a module context. Request the correct
top-level context in those situations.
rdar://73379770
Unresolved member lookup is allowed to perform implicit optional
unwrap of a base type to find members. Previously if there were
any members directly on `Optional`, lookup would stop there. But
since SR-13815 it became possible for solver to attempt members
found on unwrapped type even if there are viable ones on
`Optional` as well.
New score kind has been introduced to guard against possible ambiguities
with new scheme - `SK_UnresolvedMemberViaOptional`. It's used very
time member found via base type unwrap is attempted. Unfortunately,
doing so can lead to behavior changes in existing code because it's
possible that base was wrapped into optional implicitly based on
context e.g. unresolved member passed in as an argument to a parameter
of optional type.
To fix situations like that, `SK_UnresolvedMemberViaOptional` should
only be increased if there is a mix of members to attempt - both directly
on `Optional` and on unwrapped type, in all other cases score should stay
the same because there could be no ambiguity.
Resolves: rdar://73027153
This is a follow-up to https://github.com/apple/swift/pull/35072.
Let's wait until both sides are equally optional before attempting
`.rawValue` fix, otherwise there is a risk that a valid code would
get diagnosed.
Extend test coverage of possible `.rawValue` situations to
contextual and argument positions to make sure that valid
code is accepted.
Resolves: SR-13951
