We were reusing the SILLocation from return instructions
to generate projections to ultimately destroy values.
This fix improves on what we were doing before, by
converting the insertion point's SILLocation into a
RegularLocation _without dropping_ the source location.
If the SILLocation was tied to an ASTNode, it'll carry
over the line location for this new regular location.
Otherwise, it'll fallback to the prior strategy of
producing a line 0 autogenerated location.
resolves rdar://163281183
A trivial store is allowed to occur on an existing live value, and should not
trigger an attempt to destroy the original value completely. Fixes rdar://147791932.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Like `?` or property access, `x!` can be borrowing, consuming, or mutated
through depending on the use site and the ownership of the base value.
Alter SILGen to emit `x!` as a borrowing operation when the result is only
used as a borrow. Fix the move-only checker not to treat the unreachable
branch as a dead path for values and try to destroy the value unnecessarily
and possibly out-of-order with cleanups on the value. Fixes rdar://127459955.
An empty struct without a deinit gets a single bit which is used to
track the struct's liveness. Previously, an empty struct with a deinit
also only got a single bit. Consequently, when discarding the struct
(i.e. dropping the deinit), there was no bit left to represent the
struct. This resulted in a failure to track liveness for the value.
rdar://126863003
Previously, the enum representation was fixed to represent the different
cases payloads separately with the unchecked_take_enum_data_addr
instruction consuming all fields but that whose address is obtained.
In a few places, handling for enum deinits was left undone with an
assertion that the enum not have one.
Here, the deinit bit of the enum is shifted to the end. And the
assertions are replaced with handling. Finally, the logic for inserting
destroys after switch_enum_addr instructions is fixed.
Change FieldSensitive's enum representation to allow distinguishing
among the elements with associated value. Consider
`unchecked_take_enum_data_addr` to consume all other fields than that
taken.
rdar://125113258
An instruction can consume multiple (discontiguous) fields. Use a
SmallBitVector to track the fields consumed by an instruction rather
than a TypeTreeLeafRange.
rdar://125103951
A `try_apply` with indirect out arguments is only a def for those arguments on
the success path. Model this by sinking the def-ness of the instruction into the
success branch of the try_apply, and introducing a new `DeadToLiveEdge` mode for
block liveness which stops propagation of use-before-def conditions into the
block that introduced the def. Fixes rdar://118567869.
Fill in a missing path for destructuring loadable elements from
address-only tuples in a borrowing context. Enclose projections in their
own separate accesses so that they are analyzed independently by the
move checker.
Relax some existing pattern matches and add some unhandled instructions to the
walkers so that borrowing switches over address-only enums are properly analyzed
for incorrect consumption. Add a `[strict]` flag to `mark_unresolved_move_only_value`
to indicate a borrow access that should remain a borrow access even if the subject
is later stack-promoted from a box.
In the C++ sources it is slightly more convenient to dump to stderr than
to print to stdout, but it is rather more unsightly to print to stderr
from the Swift sources. Switch to stdout. Also allows the dump
functions to be marked debug only.
And use it in lifetime maximization.
The preexisting member function updateForUse has been updated to match
PrunedLiveness and gravitate towards lifetimeEnding=false.
For a fixed instruction and bit, if called with lifetimeEnding=true and
then lifetimeEnding=false, the lifetime-ending-ness of the instruction
at the bit will be false; and if it is again called with
lifetimeEnding=true, the lifetime-ending-ness of the instruction at the
bit will remain false.
In contrast the new member function extendToUse does not alter the
lifetime-ending-ness if it is already set. If it is unset, the function
sets the bit to lifetimeEnding=false.
Also, the store_borrow work in the previous patch caused some additional issues
to crop up. I fixed them in this PR and added some tests in the process.
This is similar to our ban on partial consuming a value for this release. The
reason for this is that, one can achieve a similar affect as partial consumption
via a consumption of the entire value and then a partial reinitialization. Example:
```swift
struct X : ~Copyable { var i = 5, var i2 = Klass() }
var x = X()
_ = consume x
x.i = 5
```
in the case above, we now have a value that is in a partially initialized state.
We still allow for move only types to have their fields initialized as long as
there is an intervening init.
rdar://111498740
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
Track liveness of self so we don't accidentally think that such types
can be memberwise reinitialized.
Fixes rdar://110232973 ([move-only] Checker should distinguish in
between field of single field struct vs parent field itself (was:
mutation of field in noncopyable struct should not trigger deinit))
The address checker records uses in its livenessUses map. Previously,
that map mapped from an instruction to a range of fields of the type.
But an instruction can use multiple discontiguous fields of a single
value. Here, such instructions are properly recorded by fixing the map
to store a bit vector for each instruction.
rdar://110676577
FieldSensitivePrunedLiveness is used as a vectorization of
PrunedLiveness. An instance of FSPL with N elements needs to be able to
represent the same states as N instances of PL.
Previously, it failed to do that in two significant ways:
(1) It attempted to save space for which elements were live by using
a range. This failed to account for instructions which are users of
non-contiguous fields of an aggregate.
apply(
@owned (struct_element_addr %s, #S.f1),
@owned (struct_element_addr %s, #S.f3)
)
(2) It used a single bit to represent whether the instruction was
consuming. This failed to account for instructions which consumed
some fields and borrowed others.
apply(
@owned (struct_element_addr %s, #S.f1),
@guaranteed (struct_element_addr %s, #S.f2)
)
The fix for (1) is to use a bit vector to represent which elements
are used by the instruction. The fix for (2) is to use a second bit
vector to represent which elements are _consumed_ by the instruction.
Adapted the move-checker to use the new representation.
rdar://110909290
The reason why I am using a different instruction for addresses and objects here
is that the object checker doesnt have to deal with things like initialization.
I think this was a mistake from when I changed implementations to use pure
scalar bit processing rather than processing all at once. Instead of just
updating the internal found resulting uses array, we were appending to it.
Some notes:
1. This actually did not break anything semantically in the move checker since
we do not use this array in the caller in anyway. We just use it internally in
the routine to first lookup the current state which we then process in the
routine. That being said, this API is written such that a user /could/ do that
and we want to allow for users to be able to do that so that we match what
PrunedLiveness does.
2. This could cause memory corruption due to iterator invalidation if by
appending we caused the SmallVector to reallocate as we iterated over the
array.
So to fix this I did the following:
a. I changed the push_back to be an assignment.
b. I removed llvm::enumerate just out of paranoia if the assignment could
potentially cause iterator invalidation.
The given test exercises this code path and with the old behavior would crash
with asan or guard malloc.
rdar://109673338
This will let the non-field sensitive version use a more performant
implementation internally. This is important since PrunedLiveBlocks is used in
the hot path when working with Ownership SSA, while the field sensitive version
is only used for certain diagnostics.
NOTE: I did not refactor PrunedLiveness to use the faster implementation... this
is just a quick pass over the code to prepare for that change.
Specifically:
1. I added to the documentation at the top of the file that our representation
allows for partial init/reinit of structs/tuples from parts.
2. I renamed SubElementNumber to SubElementOffset. This I think fits the actual
use case better and makes it clearer what one is working with (the offset inside
a type of a subelement of the type).
3. I added some small helpers to TypeSubElementCount and SubElementOffset for
adding/subtracting from them.
4. I added the ability to iterate over just consuming/nonconsuming users in
FieldSensitivePrunedLiveness. Just a useful little helper.
