Looking at the AST-level `getReadImpl` doesn't always correspond to what
accessor SILGen prefers to use, due to resilience, ABI rules, and other
concerns. In findStorageReferenceExprForMoveOnly, when determining whether
a storage reference is borrowable, use the same logic as SILGenLValue actually
uses to determine what storage or accessor access strategy to use.
Fixes rdar://142509673
This attribute makes it so that a parameter of the annotated type, as well as
any type structurally containing that type as a field, becomes passed as
if `@_addressable` if the return value of the function has a dependency on
the parameter. This allows nonescapable values to take interior pointers into
such types.
Right now it is basically a version of nonisolated beyond a few simple cases
like constructors/destructors where we are pretty sure we want to not support
this.
This is part of my bringup strategy for changing nonisolated/unspecified to be
caller isolation inheriting.
Fixes a correctness issue with unsafe addressors: `unsafeAddress` and
`unsafeMutableAddress`. Previously, the resulting `Unsafe[Mutable]Pointer` did
not depend on `self`, meaning that the compiler is allowed to destroy `self`
before any uses of the pointer. This happens to be valid for
`UnsafePointer.pointee` because, in that case, `self` does not have a lifetime
anyway; the correctness burden was on the programmer to use
`withExtendedLifetime` around all uses of `self`.
Now, unsafe addressors can be used for arbitrary `Self` types.
This also enables lifetime dependence diagnostics when the addressor points to a
`~Escapable` type.
Addressors can now be used as an implementation of borrowed properties.
Many APIs using nonescapable types would like to vend interior pointers to their
parameter bindings, but this isn't normally always possible because of representation
changes the caller may do around the call, such as moving the value in or out of memory,
bridging or reabstracting it, etc. `@_addressable` forces the corresponding parameter
to be passed indirectly in memory, in its maximally-abstracted representation.
[TODO] If return values have a lifetime dependency on this parameter, the caller must
keep this in-memory representation alive for the duration of the dependent value's
lifetime.
When the CoroutineAccessors feature is enabled, `begin_apply`
instructions produce an additional result representing the allocation
done by the callee. Fix a couple of cases where this additional result
was not being handled.
Instead of doing the pattern parsing in both the
C++ parser and ASTGen, factor out the parsing into
a request that returns the pattern to emit, regex
type, and version. This can then be lazily run
during type-checking.
When its operand has coroutine kind `yield_once_2`, a `begin_apply`
instruction produces an additional value representing the storage
allocated by the callee. This storage must be deallocated by a
`dealloc_stack` on every path out of the function. Like any other stack
allocation, it must obey stack discipline.
Temporarily allow the legacy behavior of allowing caller coroutine
accessors to observe errors (i.e. by executing no code after the yield
if the caller threw an error) behind the
CoroutineAccessorsUnwindOnCallerError flag.
Experience with `_modify`/`_read` has shown that it is never desireable
to cleanup differently based on whether the caller has thrown. Emit an
`end_apply` in either case.
This requires two major changes.
The first is that we need to teach SILGen that the isolation of an initializer
is essentially dynamic (as far as SILGen is concerned) --- that it needs to emit
code in order to get the isolation reference. To make this work, I needed to
refactor how we store the expected executor of a function so that it's not
always a constant value; instead, we'll need to emit code that DI will lower
properly. Fortunately, I can largely build on top of the work that Doug previously
did to support #isolation in these functions. The SIL we emit here around delegating
initializer calls is not ideal --- the breadcrumb hop ends up jumping to the
generic executor, and then DI actually emits the hop to the actor. This is a little
silly, but it's hard to eliminate without special-casing the self-rebinding, which
honestly we should consider rather than the weirdly global handling of that in
SILGen today. The optimizer should eliminate this hop pretty reliably, at least.
The second is that we need to teach DI to handle the pattern of code we get in
delegating initializers, where the builtin actually has to be passed the self var
rather than a class reference. This is because we don't *have* a class reference
that's consistently correct in these cases. This ended up being a fairly
straightforward generalization.
I also taught the hop_to_executor optimizer to skip over the initialization of
the default-actor header; there are a lot of simple cases where we still do emit
the prologue generic-executor hop, but at least the most trivial case is handled.
To do this better, we'd need to teach this bit of the optimizer that the properties
of self can be stored to in an initializer prior to the object having escaped, and
we don't have that information easily at hand, I think.
Fixes rdar://87485045.
It should no longer be necessary to provide an `@_alwaysEmitIntoClient` version
of `_diagnoseUnavailableCodeReached()`. This workaround was originally added to
provide compatibility with projects that were misconfigured to compile against
a newer stdlib but link against an older one.
Resolves rdar://119892482.
This corresponds to the parameter-passing convention of the Itanium C++
ABI, in which the argument is passed indirectly and possibly modified,
but not destroyed, by the callee.
@in_cxx is handled the same way as @in in callers and @in_guaranteed in
callees. OwnershipModelEliminator emits the call to destroy_addr that is
needed to destroy the argument in the caller.
rdar://122707697
The reason why I am fixing this is that otherwise, we get a warning when one
creates an actor isolated closure and pass it into a task, e.x.:
```swift
@MainActor func test() {
// We would get a warning on the closure below saying that we are sending
// a closure that is MainActor isolated.
Task {
...
}
}
```
Create two versions of the following functions:
isConsumedParameter
isGuaranteedParameter
SILParameterInfo::isConsumed
SILParameterInfo::isGuaranteed
SILArgumentConvention::isOwnedConvention
SILArgumentConvention::isGuaranteedConvention
These changes will be needed when we add a new convention for
non-trivial C++ types as the functions will return different answers
depending on whether they are called for the caller or the callee. This
commit doesn't change any functionality.
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.
Remove improper special-case handling of subscripts in `findStorageReferenceExprForMoveOnly`.
The correct thing to do for any storage decl ref of noncopyable type is to emit it as a borrow
if it's implemented using storage, a read accessor, or an addressor. Fixes rdar://127335590.
Later analyses are too conservative to remove a copy, but it should be fairly safe to
elide the copy for noncopyable globals, since accesses are tightly scoped and dynamically checked,
so consumes aren't possible, and borrows and inout accesses of mutable globals are dynamically
guarded and not subject to exclusivity checks. rdar://114329759
* Allow normal function results of @yield_once coroutines
* Address review comments
* Workaround LLVM coroutine codegen problem: it assumes that unwind path never returns.
This is not true to Swift coroutines as unwind path should end with error result.
a closure expression, then don't actually do it. The long term plan is
to actually do this, which should just be a matter of taking some of the
code out of reabstraction thunk emission and using it in prolog/epilog/return
emission. In the short term, the goal is just to get the conversion
information down to the closure emitter so that we can see that we're
erasing into an `@isolated(any)` type and then actually erase the
closure's isolation properly instead of relying on type-based erasure,
which can't handle parameter/capture isolation correctly.
Synthesized stub constructors contain `#line` directives and under certain
circumstances these directives can have invalid source locations. SILGen would
trigger an assert (or invoke UB in non-asserts builds) when attempting to
expand these directives into literal values. Check the source location for
validity before translating the location to a location in the outermost source
file.
Resolves rdar://121971741
