We need to compare the not lowered types, because function types may differ in their original version but are equal in the lowered version, e.g.
```
((Int, Int) -> ())
(((Int, Int)) -> ())
```
Fixes a miscompile
We need to ignore such casts because otherwise the constructed walking path wouldn't contain the right `existential` field kind.
Fixes a miscompile caused by redundant load elimination.
rdar://132364917
Invalid types are not considered Escapable. This makes it difficult to make any
assumptions about nonescapable types.
Fixes rdar://132348528 (Fix LifetimeDependenceDiagnostics to handle invalid SIL types)
These projections don't have access scopes, so the utility was treating them
like escapes.
Fixes: rdar://131499478 (Difficulties composing non-escapable types)
This corresponds to the parameter-passing convention of the Itanium C++
ABI, in which the argument is passed indirectly and possibly modified,
but not destroyed, by the callee.
@in_cxx is handled the same way as @in in callers and @in_guaranteed in
callees. OwnershipModelEliminator emits the call to destroy_addr that is
needed to destroy the argument in the caller.
rdar://122707697
VS 17.10 introduced a requirement on Clang 17, but the pinned Swift
toolchain used to bootstrap the compilers (a 5.10 snapshot) uses Clang 16. We
can relax this version requirement with ALLOW_COMPILER_AND_STL_VERSION_MISMATCH
which needs to be set for all CMAKE_Swift_FLAGS when building the
compilers, as well as explicitly in SwiftCompilerSources as the
invocation of swiftc there is via custom_command
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)
When visiting consumes, also visit `extend_lifetime` instructions.
These instructions are not lifetime ending, but together with the
consumes, they enclose the users of a value.
Add a flag to LinearLiveness to control whether these instructions are
added so that the verifier can use verify that all such instructions
appear outside the linear lifetime boundary (not including them).
It indicates that the value's lifetime continues to at least this point.
The boundary formed by all consuming uses together with these
instructions will encompass all uses of the value.
The OSSA elimination pass has not yet been moved below all high level
function passes. Until that work has been completed the Autodiff
closure-spec optimization pass cannot solely support OSSA instructions.
The buffer of global arrays could already be statically initialized.
The missing piece was the array itself, which is basically a reference to the array buffer.
For example:
```
var a = [1, 2, 3]
```
ends up in two statically initialized globals:
1. the array buffer, which contains the elements
2. the variable `a` which is a single reference (= pointer) of the array buffer
This optimization removes the need for lazy initialization of such variables.
rdar://127757554
