When the default isolation is main-actor, don't infer @MainActor
for a type that conforms to a protocol P in its primary definition when
P inherits from Sendable. Such types should remain non-isolated
because they're highly unlikely to be able to implement the P
conformance (which cannot be isolated).
Put this feature behind a new experimental flag,
SendableProhibitsMainActorInference.
Implements rdar://151029300
Returning the unsubstituted superclass type is not correct,
because it may contain type parameters. Let's form a new
UnboundGenericType instead.
- Fixes https://github.com/swiftlang/swift/issues/82160.
- Fixes rdar://152989888.
Adjust the downgrade check for static member references to
account for the fact that argument could come of a tuple or
some other reference that doesn't have a declaration associated
with it.
Resolves: rdar://153083848
(cherry picked from commit 3ae8d5680f)
My change 983b75e1cf broke
-warn-long-expression-type-checking because now the
ExpressionTimer is not instantiated by default and that
entire code path is skipped.
Change it so that if -warn-long-expression-type-checking
is passed in, we still start the timer, we just don't
ever consider it to have 'expired'.
Fixes rdar://problem/152998878.
We weren't substituting generic arguments into function types. In the
presence of parameter packs, this could mean that the parameter and
argument lists no longer match up, which would cause the effects
checker to prematurely bail out after treating this as "invalid" code.
The overall effect is that we would not properly check for throwing
behavior in this case, allowing invalid code (as in the example) and
miscompiling valid code by not treating the call as throwing.
Fixes rdar://153926820.
Follow-up for https://github.com/swiftlang/swift/pull/82326.
The optional injection is only viable is the wrapped type is
not yet resolved, otherwise it's safe to wrap the optional.
(cherry picked from commit 4804f2131b)
Follow-up for https://github.com/swiftlang/swift/pull/79893.
More than one global actor isolated conformance at any level
creates a clash and conforming type should be inferred as `nonisolated`.
Resolves: rdar://154202375
(cherry picked from commit 2e1fe444a6)
We need to be very careful while matching types to test whether a
fix is applicable or not to avoid adding extraneous fixes and failing
the path early. This is a temporary workaround, the real fix would
be to let `matchTypes` to propagate `TMF_ApplyingFixes` down.
Resolves: rdar://154010220
Resolves: https://github.com/swiftlang/swift/issues/82397
(cherry picked from commit 7ecb1fd1db)
'@preconcurrency' imports open up memory safety holes with respect to
Sendable, which are diagnosed under strict memory safety + strict
concurrency checking. Allow one to write '@unsafe' on those imports to
silence the diagnostic about it.
Make sure that referencing `nonisolated(nonsending)` properties,
especially through a witness is as not treated as leaving the
isolation domain of the caller.
Resolves: rdar://153922620
(cherry picked from commit 35a41ab9cf)
If the requirement is `nonisolated(nonsending)` but witness is
synchronous, prevent actor isolation inference from requirements
because this isolation only applies to asynchronous declarations
at the moment.
Resolves: rdar://153680826
(cherry picked from commit a964282275)
Otherwise, if PDerived inherits from P and P's requirements are
witnessed by @MainActor-isolated members, we fail to infer
@MainActor isolation on the conformance to PDerived.
- Fixes https://github.com/swiftlang/swift/issues/82222.
- Fixes rdar://153219831.
Specifically, there is currently a bug in TypeCheckConcurrency.cpp where we do
not visit autoclosures. This causes us to never set the autoclosure's
ActorIsolation field like all other closures. For a long time we were able to
get away with this just by relying on the isolation of the decl context of the
autoclosure... but with the introduction of nonisolated(nonsending), we found
cases where the generated single curry autoclosure would necessarily be
different than its decl context (e.x.: a synchronous outer curry thunk that is
nonisolated that returns an inner curry thunk that is
nonisolated(nonsending)). This problem caused us to hit asserts later in the
compiler since the inner closure was actually nonisolated(nonsending), but we
were thinking that it should have been concurrent.
To work around this problem, I changed the type checker in
ced96aa5cd to explicitly set the isolation of
single curry thunk autoclosures when it generates them. The reason why we did
this is that it made it so that we did not have to have a potential large source
break in 6.2 by changing TypeCheckConcurrency.cpp to visit all autoclosures it
has not been visiting.
This caused a follow on issue where since we were now inferring the inner
autoclosure to have the correct isolation, in cases where we were creating a
double curry thunk for an access to a global actor isolated field of a
non-Sendable non-global actor isolated nominal type, we would have the outer
curry thunk have unspecified isolation instead of main actor isolation. An
example of this is the following:
```swift
class A {
var block: @MainActor () -> Void = {}
}
class B {
let a = A()
func d() {
a.block = c // Error! Passing task isolated 'self' to @MainActor closure.
}
@MainActor
func c() {}
}
```
This was unintentional. To work around this, this commit changes the type
checker to explicitly set the double curry thunk isolation to the correct value
when the type checker generates the double curry thunk in the same manner as it
does for single curry thunks and validates that if we do set the value to
something explicitly that it has the same value as the single curry thunk.
rdar://152522631
(cherry picked from commit c28490b527)
If we have a tuple with unresolved pack expansion on one side
and an optional type on the other, prevent `matchTypes` from
wrapping optional into a one-element tuple because the matching
should be handled as part of the optional injection.
Resolves: rdar://152940244
(cherry picked from commit 6cfbafd968)
If a `nonisolated` type conforms to a global-isolated protocol
the witnesses to the protocol requirements should infer the
isolation from the protocol but instead be `nonisolated`.
Resolves: rdar://145519840
(cherry picked from commit e50acbf3d5)
Even if the requirement is stated on an isolated protocol if the
conformance is implied by a nonisolated one all of the requirements
and witnesses should be nonisolated.
(cherry picked from commit 06be7bda39)
These are special declarations that are synthesized by the compiler
or a macro and warnings about them are non-actionable.
(cherry picked from commit 17976c7775)
The execution of these functions is controlled by the testing
framework and it's okay if their behavior changes when the feature
flag is enabled.
Resolves: rdar://152687527
(cherry picked from commit f2f5d234dc)
Macro expansion can call typeCheckExpr(), which performs qualified
lookups. So if we expand macros while binding extensions, these
qualified lookups can fail because they cannot find members of
extensions that have not been bound yet.
To fix this, try binding extensions without performing macro
expansion first. If any extensions remain at the end, we fall back
to the old behavior, and try to bind them again, this time
performing macro expansion.
Fixes rdar://149798059.
I previously added this hack to match the logic in
`TypeChecker::lookupUnqualified`, but it turns out that can introduce
request cycles for cases where `CodingKeys` is used in a generic
requirement for one of `Codable`'s potential value witnesses. Scale
back the hack such that it's only done when we get an initial empty
lookup result, ensuring we maintain source compatibility. Both these
lookup hacks should go away once we properly handle CodingKeys
synthesis.
rdar://153096639
Prevent migration from handling declarations that come from a
module different from the current one, this is primarily a
problem for swiftinterfaces that can get rebuilt when the module
is imported by a model that has migration mode enabled.
Resolves: rdar://152687353
(cherry picked from commit bcd6caaea4)
The compiler would previously accept use of `@_inheritActorContext`
on a parameter with a synchronous function type which wasn't marked
as `@isolated(any)`. That is incorrect because in such cases the
attribute has no effect and furthermore would prevent Sendable
and isolation checking.
Uses like that are currently diagnosed by the type-checker but we
need to go one step further and remove the effect in such case to
prevent invalid uses.
Resolves: rdar://143581268
(cherry picked from commit dbe19b6d5f)
