When a non-Escapable value depends on the address of a trivial value, we use a
special computeAddressableRange analysis to compute the trivial value's
scope. Extend that analysis to include unreachable paths.
Fixes this pattern:
inlineStorage.span.withUnsafeBytes
where inlineStorage is a trivial type defined in the user module. This
does not reproduce directly with InlineArray, but it is a problem for
user modules that have their own trivial wrapper around an InlineArray.
Fixes rdar://161630684 (Incorrect diagnostic: lifetime-dependent value escapes its scope)
(cherry picked from commit 98b7d5906cffa0cf7a481ba47a6acd746e388ac9)
* Fix the right shift operator which didn't work if the number of bits is exactly 64
* Detect overflow when combining indices
Such large indices usually don't appear in real code, except in internal String operations where (potentially large) integer values are treated as pointers.
Fixes a compiler crash
https://github.com/swiftlang/swift/issues/84372
rdar://160863199
When the source of a lifetime dependency is a stack-allocated address, extend
the stack allocation to cover all dependent uses.
This avoids miscompilations for "addressable" dependencies which arise in code
built with -enable-experimental-feature AddressableTypes or
AddressableParameters. It is always an error for SILGen to emit the alloc_stack
in such cases. Nonetheless, we want to handle these unexpected cases gracefully
in SIL as a diagnostic error rather than allowing a miscompile.
Fixes rdar://159680262 ([nonescapable] diagnose dependence on a
temporary copy of a global array)
(cherry picked from commit 7dfd1057111425d3902b1b17cd2129c94f974027)
Add a diagnostic to catch addressable dependencies on a trivial values that have
been copied to a temporary stack location. SILGen should never copy the source
of an addressable dependency to a temporary stack location, but this diagnostic
catches such compiler bugs rather than allowing miscompilation.
Fixes rdar://159680262 ([nonescapable] diagnose dependence on a temporary copy
of a global array)
Extend temporary allocations (sink dealloc_stacks) initialized by a store_borrow
across lifetime dependent uses.
Fixes rdar://143159873 ([nonescapable] extend rvalue lifetimes when they are the source of a dependency)
(cherry picked from commit 288cef1532)
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
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)
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)
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)
Consider an empty tuple to be a value introducer rather than a forwarding
instruction.
Fixes rdar://153978086 ([nonescapable] compiler crash with dependency on an
expression)
(cherry picked from commit bcc4a78c42)
When extending a coroutine, handle the end_borrow instruction used to end a
coroutine lifetime at a dead-end block.
Fixes rdar://153479358 (Compiler crash when force-unwrapping optional ~Copyable type)
(cherry picked from commit 5b5f370ce1)
It used to also set it for functions which are referenced from a global with a const/section attribute - even if not performance attribute was present in the whole module. This is unnecessary and can lead to worse code generation.
rdar://152665294
When extending an access scope over a coroutines, instead of simply
considering the lifetime of the coroutine scope, recurse through all
uses of yielded values. They may be copyable, non-Escapable values
that depend on the coroutine operand.
Fixes rdar://152693622 (Extend coroutines over copied yields)
(cherry picked from commit 227f8028e8)
Add support for diagnosing calls to closures that return a generic
non-Escapable result.
Closures do not yet model lifetime dependencies. The diagnostics have
a special case for handling nonescaple result with no lifetime
dependence, but it previously only handled direct results. This fix handles
cases like the following:
func callIndirectClosure<T>(f: () -> NE<T>) -> NE<T> {
f()
}
Fixes rdar://134318846 ([nonescapable] diagnose function types with nonescapable results)
(cherry picked from commit 1d09c06ab1)
When de-serializing a function and this function allocates a class, the methods of the de-serialized vtable must be handled, too.
Fixes an IRGen crash
rdar://152311945
The function convention for the first argument is not identified as indirect-out.
This lets alias analysis assume that the memory pointed to by argument 0 cannot be written by the called function.
The problem is that subscripting a LazyFilterCollection (with the base index, e.g. `Int`) does not work as expected, because it returns the nth element of the base collection!
The fix is to implement the subscript "manually".
Fixes a mis-compile.
rdar://152160748
This prevents simplification and SILCombine passes to remove (alive) `mark_dependence_addr`.
The instruction is conceptually equivalent to
```
%v = load %addr
%d = mark_dependence %v on %base
store %d to %addr
```
Therefore the address operand has to be defined as writing to the address.
If the block is passed to another function - either as closure argument or as closure capture - it's "converted" to a swift closure with the help of a thunk. The thunk just calls the block.
If this is done with a non-escaping partial_apply, the block does not escape.
rdar://149095630
As SourceKit explicitly disables WMO, silence the diagnostic in this case (but leave it enabled for explicit non-WMO builds otherwise).
rdar://150596807
This utility is used by DependentAddressUseDefWalker which now conservatively
follows all possible uses. This could result in the same address being reached
multiple times during a def-use walk. Ensure that we don't infinitely recurse.
There is no small test case for this, but the fix is trivial and standard
practice for such walkers, and this is hit quickly in real usage, so there is no
danger of it regressing.
Fixes rdar://150403948 ([nonescapable] Infinite recursion compiler crash in
lifetime dependence checking)
(cherry picked from commit 4512927d2b)
