Under discussion as part of an amendment to SE-0466, limit default main
actor inference so it doesn't apply to a nested type within a
nonisolated type.
Previously, only conditional unavailability was considered, but setters that
are always unavailable must also make a keypath read-only.
Resolves rdar://155832511.
With `NonisolatedNonsendingByDefault` an explicit `nonisolated`
attribute in declaration context is inferred to mean `nonisolated(nonsending)`
and it should be printed as such in interface files and other places.
The inference logic that did didn't remove the original attribute
which meant that it would be printed twice i.e.
`nonisolated nonisolated(nonsending) func test() async` which is
incorrect and would fail swift interface validation.
Resolves: rdar://155847011
The previous message was just suggesting unchecked Sendable, but instead
we should be suggesting to add final to the class. We also don't
outright suggest using unchecked Sendable -- following
https://github.com/swiftlang/swift/pull/81738 precedent.
Resolves rdar://155790695
Completion can end up calling into pre-checking multiple times in
certain cases, make sure we don't attempt to fold a SequenceExpr
multiple times since its original AST is in a broken state
post-folding. Instead, just return the already-folded expression.
rdar://133717866
When checking whether a capture of a metatype is Sendable, we had an
incomplete and incorrect check for SendableMetatype conformance.
Replace that with the proper "prohibits isolated conformances" check
on the generic signature, which matches what we do on the caller side.
Fixes issue #82905 / rdar://155399531.
In the provided test case, the generic signature of the
protocol requirement is
<Self, T where Self == T.A, T: P2>
The conformance requirement `Self: P1` is derived from `T: P2`
and `Self.A: P1` in P1. So given a substitution map
`{ Self := X, T := T }` that replaces T with a concrete type X
and T with a type parameter T, there are two ways to recover a
substituted conformance for `Self: P1`:
- We can apply the substitution map to Self to get X, and look
up conformance of X to P1, to get a concrete conformance.
- We can evaluate the conformance path `(T: P2)(Self.A: P1)`,
to get an abstract conformance.
Both answers are correct, but SILGenModule::emitProtocolWitness()
was assuming it would always get a concrete conformance back.
This was the case until e3c8f423bc,
but then we started returning an abstract conformance. SILGen
would then mangle the protocol witness thunk in a way that was
not sufficiently unique, and as a result, we could miscompile
a program where two witness tables both hit this same scenario.
By using contextual types in the getRequirementToWitnessThunkSubs()
substitution map, we ensure that evaluating the conformance path
against the substitution map produces the same result as performing
the global lookup.
Also, to prevent this from happening again, add a check to SILGen
to guard against emitting two protocol witness thunks with the
same mangled name.
Unfortunately, this is done intentionally as part of some
backward deployment logic for coroutine accessors. There is a
hack to allow duplicate thunks with the same name in this case,
but this should be revisited some day.
Fixes rdar://problem/155624135..
Since LayoutPrespecialization has been enabled by default in all compiler
invocations for quite some time, it doesn't make sense for it to be treated as
experimental feature. Make it a baseline feature and remove all the
checks for it from the compiler.
When synthesizing code for Codable conformances involving unsafe types,
make sure to wrap the resulting expressions in "unsafe" when strict memory safety is enabled.
Tweak the warning-emission logic to suppress warnings about spurious
"unsafe" expressions when the compiler generated the "unsafe" itself,
so we don't spam the developer with warnings they can't fix. Also make
the checking for other suppression considerations safe when there are
no source locations, eliminating a potential assertion.
Fixes rdar://153665692.
The `$generator` variable we create for the async for..in loop is
`nonisolated(unsafe)`, so ensure that we generate an `unsafe`
expression when we use it. This uncovered some inconsistencies in how
we do `unsafe` checking for for..in loops, so fix those.
Fixes rdar://154775389.
