The C++ `SILFunctionType` exposes both `getResults()` (formal results only)
and `getResultsWithError()` (formal + error). The Swift mirror previously
only had `results`, bridging to the with-error variant. Add `formalResults`
for the formal-only view, matching the C++ split.
Switch PackSpecialization's three result-iteration sites to `formalResults`.
The bridged `createSpecializedFunctionDeclaration` preserves the error
result on its own, so iterating with-error included it twice in the new
function's signature.
Also forward the original apply's `nothrow`/`noasync` flags to the
specialized apply, required for SIL verification of a plain apply calling
a function with an error result.
The patch implements proper sil-combiner handling of
`differentiable_function` for cases when extractee has non-trivial
ownership. In such casese, it is consumed by the differentiable_function
instruction. We must copy the extractee before the consumption point so
the copy remains live afterward.
Fixes#88816
Fixes a miscompile when the index of `index_addr` is a negative integer constant. In this case two access paths were considered overlapping while in reality they reference two different array elements.
The miscompile manifested in the dead-store-elimination pass, but could potentially also show up in other passes, which use this utility.
https://github.com/swiftlang/swift/issues/77558
rdar://176820188
Fix lifetime diagnostics to consider an implicit initializer of a ~Escapable
type to be implicitly immortal. Required to handle Optional<~Escapable> stored
properties, such as:
struct Foo<Element: ~Escapable>: ~Escapable {
var element: Element?
@_lifetime(borrow c)
init<C>(c: borrowing C) {
// error: Lifetime-dependent variable 'self' escapes its scope
}
}
The fix is simply to remove a temporary safeguard that I put in place to
compensate for our incomplete closure lifetimes. We now have the complete
representation of lifetimes on closures, so don't need the safeguard.
Representationally, a function that returns a ~Escapable value but has no
dependendencies is immortal. This was always the intended design, but the
temporary safeguard treated these cases as implicitly bound to some local scope.
Removing this safeguard has the effect of:
- Variable intialization is immortal (it cannot depend on anything by
definition). The safety of the initializer is checked inside the implementation
of those expressions rather than the caller.
- Empty ~Escapable types have an implicit immortal initializer (why not?)
- Calls to a function with @_unsafeNonescapableResult but no @_lifetime
annotation produce an immortal value. This is reasonable, and we want to
deprecate this attribute as soon as possible anyway. It is not for general use.
This is currently blocking usage of BorrowingSequence, such as a hypothetical BorrowingSequenceMapSequenceIterator.
Fixes rdar://176561897 ([nonescapable] initialization of Optional fields reports
a lifetime escape)
Code like this currently looks like a lifetime escape:
struct Ref<T: ~Copyable & ~Escapable>: ~Escapable {
private let ref: Builtin.Borrow<T>
@_lifetime(borrow target)
init(_ target: borrowing T) {
self.ref = Builtin.makeBorrow(target)
}
}
This is blocking the implementation of `Ref<~Escapable>`.
Fixes rdar://176564359 ([nonescapable] support Builtin.makeBorrow in
lifetime diagnostics)
Currently, AutoDiff Closure Specialization pass iterates over all VJP
instructions and checks each of them against a set of conditions which
`partial_apply` of pullback must satisfy.
This logic could be re-implemented w/o loop, checking conditions in
opposite direction, starting from `return` instruction and transitively
going to defining instructions of operands (`tuple` and `partial_apply`
for the desired pullback case).
This is especially important for Embedded Swift because non de-virtualized deinits result in IRGen crashes.
Fixes a compiler crash in embedded
rdar://175984319
Rather than doing a standard swift runtime cast to an existential, explicitly check for the conforming instruction classes, which is much faster.
The new `isFullApplySite` and `isReturnInstruction` casting utilities are used in the (very few) time critical places in the optimizer.
After toolchain builders are upgraded to a compiler version which includes the fix for this problem (https://github.com/swiftlang/swift/pull/88270), we don't need this workaround anymore and the regular `as`/`is` casts can be used again.
Now the runtime casts doesn't show up prominently in compile-time profiling data anymore - even with a host compiler which doesn't implement fast type checks, yet.
rdar://173916206
Passing a C++ object to the TSanInOutAccess builtin resulted in an extra
temporary copy. This copy was not optimized out because the semantics of this
builtin was not understood by the optimizer. Teaching the utils that this
intrinsic does not actually modify the object, does not escape it,
and does not read it lets the optimizer eliminate this copy.
Strictly speaking, the test code that uses interop is not safe/correct,
this is why it had a lifetime issue.
rdar://173921363
Add a new --enable-caching option that enables compilation caching for both
C/C++ (via clang-cache as compiler launcher) and Swift code (via
-cache-compile-job flags when bootstrapping=hosttools).
New options:
- --enable-caching: main toggle, incompatible with --sccache/--distcc
- --caching-cas-path: CAS directory (default: $BUILD_ROOT/cas)
- --caching-depscan-socket: depscan daemon socket path
- --caching-plugin-path: CAS plugin library path
- --caching-plugin-option: CAS plugin options (repeatable)
- --caching-prefix-map: enable source/SDK/toolchain prefix mapping
- --caching-remote-service-path: remote caching service with auto
plugin inference from Xcode and implied prefix mapping
The build script starts a clang-cache depscan daemon with reliable cleanup
via atexit and SIGTERM handlers. Per-product build directories get .cas-config
and compilation-prefix-map.json files written automatically.
Caching flags are applied to all Swift host compilation targets: compiler
sources, pure-swift host libraries (ASTGen, macros), swift-syntax, and
the new runtime build when --build-runtime-with-host-compiler is used.
When not using --caching-remote-service-path, enables CAS backend
(-Xfrontend -cas-backend -Xllvm -cas-friendly-debug-info) unless
SWIFT_CACHE_DISABLE_MCCAS is set.
A ninja wrapper is generated at build/<subdir>/build-utils/ninja for
cached incremental builds outside the build-script.
rdar://155876033
Assisted-By: Claude
We cannot use spare bits or other overlapping storage layout tricks with fundamentally
address-only enums, and we can take advantage of this to do borrowing switches or other
in-place projections without copying the value. However, for resilient enums, the
implementation may use spare bit packing, but the type must be handled address-only
outside of its defining module, and we didn't have a way to express that with
borrowing switch. Optimization passes have also been running into problems with the
complexity that we were using `unchecked_take_enum_data_addr` sometimes as a pure
operation. This patch splits the instruction into three:
- `unchecked_inplace_enum_data_addr` represents a nondestructive in-place enum
projection. It is only allowed for enums whose projection operation is
nondestructive.
- `unchecked_take_enum_data_addr` represents a destructive enum projection,
invalidating the enum and leaving the payload to be further consumed.
This matches the current instruction's semantics.
- `unchecked_borrow_enum_data_addr` represents a borrowing enum projection.
The instruction takes a second operand for "scratch" space, which the
enum representation may be copied into in order to avoid invalidating the
enum value, so the result is dependent on the lifetime of both the
original enum and the scratch buffer. This allows for borrowing switches
over resilient enums.
`unchecked_borrow_enum_data_addr` is implemented by taking advantage of the
"address-only enums can't do spare bit optimization" property at runtime.
We inspect the operand type's bitwise-borrowability from its metadata. If
the type is bitwise-borrowable, then we are allowed to bitwise-copy the
enum to the scratch space and apply the projection to the scratch space,
preserving the original value. If the type is not bitwise-borrowable, then
we cannot use spare bit optimization in its layout, so we apply the
projection in-place.
Fixes rdar://174952822.
Now that we have generalized existentials in Embedded Swift, we also
have all of the infrastructure for metatypes. They're lazily
constructed on an as-needed basis, but otherwise work the same way as
in non-Embedded Swift.
Fixes rdar://145706221.
Keypath simplification can create new basic blocks when projecting
optional chain components (OptionalChainProjector splits the block and creates new conditional branches).
However, the Swift-side tryOptimizeKeypath was not notifying the pass manager about
CFG or instruction changes, leaving analyses like the dominator tree stale.
Fix this by calling notifyBranchesChanged() and notifyInstructionsChanged()
when tryOptimizeKeypath succeeds.
This reverts commit 338dd185e7.
The problem is already fixed and disabling the loadable-address pass causes other problems:
When the pass is disabled a `swiftself` attribute is missing for the stdlib `Hasher.finalize` declaration in LLVM IR.
This causes a mis-compile.
Required for Builtin.borrowAt. SILGen may generate dead borrow scopes for
loadable values used in a return expression that for a borrow access that uses
guaranteed_address convention.
rdar://175382154 (Enable load_borrow simplification at -Onone)
The [dynamic_lifetime] attribute represents that the stack location's initialization state is tracked dynamically via a boolean flag — it may be uninitialized at certain program points. TempLValueElimination pass can replace an alloc_stack [dynamic_lifetime] with a destination alloc_stack that does not have dynamic_lifetime. This results in invalid SIL which triggers verifier errors due to lifetime mismatches in some program paths in ossa.
This PR fixes this issue by bailing out of TempLValueElimination for alloc_stack [dynamic_lifetime] in ossa.
Resolves rdar://175097584
Support for existentials in Embedded Swift has been available for a
little while now and appears to be solid. Remove the ability to disable
them (via `-disable-experimental-feature EmbeddedExistentials`), both
because it simplifies the code and because it's an ABI break to
disable the feature.
**Explanation**: We would like untyped throws to be available in Embedded Swift when system allocator is available.
**Scope**: limited to Embedded Swift.
**Risk**: low due to isolated scope, additive nature of the change, and no adoption of untyped throws in Embedded Swift so far.
**Testing**: added new lit tests.
**Issue**: rdar://171325402
When the option `-remove-runtime-asserts` is used all `cond_fail` instructions are removed.
However, the cast optimizer inserts such unconditional fails for failing casts. This ended up in an infinite optimization loop in SILCombine.
The fix is
1. don't remove unconditional `cond_fail`s, even if with the `-remove-runtime-asserts` option. This also has the benefit that it enables later optimizations to remove all the dead code after such an unconditional `cond_fail`.
2. Don't optimize a failing cast if it is already preceded by an unconditional `cond_fail`
This bug was introduced by https://github.com/swiftlang/swift/pull/88258
Fixes a compiler hang
rdar://174185165
The original implementation of `mayAccessPointer` did look through `address_to_pointer` - `pointer_to_address` pairs and therefore not detect such pointers.
Fixes a miscompile
rdar://174268466
Optimizes protocol conformance checking by pre-populating vtables with conformance information for "fast-cast" protocols that have superclass constraints.
This optimization works by:
1. Identifying classes that are eligible for optimization (have fixed metadata layout, are not open access, and belong to the current module)
2. Finding protocols, enabled for fast casting nad that have superclass constraints and belong to the current module
3. Pre-computing conformance checks for these protocols and storing the results directly in the vtable, eliminating the need for runtime conformance lookups