With the re-introduction of `@_unsafeInheritExecutor` for `TaskLocal.withValue`,
we need to extend the type checker trick with `_unsafeInheritExecutor_`-prefixed
functions to work with methods. Do so to make `TaskLocal.withValue` actually
work this way.
If a conformance is inherited from a superclass, the isolation
of the subclass should be inferred directly from the superclass.
If the superclass has opted out of global actor inference from a
protocol, such as by conforming to the protocol in an extension,
then the subclass should not infer isolation from the protocol.
If ObjC member cannot be overridden due to isolation mismatch set `@preconcurrency`
bit to make the diagnostic a warning instead of an error in Swift 5 mode.
Resolves: rdar://130776220
The move from `@_unsafeInheritExecutor` to `#isolation` for the
with*Continuation breaks code that is using `@_unsafeInheritExecutor` and
calling these APIs. This originally caused silent breakage (which manifest
as runtime crashes), and is now detected by the compiler as an error.
However, despite `@_unsafeInheritExecutor` being an unsafe,
not-intended-to-be-user-facing feature, it is indeed being used, along
with these APIs. Introduce _unsafeInheritExecutor_-prefixed versions of
the `with*Continuation` and `withTaskCancellationHandler` APIs into
the _Concurrency library that use `@_unsafeInheritExecutor`. Then,
teach the type checker to swap in these
_unsafeInheritExecutor_-prefixed versions in lieu of the originals
when they are called from an `@_unsafeInheritExecutor` function. This
allows existing code using `@_unsafeInheritExecutor` with these APIs
to continue working as it has before, albeit with a warning that
`@_unsafeInheritExecutor` has been removed.
Fixes rdar://131151376.
`#isolation` in unsafe within a function that uses
`@_unsafeInheritExecutor`, so avoid the implicit use of the new
`AsyncIteratorProtocol.next(isolation:)` in such functions.
An `@_unsafeInheritExecutor` function is unsafe because it doesn't
really "inherit" the executor, it just avoids immediately hopping off
the executor. That means that using `#isolation` within such a
function is fundamentally broken. Ban the use of `#isolation` within
such a function, providing a Fix-It that removes the
`@_unsafeInheritExecutor` attribute and adds a defaulted parameter
isolation: (any Actor)? = #isolation
instead. That's the real, safe pattern that want going forward.
We did say it was unsafe, after all. Part of rdar://131151376.
isolation of a stored property initializer.
This allows isolated key-path components to be used in stored property
initializers when the stored property itself is isolated to the same
global actor.
Add support for swift style diagnostics for swift caching. This includes
pre-populate the GeneratedSourceInfo with macro name so it doesn't need
to infer from an ASTNode, which the caching mechanism cannot preserve.
Still leave the default diagnostic style to LLVM style because replaying
swift style diagnostics is still very slow and including parsing source
file using swift-syntax.
rdar://128615572
Otherwise, we will assume that an async let autoclosure infers isolation from
its DeclContext... which we do not want. An async let autoclosure should always
be nonisolated + sending.
The diagnostic change that I mentioned in the header is that we were emitting
unfortunate "sending task or actor isolated could result in races" error. I
eliminated this by adding a new diagnostic for transfer non transferrable errors
happening in autoclosures. So now we emit this:
```swift
func asyncLetInferAsNonIsolated<T : Actor>(
isolation actor: isolated T
) async throws {
async let subTask: Void = {
await useValueAsyncNoReturnWithInstance(self, actor)
// expected-warning @-1:47 {{sending 'self' risks causing data races}}
// expected-note @-2 {{sending 'actor'-isolated 'self' into async let risks causing data races between nonisolated and 'actor'-isolated uses}}
}()
await subTask
```
I also noticed that we did not have enough test cases for autoclosures in
general so I also added a bunch of tests just so we can see what the current
behavior is. I think there are a few issues therein (I believe some may have
been reported due to '??').
rdar://130151318
Downgrade a mismatch on `any Sendable` -> `Any` to a warning until
Swift 6 to enable class authors to introduce concurrency annotations
to overridable properties.
Resolves: rdar://122193606
Make sure `CouldNotInferPlaceholderType` can
produce a diagnostic for a `PlaceholderType`
locator element, and avoid emitting an extra
diagnostic for a placeholder type in an invalid
position.
Not all runtimes can correctly operate with types that use noncopyable
generics. When the generic argument of a type is noncopyable, old
runtimes can't recognize that to correctly check conformances that may
be conditional on those arguments being Copyable, etc.
resolves rdar://126239335
A bunch of synthesis code was getting this wrong
and setting an interface type for a TypedPattern.
Assert that we have a contextual type, and update
some synthesis logic.
The case being handled is the input being more
optional than the cast type, so we need to inject
optional patterns to bring the input down to the
same optionality of the cast. Therefore we need
to take the optional types from the start of the
input optional types, not the end.
Luckily this issue doesn't currently cause any
issues because `coercePatternToType` will fixup
the right type.
These aren't currently claimed by anything other
than SILFunctions, and as such are invalid in
regular Swift code. Treat them as SIL type
attributes. Also while here, fix the SIL reference
attributes to be SIL attributes.
A conditional conformance to a protocol does not usually imply
a conformance to the protocol's inherited protocols, because
we have no way to guess what the conditional requirements
should be.
A carveout was added for 'Sendable', so that protocols could
inherit from 'Sendable' retroactively. However, the 'Sendable'
conformance would become conditional, which causes us to
reject a _second_ conditional conformance to such a protocol:
struct G<T> {}
protocol P: Sendable {}
protocol Q: Sendable {}
extension G: P where T: P {}
extension G: Q where T: Q {}
To make this work, tweak the code so that an implied conformance
has the same generic signature as the conforming type, that is,
we force it to be unconditional.
Fixes rdar://122754849
Fixes https://github.com/swiftlang/swift/issues/71544
