Add a case to LifetimeDependence.Scope to support dependencies on address-only
'let' variables. This comes up with C++ interop.
Fixes rdar://147500193 (Spurious lifetime error with closures)
(cherry picked from commit 5831777407)
This adds support to handle unsafe addressors, which generate mark_dependence
instructions with an address base. This case does not arise with lifetime
dependencies. Nonetheless, the lifetime dependence diagnostics kick in to
attempt to promote the unsafe addressor's mark_dependence to noescape, so we
need to handle it.
rdar://149784450 (Compiler crash with non-escapable deinit dereferencing)
(cherry picked from commit 3b08592ed2)
Allow a dependency on a local [read] access scope to be transfered to the
caller's [modify] access.
Fixes rdar://149560133 (Invalid lifetime dependence error when
trying to return Span from an inout argument)
(cherry picked from commit 33fbe11bf8)
Add support for returnValue phis (e.g. to return an Optional .some or .none).
Fixes rdar://149397018 (Wrapping non escapable in an Optional
(or any copy lifetime wrapper) is an escape)
(cherry picked from commit a1aaed9159)
Add support for extending owned temporary values in addition to access scopes
and borrow scopes. Required for _read accessors in which the coroutine depends
on an owned value.
(cherry picked from commit 62454f42fd)
We sometimes use LocalVariableUtils to analyze temporary storage in which the
store_borrow is not already enclosed by an access scope.
(cherry picked from commit 4e35d255ad)
Refactor VariableIntroducerUseDefWalker into a general
LifetimeDependenceUseDefWalker for use with LifetimeDependenceScopeFixup.
(cherry picked from commit b80bd16eea)
This allows further extension of access scopes.
Fixes rdar://143992296 (Use of `RawSpan` in switch context causes compiler crash
in AddressOwnershipLiveRange)
(cherry picked from commit c9279d9899)
This is only used for lifetime dependence diagnostics.
Fix a couple of obvious problems with data flow propagation that crept in during
"cleanup" because no unit tests existed.
(cherry picked from commit 37ecd0e9bd)
An address-type parameter may escape via an indirect argument if the function's
result depends on the argument's address.
(cherry picked from commit 05a9acbb40)
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
When performing a dynamic cast to an existential type that satisfies
(Metatype)Sendable, it is unsafe to allow isolated conformances of any
kind to satisfy protocol requirements for the existential. Identify
these cases and mark the corresponding cast instructions with a new flag,
`[prohibit_isolated_conformances]` that will be used to indicate to the
runtime that isolated conformances need to be rejected.
Fixes a false alarm in case of recursive calls with different type parameters.
For example:
```
protocol P {
associatedtype E: P
}
func noRecursionMismatchingTypeArgs1<T: P>(_ t: T.Type) {
if T.self == Int.self {
return
}
noRecursionMismatchingTypeArgs1(T.E.self)
}
```
The lifetime of yielded values always end at the end_apply.
This is required because a yielded address is non-aliasing inside the begin/end_apply scope, but might be aliasing after the end_apply.
For example, if the callee yields an `ref_element_addr` (which is encapsulated in a begin/end_access).
Therefore, even if the callee does not write anything, the effects must be "read" and "write".
Fixes a SIL verifier error
rdar://147601749
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.
The Protocol field isn't really necessary, because the conformance
stores the protocol. But we do need the substituted subject type
of the requirement, just temporarily, until an abstract conformance
stores its own subject type too.
