The check to see whether argument matches the parameter exactly
causes two problems: prevents projected value initialized injection;
and, if there are multiple parameters with property wrappers,
would apply incorrect wrapper to other locations because the wrapper
application index wasn't incremented.
Resolves: rdar://140282980
This matches the double curry thunk logic and
ensures that the resulting autoclosure matches the
expected type of the reference, avoiding mismatches
with parent expressions.
rdar://140212823
Attempting to expand macros in the middle of
CSApply can result in attempting to run
MiscDiagnostics within a closure that hasn't yet
had the solution applied to the AST, which can
crash the implicit-self diagnostic logic. Move
the expansion to the end of CSApply such that
expansions are type-checked along with local
decls, ensuring it's run after the solution has
been applied to the AST.
rdar://138997009
When we replay a solution, we must record changes in the trail, so fix the
logic to do that. This fixes the first assertion failure with this test case.
The test case also exposed a second issue. We synthesize a CustomAttr in
applySolutionToClosurePropertyWrappers() with a type returned by simplifyType().
Eventually, CustomAttrNominalRequest::evaluate() looks at this type, and passes
it to directReferencesForType(). Unfortunately, this entry point does not
understand type aliases whose underlying type is a type parameter.
However, directReferencesForType() is the wrong thing to use here, and we
can just call getAnyNominal() instead.
Fixes rdar://139237781.
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.
Since this function is being called from the constraint solver now, we
need to generalize the way it obtains the Type of an Expression, as the
expression itself may not know its own type, only the solver does.
resolves rdar://134371893 / https://github.com/swiftlang/swift/issues/75999
Previously we would only call this in the delayed
application logic, which is currently run for
multi-statement closures. I'm planning on
removing that code path, which uncovered this
issue.
`participatesInInference` is now always true for
a non-empty body, remove it along with the separate
type-checking logic such that empty bodies are
type-checked together with the context.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
If a closure is passed as an argument to a not-fully concurrency
checked callee - require dynamic isolation checking.
This information is going to be used by SILGen to inject expected
executor precondition when necessary.
This is an important information for closures because the compiler
might need to emit dynamic actor isolation checks in some circumstances
(i.e. when a closure is isolated and passed to a not fully concurrency
checked API).
Just like other members of that type, `isPassedToSendableParameter` bit
set tracks information per parameter. The "passed" bit is applicable
to the argument rather than the parameter itself so it should bit kept
on the `AbstractClosureExpr`.
If existential is a protocol composition type where all of the
protocols are `@_marker`, narrowly allow coercion to its superclass
bound (if it matches). Both types have the same representation
which makes it okay.
This is only a problem in Swift 5 mode without strict concurrency
checks. In this mode `@preconcurrency` stripping happens
outside of the solver which means that no conversion restrictions
are recorded for members that got `& Sendable` stripped from
their types.
For example:
```swift
struct S {
@preconcurrency static let member: KeyPath<String, Int> & Sendable
}
func test() {
_ = S.member
}
```
Since `member` is `@preconcurrency` its type would get concurrency
annotations stripped, which includes `& Sendable` which means that
the solver uses `KeyPath<String, Int>` type for the reference and
not the original `KeyPath<String, Int> & Sendable`, this is a problem
for `ExprRewritter::adjustTypeForDeclReference` because conversion
between existential and its superclass bound requires a constraint
restriction which won't be available in this case.
Resolves: rdar://132700409
Implicit initializers internally have "Default" parameter ownership
specifiers, which can only happen for a noncopyable type if the decl is
synthesized, since ownership is required to be specified if it were
written in the source.
There's no reason to warn for such decls, since the user can't see it
anyway. So specifically target an explicitly written "borrowing" as
being confusing, since that's the only valid case that could happen
anyway.
resolves rdar://131546153
The changes to support `& Sendable` composition with key path
types adjusted `buildKeyPathDynamicMemberArgExpr` to support
that but the use-site erroneously still cast index type or
`BoundGenericType` as before.
Resolves: https://github.com/swiftlang/swift/issues/75244
Resolves: rdar://131768785
Consider the following piece of code and what the isolation is of the closure
literal passed to doSomething():
```swift
func doSomething(_ f: sending () -> ()) { ... }
@MyCustomActor
func foo() async {
doSomething {
// What is the isolation here?
}
}
```
In this case, the isolation of the closure is @MyCustomActor. This is because
non-Sendable closures are by default isolated to their current context (in this
case @MyCustomActor since foo is @MyCustomActor isolated). This is a problem
since
1. Our closure is a synchronous function that does not have the ability to hop
to MyCustomActor to run said code. This could result in a concurrency hole
caused by running the closure in doSomething() without hopping to
MyCustomActor's executor.
2. In Region Based Isolation, a closure that is actor isolated cannot be sent,
so we would immediately hit a region isolation error.
To fix this issue, by default, if a closure literal is passed as a sending
parameter, we make its isolation nonisolated. This ensures that it is
disconnected and can be transferred safely.
In the case of an async closure literal, we follow the same semantics, but we
add an additional wrinkle: we keep support of inheritActorIsolation. If one
marks an async closure literal with inheritActorIsolation, we allow for it to be
passed as a sendable parameter since it is actually Sendable under the hood.
