Since labels are considered part of the name, mismatches in labeling
should be invalidate overload choices. Let's prefer an overload with
correct labels but incorrect types over the one with incorrect labels.
This also means that it's possible to restore performance optimizations
related to early filtering in diagnostic mode, which is important for
deeply nested code i.e. SwiftUI views.
The existing overloading rules strongly prefer async functions within
async contexts, and synchronous functions in synchronous contexts.
However, when there are other differences in the
signature, particularly parameters of function type that differ in
async vs. synchronous, the overloading rule would force the use of the
synchronous function even in cases where the synchronous function
would be better. An example:
func f(_: (Int) -> Int) { }
func f(_: (Int) async -> Int) async { }
func g(_ x: Int) -> Int { -x }
func h() async {
f(g) // currently selects async f, want to select synchronous f
}
Effect the semantics change by splitting the "sync/async mismatch"
score in the constraint system into an "async in sync mismatch" score
that is mostly disqualifying (because the call will always fail) and a
less-important score for "sync used in an async context", which also
includes conversion from a synchronous function to an asynchronous
one. This way, only synchronous functions are still considered within
a synchronous context, but we get more natural overloading behavior
within an asynchronous context. The end result is intended to be
equivalent to what one would get with reasync:
func f(_: (Int) async -> Int) async { ... }
Addresses rdar://74289867.
Currently bindings where inferred on every `bindTypeVariable` call,
but that's wasteful because not all binds are always correct. To
avoid unnecessary inference traffic let's wait until re-activated
constraints are simplified and notify binding inference about new
fixed type only if all of them are successful.
when it has property wrapper parameters.
The property wrapper type will be replaced with either the wrapped-value
or projected-value type, depending on the argument label/parameter name,
and CSApply will build a thunk to construct the property wrapper and call
the function.
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.
