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)
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)
Add a note explaining that dependence on closure captures is not
supported. Otherwise, the diagnostics are very confusing:
"it depends on a closure capture; this is not yet supported"
(cherry picked from commit 83b0ce1098)
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.
(cherry picked from commit ec512864eb)
Briefly (April 2025), RawSpan._extracting, Span._extracting, and UTF8Span.span
returned a borrowed value that depended on a copied argument. Continue to
support those interfaces. The implementations were correct but needed an
explicit _overrideLifetime.
(cherry picked from commit 8a48cd979b)
Diagnose a scoped dependence on an argument that inherits its lifetime as an
error:
@lifetime(borrow arg)
func reborrowSpan<T>(_ arg: Span<T>) -> Span<T> { arg }
@lifetime(copy span)
public func testBorrowInheritedArg<T>(_ span: Span<T>) -> Span<T> {
reborrowSpan(span) // expected-error {{lifetime-dependent value escapes its scope}}
}
Fixes: rdar://146319009 ([nonescapable] enforce borrow constraint narrowing of inherited lifetime)
(cherry picked from commit 4f470a1d34)
Refactor VariableIntroducerUseDefWalker into a general
LifetimeDependenceUseDefWalker for use with LifetimeDependenceScopeFixup.
(cherry picked from commit b80bd16eea)
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
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)
Briefly, some versions of Span in the standard library violated trivial
lifetimes; versions of the compiler built at that time simply ignored
dependencies on trivial values. For now, disable trivial dependencies to allow
newer compilers to build against those older standard libraries. This check is
only relevant for ~6 mo (until July 2025).
Add `Value.constantAccessPath`. It is like `accessPath`, but ensures that the projectionPath only contains "constant" elements.
This means: if the access contains an `index_addr` projection with a non-constant index, the `projectionPath` does _not_ contain the `index_addr`.
Instead, the `base` is an `AccessBase.index` which refers to the `index_addr`.
As the optimizer uses more and more AST stuff, it's now time to create an "AST" module.
Initially it defines following AST datastructures:
* declarations: `Decl` + derived classes
* `Conformance`
* `SubstitutionMap`
* `Type` and `CanonicalType`
Some of those were already defined in the SIL module and are now moved to the AST module.
This change also cleans up a few things:
* proper definition of `NominalTypeDecl`-related APIs in `SIL.Type`
* rename `ProtocolConformance` to `Conformance`
* use `AST.Type`/`AST.CanonicalType` instead of `BridgedASTType` in SIL and the Optimizer
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)
ClosureLifetimeFixup now emits mark_dependence [nonescaping]. Those should be
ignored by diagnostics. In the capture case, the dependence has already been
resolved, and may not match the SIL patterns that we expect for source-level
lifetime dependencies.
Fixes rdar://125375685 ([nonescapable] Fix lifetime-dependence diagnostics in the stdlib)
Don't treat StoreBorrow addresses as unknown bases. While they are never the base of a formal access, they are returned
as the AccessBase when querying the enclosing scope of an address.
SILBoxTypes have their own generic signature and substitution
map. This means that every time we query isEscapable or mayEscape, we
need to extract the type of the box's field and perform type
substitution so that the AST query only sees types from the function's
generic environment.
Fixes rdar://124179106 (Assertion failed in SIL:
(!type->hasTypeParameter() && "caller forgot to mapTypeIntoContext!"))
