The reason why we want to do this is that if we treat it as a true forwarding
use, we will visit the uses of the trivial value and treat those as liveness
uses. Since the trivial value is not tied to the lifetime of the underlying
noncopyable value, this can be outside of the lifetime of said value causing a
memory lifetime error. By just treating the guaranteed forwarding instruction
with all trivial values as a liveness use, we avoid this problem.
I added a SIL test, a Swift test, and an Interpreter test that validates this
behavior.
rdar://111497657
On recent main, this test case fails verification with
```
SIL memory lifetime failure in @$s4main4doityyF: memory is not initialized, but should be
memory location: %21 = struct_element_addr %20 : $*M4, #M4.s2 // user: %23
at instruction: %23 = apply %22(%19, %21) : $@convention(thin) (@inout S, @inout S) -> ()
[...]
4. While running pass #173 SILFunctionTransform "MoveOnlyChecker" on SILFunction "@$s4main4doityyF".
for 'doit()' (at test/Interpreter/moveonly_reinit_noncontiguous.swift:32:1)
```
Per the clarification during the review thread, all properties with
init accessors (including those that do not initialize any underlying
storage) are part of the memberwise initializer.
The reason why I am doing this is that this was not part of the original
evolution proposal (it was called an extension) and after some discussion it was
realized that partial consumption would benefit from discussion on the forums.
rdar://111353459
* [IRGen+Runtime] Layout string getEnumTag for fixed size enums subset
getEnumTag impl for layout strings of fixed sized enums that use a function to fetch the enum tag
* Fix potential UB in IRGen
SILGen introduces a copy of the capture, because the semantics of escaping partial_apply's
requires the closure to take ownership of the parameters. We don't know when a closure is
strictly nonescaping or its final lifetime until ClosureLifetimeFixup runs, but that replaces
the consume of the copy with a borrow of the copy normally, hoping later passes fix it up.
We can't wait that long for move-only types, which can't be copied, so try to remove the
copy up front when the copy lives long enough and has no interfering uses other than the
partial_apply. rdar://110137169
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))
Previously, the checker inserted destroys after each last use. Here,
extend the lifetimes of fields as far as possible within their original
(unchecked) limits.
rdar://99681073
* [IRGen] Use EnumImplStrategy to generate getEnumTag function for layout strings
rdar://110794898
The implementation in TypeLayout seems to have a bug causing wrong tags to be returned on 32 bit systems.
* Don't use unsupported types in tests
Skip stored properties that are initialized via init accessors and
emit parameters/initializations in field order which allows us to
cover more use-cases.
If some property is initializable by one than one init accessor
let's not sythesize a memberwise initializer in that case because
it's ambiguous what is the best init accessor to use.
If init accessor initialize the same properties, let's emit them
in sequence and emit `destroy_addr` in-between to make sure that
there is no double initialization.
SIL Functions are serialized in canonical SIL before they have their final ABI
adjusted for large function arguments. Large function argument ABI is adjusted
to be indirect as part of the transition from canonical SIL to lowered SIL. This
means that if we deserialize a function from another module in canonical SIL and
attempt to call it in IRGen we will call it with the wrong ABI implying if we
reference any fields of the type in the deinit we will most likely crash (among
other potential issues).
This patch fixes the issue by changing IRGen to not lazily deserialize the
moveonly deinit table and its associated functions. Instead if we do not have
our table already deserialized, we just call the function's deinit via the
destroy value deinit table.
rdar://110496872
