We need the self metatype parameter to correctly lower
DynamicSelfType in IRGen, so plumb this through to all
calls of init accessors, and inside the prolog of an
init accessor definition.
This does not break the public ABI, because init
accessors are never public. Also for value types, the
metatype is thin, so it should not change generated
code.
For classes we need the metatype in the general case
because of `Self`, but hopefully in most cases the
init accessor can be inlined away and the value_metatype
instruction subject to dead code elimination.
Fixes rdar://problem/119822466.
In address-lowered mode, to initialize tuple-typed memory in a single
step, tuple_addr_constructor must generally be used because it's not
possible to construct a tuple any of whose fields are address-only. In
opaque values mode, there is no problem constructing such a tuple. So
construct the tuple and then assign it into the tuple-typed memory; the
single instruction that initializes the memory will be the assign.
Fix a leak when emitting the native to foreign thunk for an async
function which fulfills an Objective-C protocol requirement which can be
fulfilled with either a value or an error via a nullable completion.
Previously, the SIL in question used to look like this:
```sil
%maybe_completion = ...
try_apply %impl..., normal success, ...
success(%value):
switch_enum %maybe_completion...
case some!enumelt: invoke
case none!enumelt: ignore
ignore:
br join
invoke(%completion):
%some_value = enum Optional, some!enumelt, %value // consumes %value
%guaranteed_some_value = begin_borrow %some_value
%none_error = enum Optional, none!enumelt
apply %completion(%guaranteed_some_value, %none_error)
end_borrow %guaranteed_some_value
destroy_value %some_value
br join
join:
destroy_value %maybe_completion
...
```
which leaks %value on the codepath through `ignore`.
Note that `%value` is consumed by the `enum` instruction, but
`%completion` is invoked with `%guaranteed_some_value`, a guaranteed
value. So there is no need to consume %value in `invoke`.
Here, `%value` itself is borrowed and forwarded into an enum instruction
whose result is passed to `%completion`:
```sil
%maybe_completion = ...
try_apply %impl..., normal success, ...
success(%value):
switch_enum %maybe_completion...
case some!enumelt: invoke
case none!enumelt: ignore
ignore:
br join
invoke(%completion):
%guaranteed_value = begin_borrow %value
%guaranteed_some_value = enum Optional, some!enumelt, %guaranteed_value
%none_error = enum Optional, none!enumelt
apply %completion(%guaranteed_some_value, %none_error)
end_borrow %guaranteed_some_value
br join
join:
destroy_value %maybe_completion
destroy_value %value
...
```
Because an argument scope was already being created and a cleanup was
already being pushed for `%value`, nothing more is required to fix the
issue than to reorder the enum and the borrow.
rdar://119732084
The dependent 'value' may be marked 'nonescaping', which guarantees that the
lifetime dependence is statically enforceable. In this case, the compiler
must be able to follow all values forwarded from the dependent 'value', and
recognize all final (non-forwarded, non-escaping) use points. This implies
that `findPointerEscape` is false. A diagnostic pass checks that the
incoming SIL to verify that these use points are all initially within the
'base' lifetime. Regular 'mark_dependence' semantics ensure that
optimizations cannot violate the lifetime dependence after diagnostics.
patterns) in argument positions in reabstraction thunks.
Most of the difficulty in this work continues to center around
(1) trying to reuse as much code as possible between the parameter
and result paths and (2) propagating ownership information as
necessary throughout the code. I did my best to assert the preconditions
and postconditions here, but undoubtedly I'm missing cases. Some
simplicity here is still eluding me here.
This patch necessarily changes quite a bit of the code used in
non-variadic paths. I tried to avoid doing things that I knew would
be risky, like optimizing copies. I did fail in a few places: e.g.
we should now generate significantly better code when erasing to
Optional<Any>, just because the code was oddly poorly-factored before.
You can see the effect on the function_conversion test case.
The `_diagnoseUnavailableCodeReached()` function was introduced in the Swift
5.9 standard library and employs `@backDeployed` to support compilation of
binaries that target OS releases aligned with earlier Swift releases.
Unfortunately, though, this backdeployment strategy doesn't work well for some
unusual build environments. Specifically, in some configurations code may be
built with a compiler from a recent Swift toolchain and then linked against the
dylibs in an older toolchain. When linking against the older dylibs, the
`_diagnoseUnavailableCodeReached()` function does not exist but the
`@backDeployed` thunks emitted into the binary reference that function and
therefore linking fails.
The idea of building with one toolchain and then linking to the dylibs in a
different, older toolchain is extremely dubious. However, it exists and for now
we need to support it. This PR introduces an alternative
`_diagnoseUnavailableCodeReached()` function that is annotated with
`@_alwaysEmitIntoClient`. Calls to the AEIC variant are now emitted by the
compiler when the deployment target is before Swift 5.9.
Once these unusual build environments upgrade and start linking against a Swift
5.9 toolchain or later we can revert all of this.
Resolves rdar://119046537
For an isolated ObjC function that is not async, we
emit a hops around the call. But if that function
returns an autoreleased pointer, we need to ensure
we're retaining that pointer before hopping back
after the call. We weren't doing that in the case
of an autoreleased NSError:
```
%10 = alloc_stack $@sil_unmanaged Optional<NSError>
%19 = ... a bunch of steps to wrap up %10 ...
%20 = enum $Optional<AutoreleasingUnsafeMutablePointer<Optional<NSError>>>, #Optional.some!enumelt, %19 : $AutoreleasingUnsafeMutablePointer<Optional<NSError>>
hop_to_executor $MainActor
%26 = apply X(Y, %20) : $@convention(objc_method) (NSObject, Optional<AutoreleasingUnsafeMutablePointer<Optional<NSError>>>) -> @autoreleased Optional<NSString>
hop_to_executor $Optional<Builtin.Executor>
// retain the autoreleased pointer written-out.
%28 = load [trivial] %10 : $*@sil_unmanaged Optional<NSError>
%29 = unmanaged_to_ref %28 : $@sil_unmanaged Optional<NSError> to $Optional<NSError>
%30 = copy_value %29 : $Optional<NSError>
assign %31 to %7 : $*Optional<NSError>
```
This patch sinks the hop emission after the call
so it happens after doing that copy.
rdar://114049646
Mark the result of a move-only addressor as unresolved. The pointed-at value
cannot be consumed so ensure that only [read] or [modify] accesses are
performed. Update the move-only checker to recognize code patterns
from addressors.
SILGen and IRGen would disagree on the return type of the
`swift_task_getMainExecutor()` runtime function if
`SILGenModule::getGetMainExecutor()` had ever been called. To address this,
consistently use the `buildMainActorExecutorRef` built-in and get rid of
`SILGenModule::getGetMainExecutor()`.
Resolves rdar://116472583
Correctly determining the DeclContext needed for an
ExplicitCaughtTypeRequest is tricky for a number of callers, and
mistakes here can easily lead to redundant computation of the caught
type, redundant diagnostics, etc.
Instead, put a `DeclContext` into `DoCatchStmt`, because that's the
only catch node that needs a `DeclContext` but does not have one.
Following https://github.com/apple/swift/pull/70333, do the same thing for
modify coroutines, marking the result so that we check uses of the result to
ensure it isn't consumed (without being reinitialized).
Mark the result of starting a read coroutine to be checked by the move-only checker, and then
update the pattern matching in the move checker itself so that it recognizes code patterns
involving yielding from and receiving yields from read coroutines. Teach move only diagnostics
to get the property name for an access through a read coroutine from the referenced declaration.
