Allow `any Sendable` to match `Any` constraint while matching
generic arguments i.e. `[any Sendable]` -> `[Any]` when `any Sendable`
type comes from context that involves `@preconcurrency` declarations
in non-strict concurrency compiler mode.
Note that it's currently impossible to figure out precisely
where `any Sendable` type came from.
Prevent generic arguments from being assigned `any Sendable`
directly, that should only happen through inference. This is
required because we allow `any Sendable` -> `Any` conversion
in modes without strict concurrency enabled to maintain source
compatibility and let the developers annotate existing APIs
with `any Sendable` and other concurrency attributes.
If a (trailing) closure is determined to be an extraneous argument
for one of the overload choices it needs to be marked as hole as
eagerly as possible and prevented from being resolved because
otherwise it's going to be disconnected from the rest of the
constraint system and resolution might not be able to find all of
the referenced variables. This could result either in crashes
or superfluous diagnostics.
Resolves: rdar://141012049
Avoid wrapping parameters in the function reference
for compound applies, and make sure we consult
the parameter label in the compound name if it's
present to determine whether to match using the
projected value or not. This matches the existing
logic in `unwrapPropertyWrapperParameterTypes`.
Just because the type of the initializer expression is an opaque return type,
does not mean it is the opaque return type *for the variable being initialized*.
It looks like there is a bit of duplicated logic and layering violations going
on so I only fixed one caller of openOpaqueType(). This addresses the test case
in the issue. For the remaining calls I added FIXMEs to investigate what is
going on.
Fixes https://github.com/swiftlang/swift/issues/73245.
Fixes rdar://127180656.
FunctionRefKind was originally designed to represent
the handling needed for argument labels on function
references, in which the unapplied and compound cases
are effectively the same. However it has since been
adopted in a bunch of other places where the
spelling of the function reference is entirely
orthogonal to the application level.
Split out the application level from the
"is compound" bit. Should be NFC. I've left some
FIXMEs for non-NFC changes that I'll address in a
follow-up.
Currently we set `FunctionRefKind::Compound` for
enum element patterns with tuple sub-patterns to
ensure the member has argument labels stripped. As
such, we need to account for the correct application
level in `getNumApplications`. We ought to be
setting the correct FunctionRefKind and properly
handling the label matching in the solver though.
We also ought to consider changing FunctionRefKind
such that "is compound" is a separate bit from the
application level.
rdar://139234188
If the base type of the specialization is invalid,
the AST node is going to be replaced with `ErrorExpr`.
We need to handle that gracefully when attempting
to apply specialization in such situations.
Resolves: https://github.com/swiftlang/swift/issues/77644
Situations like:
```
let _: Double = <<CGFloat>>
<var/property of type Double> = <<CGFloat>>
```
Used to be supported due to an incorrect fix added in
diagnostic mode. Lower impact here means that right-hand
side of the assignment is allowed to maintain CGFloat
until the very end which minimizes the number of conversions
used and keeps literals as Double when possible.
Resolves: rdar://139675914
Allow witnesses to introduce `any Sendable` types into their interface
before requirements (predicated on presence of `@preconcurrency` and
Swift 5 language mode) as a pathway for concurrency adoption.
Resolves: rdar://134503878
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
