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)
Correctly generate dependency tracking for functions that return a non-Escapable
existential, such as:
func getMutableSpanWithOpaqueReturn(_ array: inout [Int]) -> any PAny & ~Copyable & ~Escapable
Previously, dependency insertion assumed that @out storage always initialized an
alloc_stack. But existentials are always boxed.
First, add a diagnostic to catch any missing dependency insertions now that
we're past the bootstrapping phase.
Then, generalize handling of dependency insertion to handle any access base as
long as it has a recognizable address source.
Fixes rdar://150388126 (Missing mark_dependence for opaque lifetime dependent
value)
Ensure that we always issue a diagnostic on error, but avoid emitting any notes that don't have source locations.
With implicit accessors and thunks, report the correct line number and indicate which accessor generates the error.
Always check for debug_value users.
Consistently handle access scopes across diagnostic analysis and diagnostic messages.
SwiftCompilerSources for Windows is now fully enabled, so there is no
longer any reason to gate these passes under an OS check.
commit d482ab73bc
Author: Hiroshi Yamauchi <hjyamauchi@gmail.com>
Date: Fri Dec 13 09:24:44 2024 -0800
Update the pinned toolchain for Windows and enable SwiftCompilerSources for Win/ARM64
With this approach, you cannot tell whether a parameter is addressable only
from the function type. Instead you need the SILValue that will be passed to the
call site.
Needed to diagnose MutableSpan and OutputSpan.
For now, simply remove the bailout and TODO. The next change will introduce more
logic to force a diagnostic error in rare cases that can't be handled completely.
Fixes rdar://143584461 (Extended exclusive borrow issues with
MutableSpan and OutputSpan)
Functional changes:
Improved modeling of dependence on local variable scopes.
For nested modify->read accesses, only extend the read accesses.
Avoid making a read access dependent on an inout argument.
The following needs to be an error to prevent span storage from being modified:
@lifetime(owner)
foo(owner: inout Owner) -> Span {
owner.span
}
Improve usability of borrowing trivial values (UnsafePointer). Allow:
let span = Span(buffer.baseAddress)
Ignore access scopes for trivial values.
Structural changes:
Delete the LifetimeDependenceUseDefWalker.
Encapsulate all logic for variable introducers within the LifetimeDependenceInsertion pass. Once mark_dependence instructions are inserted, no subsequent pass needs to think about the "root" of a dependence.
Fixes: rdar://142451725 (Escape analysis fails with mutations)
by -enable-experimental-feature NonescapableTypes
on the Windows platform
These passes do nothing unless the above feature flag is enabled, so
the only reason to run the pass is to exercise SwiftCompilerSources
and catch invalid SIL.
These passes rely on fundamental SwiftCompilerSources abstractions
which have not yet been tested outside of the passes. They don't yet
handle all SIL patterns, and SIL continues to evolve. We would like to
can these issues quickly as we hit them, but only if we have a way of
reproducing the failure. Currently, we don't have a way of reproducing
Windows-arm64 failures.
Workaround for:
rdar://128434000 ([nonescapable] [LifetimeDependenceInsertion]
Package resolution fails with arm64 Windows toolchain)
These were always redundant. And there is no way to emit them
correctly for valid OSA when the original dependence scope is in the
caller.
NFC without:
-enable-experimental-feature NonescapableTypes
-enable-lifetime-dependence-diagnostics
