If a pass forgot to call invalidateAnalysis but deleted some instructions, the pass-manager can fix this.
Currently following passes do not invalidate analysis when they change the SIL:
* LowerTupleAddrConstructor
* DestroyAddrHoisting
* MoveOnlyChecker
* PredictableDeadAllocationElimination
Ideally we should fix those passes. But with this addition in the pass-manager it's not strictly necessary.
Fixes a compiler crash.
Although it's not used anymore we still have to support it to be able to read old Swift.interface files which still contain the builtin.
rdar://144781646
Introduce a new experimental feature StrictSendableMetatypes that stops
treating all metatypes as `Sendable`. Instead, metatypes of generic
parameters and existentials are only considered Sendable if their
corresponding instance types are guaranteed to be Sendable.
Start with enforcing this property within region isolation. Track
metatype creation instructions and put them in the task's isolation
domain, so that transferring them into another isolation domain
produces a diagnostic. As an example:
func f<T: P>(_: T.Type) {
let x: P.Type = T.self
Task.detached {
x.someStaticMethod() // oops, T.Type is not Sendable
}
}
executing unknown code
This means we have to claw back some performance by recognizing harmless
releases.
Such as releases on types we known don't call a deinit with unknown
side-effects.
rdar://143497196
rdar://143141695
i```
swift\lib\SILOptimizer\Mandatory\MoveOnlyAddressCheckerUtils.cpp(2981): warning C5030: attribute [[clang::fallthrough]] is not recognized
```
Replace the use of `clang::fallthrough` with `LLVM_FALLTHROUGH` which
properly uses the C++ standard spelling (`[[fallthrough]]`) depending on
the compiler version.
Removes a workaround previously added to handle types that were
overlooked during a serializability detection pass. Now that the
pass has been refactored with instruction visitor, we can replace
it with assert.
Resolves rdar://137711038
It was used in the old redundant-load- and redundant-store-elimination passes which were replaced by new implementations.
TypeExpansionAnalysis is not used anymore.
PredictableMemoryAccessOptimizations has become unmaintainable as-is.
RedundantLoadElimination does (almost) the same thing as PredictableMemoryAccessOptimizations.
It's not as powerful but good enough because PredictableMemoryAccessOptimizations is actually only needed for promoting integer values for mandatory constant propagation.
And most importantly: RedundantLoadElimination does not insert additional copies which was a big problem in PredictableMemoryAccessOptimizations.
Fixes rdar://142814676
It's sufficient just to have a struct with a kind and a value. There
aren't any cases where the payload's original type benefits from being
statically preserved--they're only ever obtained as `SILValue`s. Keep
the type safety by way of constructors.
This is necessary to fix a recent OSSA bug that breaks common occurrences on
mark_dependence [nonescaping]. Rather than reverting that change above, we make
forward progress toward implicit borrows scopes, as was the original intention.
In the near future, all InteriorPointer instructions will create an implicit
borrow scope. This means we have the option of not emitting extraneous
begin/end_borrow instructions around intructions like ref_element_addr,
open_existential, and project_box. After that, we can also migrate
GuaranteedForwarding instructions like tuple_extract and struct_extract.
Currently, types from @_implementationOnly modules can be serialized into client modules if their
defining modules are SDK or system modules.
However, @_implementationOnly is intended to hide types from external clients, and may cause
the type’s metadata (e.g., field offsets) to be stripped. If such types are serialized and later
accessed by a client module, it can lead to linker errors due to the missing metadata.
This PR prevents all types imported with @_implementationOnly from being serialized.
Resolves rdar://144181455
The code here determined the borrow scope of an InteriorPointerOperand use of a borrow using
`visitBaseValueScopeEndingUses`, but it does so after rewriting the operand, so the base
value would sometimes be incorrect leading to missing `end_borrows` in the rewritten code.
Fixes rdar://133333278.
The return pointer may point into the materialized base value, so if the base needs
materialization, ensure that materialization covers any futher projection of the
value.
To find if all the uses are within a guaranteed value, we should find all borrow introducers.
swift::findOwnershipReferenceAggregate looks only through forwarding operations with single operands.
For simplicity, continue using swift::findOwnershipReferenceAggregate, but return false when it does
not find a borrow introducer.
