Non-escapable struct definitions often have inicidental integer fields that are
unrelated to lifetime. Without an explicit initializer, the compiler would infer
these fields to be borrowed by the implicit intializer.
struct CountedSpan: ~Escapable {
let span: Span<Int>
let i: Int
/* infer: @lifetime(copy span, borrow i) init(...) */
}
This was done because
- we always want to infer lifetimes of synthesized code if possible
- inferring a borrow dependence is always conservative
But this was the wrong decision because it inevitabely results in lifetime
diagnostic errors elsewhere in the code that can't be tracked down at the use
site:
let span = CountedSpan(span: span, i: 3) // ERROR: span depends on the lifetime of this value
Instead, force the author of the data type to specify whether the type actually
depends on trivial fields or not. Such as:
struct CountedSpan: ~Escapable {
let span: Span<Int>
let i: Int
@lifetime(copy span) init(...) { ... }
}
This fix enables stricter diagnostics, so we need it in 6.2.
Fixes rdar://152130977 ([nonescapable] confusing diagnostic message when a
synthesized initializer generates dependence on an Int parameter)
(cherry picked from commit 8789a686fed869e3cd7bc4e748a443e71df464e1)
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)
This avoids diagnostic errors on synthesized accessors, which are impossible for developers to understand.
Fixes rdar://153793344 (Lifetime-dependent value returned by generated accessor '_read')
(cherry picked from commit 855b3e4446)
Handle the presence of mark_dependence instructions after a begin_apply.
Fixes a compiler crash:
"copy of noncopyable typed value. This is a compiler bug. ..."
(cherry picked from commit 7a29d9d8b6)
Extract the special pattern matching logic that is otherwise unrelated to the
check() function. This makes it obvious that the implementation was failing to
set the 'changed' flag whenever needed.
(cherry picked from commit c41715ce8c)
Do not eliminate a mark_dependence on a begin_apply scope even though the token
has a trivial type.
Ideally, token would have a non-trivial Builtin type to avoid special cases.
(only relevant on 6.2)
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)
If two conformances imply a conformance to the same marker
protocol, don't diagnose redundancy if they differ by
unavailability. Instead, allow the more available conformance
to win.
This allows declaring a type that conforms to a protocol
that inherits from SendableMetatype, followed by an
unavailable Sendable conformance on the same type.
Fixes rdar://152509409.
'@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.
If a C++ namespace has redeclarations in a bridging header, printing AST for the namespace would crash the compiler. This is because such a redeclaration would not have an owning Clang module, and the AST printer did not account for that.
This change fixes the crash.
rdar://151715540
(cherry picked from commit cc9c51deea)
OSSA lifetime canonicalization can take a very long time in certain
cases in which there are large basic blocks. to mitigate this, add logic
to skip walking the liveness boundary for extending liveness to dead
ends when there aren't any dead ends in the function.
Updates `DeadEndBlocks` with a new `isEmpty` method and cache to
determine if there are any dead-end blocks in a given function.
(cherry picked from commit 1f3f830fc7)
To guard the new UnsafeMutablePointer.mutableSpan APIs.
This allows older compilers to ignore the new APIs. Otherwise, the type checker
will crash on the synthesized _read accessor for a non-Escapable type:
error: cannot infer lifetime dependence on the '_read' accessor because 'self'
is BitwiseCopyable, specify '@lifetime(borrow self)'
I don't know why the _read is synthesized in these cases, but apparently it's
always been that way.
Fixes: rdar://153773093 ([nonescapable] add a compiler feature to guard
~Escapable accessors when self is trivial)
(cherry picked from commit cc357f4f32)
The problem is that async_Main was setting an executor as its main executor
instead of an actor. This patch fixes the issue by just grabbing the main actor
instead.
rdar://153082633
(cherry picked from commit 862ef621c7)
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)
rdar://153681688
Instead fo counting the actual conformances, the logic took the size of the bit field, i.e. used the highest set bit, so when a type had a conditional conformance only on ~Escapable, but not on ~Copyable, it would still add 2 placeholders, but only fill one.
This may be useful for type layout of borrow fields in the future, should we
decide that addressable-for-dependencies borrows should always be represented
by a pointer. rdar://153650278
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)
