It is valid to leak a value on paths into dead-end regions.
Specifically, it is valid to leak an `alloc_box`. Thus, "final
releases" in dead-end regions may not destroy the box and consequently
may not release its contents. Therefore it's invalid to lower such final
releases to `dealloc_stack`s, let alone `destroy_addr`s. The in-general
invalidity of that transformation results in miscompiling whenever a box
is leaked and its projected address is used after such final releases.
Fix this by not treating final releases as boundary markers of the
`alloc_box` and not lowering them to `destroy_addr`s and
`dealloc_stack`s.
rdar://158149082
When replacing an opened existential type with the concrete type, we didn't consider that the existential archetype can also be a "dependent" type of the root archetype.
For now, just bail in this case. In future we can support dependent archetypes as well.
Fixes a compiler crash.
rdar://158594365
Specifically for 6.2, we are making optimize hop to executor more conservative
around caller isolation inheriting functions. This means that we are:
1. No longer treating calls to caller isolation inheriting functions as having a
hop in their prologue. In terms of this pass, it means that when determining
dead hop to executors, we no longer think that a caller isolation inheriting
function means that an earlier hop to executor is not required.
2. Treating returns from caller isolation inheriting callees as requiring a
hop. The reason why we are doing this is that we can no longer assume that our
caller will hop after we return.
Post 6.2, there are three main changes we are going to make:
* Forward Dataflow
Caller isolation inheriting functions will no longer be treated as suspension
points meaning that we will be able to propagate hops over them and can assume
that we know the actor that we are on when we enter the function. Practically
this means that trees of calls that involve just nonisolated(nonsending) async
functions will avoid /all/ hop to executor calls since we will be able to
eliminate all of them since the dataflow will just propagate forward from the
entrance that we are already on the actor.
* Backwards Dataflow
A caller isolation inheriting call site will still cause preceding
hop_to_executor functions to be live. This is because we need to ensure that we
are on the caller isolation inheriting actor before we hit the call site. If we
are already on that actor, the hop will be eliminated by the forward pass. But
if the hop has not been eliminated, then the hop must be needed to return us to
the appropriate actor.
We will also keep the behavior that returns from a caller isolation inheriting
function are considered to keep hop to executors alive. If we were able to
propagate to a hop to executor before the return inst with the forward dataflow,
then we know that we are guaranteed to still be on the relevant actor. If the
hop to executor is still there, then we need it to ensure that our caller can
treat the caller isolation inheriting function as a non-suspension point.
rdar://155905383
(cherry picked from commit b3942424c8)
tryJoinIfDestroyConsumingUseInSameBlock replaces a copy with its operand
when there is no use of the copy's operand between the copy's forwarded consuming use
and the copy operand's destroy in the same block. It is illegal to do this transformation
when there is a non-consuming use of the copy operand after the forwarded consuming use of the copy.
The code checking this illegal case was not considerin the case where the consuming use of the copy
was in the same instruction as the non-consuming use of the copy operand.
rdar://154712867
Fix two IRGen tests that are failing on Android armv7 and disable eight ClangImporter, C++ Interop, and SILOptimizer tests, two of which that were already failing on other 32-bit platforms.
If a function has lifetime dependencies, disable FSO's dead param optimization. Dead params maybe dependency sources and we should not delete them. It is also problematic to dead code params that are not dependency sources, since lifetime dependent sources are stored as indices and deleting dead parameters will require recomputation of these indices.
I cherry-picked 4c1440735b8066d061c668d3b655955c1831f1dd to prevent merge
conflicts. I think these tests were updated by a subsequent PR. Rather than
cherry-picking more work, I just updated these tests since the change seemed
benign and that this kept the overall amount of cherry-picked commits small
(converting %$NUMBER to %kind$NUMBER for some ValueDecls).
SILGen already has an exception for this from -enable-actor-data-race-checks,
so there's no need for it, and it causes problems in actor inits.
Fixes rdar://155239032
The move-checker was assuming that any non-Copyable variable in a box must be
captured by a closure. The underlying problem is that the move-checker relies on
the best-effort AllocBoxToStack optimization to be perfect. But when
non-Escapable values depend on the variable, it remains boxed. That's good for
lifetime diagnostics but caused an incorrect move-checker diagnostic.
Fixes rdar://154519148 (Returning non-copyable type after accessing borrowed
field emits incorrect error about escaped closure capturing the noncopyable)
(cherry picked from commit 1b2fc8cbf9)
This is needed after running the SSAUpdater, because the updater can insert unnecessary phis in the middle of the original liverange of a value.
Fixes an ownership error.
rdar://153229472
Unlike addresses of indirect arguments, a pointer argument (e.g. `UnsafePointer`) can escape a function call.
For example, it can be returned.
Fixes a miscompile
rdar://154124497
Add a fake use for dead-end blocks. This allows gatherKnownLifetimeUses to be
used for local liveness by considering an "unreachable" instruction to generate
liveness. This is important when liveness is used as a boundary within which
access scopes may be extended. Otherwise, we are unable to extend access scopes
into dead-end blocks.
Fixes rdar://154406790 (Lifetime-dependent variable 'X' escapes its
scope but only if actor/class is final)
(cherry picked from commit 239255b8bc)
In OSSA, the result of an `unchecked_bitwise_cast` must immediately be
copied or `unchecked_bitwise_cast`'d again. In particular, it is not
permitted to borrow it. For example, the result can't be borrowed for
the purpose of performinig additional projections (`struct_extract`,
`tuple_extract`) on the borrowed value. Consequently, we cannot promote
an address if such a promotion would result in such a pattern. That
means we can't promote an address `%addr` which is used like
`struct_element_addr(unchecked_addr_cast(%addr))` or
`tuple_element_addr(unchecked_addr_cast(%addr))`. We can still promote
`unchecked_addr_cast(unchecked_addr_cast(%addr))`.
In ownership-lowered SIL, this doesn't apply and we can still promote
address with such projections.
rdar://153693915
The test was reenabled for the `swift_stdlib_asserts` context in
https://github.com/swiftlang/swift/pull/82559/ . That had the effect of
enabling it for noasserts builds. But the test uses subpass flags which
are only heeded in asserts builds. That behavior is disabled--the flags
are made always effective--in
https://github.com/swiftlang/swift/pull/82736 . But there's no reason
to take that change onto a release branch. Just disable the test again
in exactly the relevant configuration.
rdar://154499140
switch_enum_addr was being treated like a store instruction, which killed
the local enum's liveness. This could result local variable analysis reporting a
shorter lifetime for the local.
This showed up as a missing exclusivity diagnostic because an access scope was
not fully extended across a dependent local variable of Optional type.
This prevents the following pattern from miscompiling. It should report an exclusivity violation:
var mutableView = getOpaqueOptionalView(holder: &holder)!
mutate(&holder)
mutableView.modify()
Fixes rdar://151231236 ([~Escapable] Missing 'overlapping acceses' error when
called from client code, but exact same code produces error in same module)
(cherry picked from commit fe9c0dd735)
Narrowly fix a long-standing bug where destroy_addrs would be hoisted
into read access scopes, leaving the scope as a read despite the fact
that it modifies memory. This is a problem for utilities which expect
access scopes to provide correct summaries. Do this by refusing to fold
into access scopes which are marked `[read]`.
In a follow-up, we can reenable this folding, promoting each access
scope to a modify. Doing so requires checking that there are no access
scopes which overlap with any of the access scopes which would be
promoted to modify.
rdar://154407327
Bail if the closure captures an ObjectiveC block which might _not_ be copied onto the heap, i.e optimized by SimplifyCopyBlock.
We can't do this because the optimization inserts retains+releases for captured arguments.
That's not possible for stack-allocated blocks.
Fixes a mis-compile
rdar://154241245
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)
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)
This fix enables exclusive access to a MutableSpan created from an UnsafeMutablePointer.
The compiler has a special case that allows MutableSpan to depend on a mutable
pointer *without* extending that pointer's access scope. That lets us implement
standard library code like this:
mutating public func extracting(droppingLast k: Int) -> Self {
//...
let newSpan = unsafe Self(_unchecked: _pointer, byteCount: newCount)
return unsafe _overrideLifetime(newSpan, mutating: &self)
Refine this special case so that is does not apply to inout parameters where the
programmer has an expectation that the unsafe pointer is not copied when being
passed as an argument. Now, we safely get an exclusivity violation when creating
two mutable spans from the same pointer field:
@lifetime(&self)
mutating func getSpan() -> MutableSpan<T> {
let span1 = makeMutableSpan(&self.pointer)
let span2 = makeMutableSpan(&self.pointer) // ERROR: overlapping access
return span1
}
If we don't fix this now, it will likely be source breaking in the future.
Fixes rdar://153745332 (Swift allows constructing two MutableSpans to
the same underlying pointer)
(cherry picked from commit 7c5d4b8b6d)
--- CCC ---
Explanation: Fix MutableSpan exclusive access to unsafe pointers This
fix enables exclusive access to a MutableSpan created from an
UnsafeMutablePointer.
Scope: Affects users of MutableSpan when initializing them from an unsafe pointer.
Radar/SR Issue: rdar://153745332 (Swift allows constructing two
MutableSpans to the same underlying pointer)
main PR: https://github.com/swiftlang/swift/pull/82450
Risk: Low. This only affects users of an API that requires lifetime
dependence. Without using an experimental feature, this only applies
to the initializers of Mutable[Raw]Span.
Testing: Added source-level unit tests
Reviewer: TBD
Allow a dependence on Void to be considered immortal. This is the ultimate
override in cases where no other code pattern is supported yet.
(cherry picked from commit 36d2b5bee4)
