When `-unavailable-decl-optimization=stub` is specified, insert a call to
`_diagnoseUnavailableCodeReached()` at the beginning of the function to cause
it to trap if executed at run time.
Part of rdar://107388493
The reason why I am doing this is that otherwise if one has a function that
takes both a guaranteed and an owned parameter, we will break OSSA invariants
since the load [take] will invalidate the load_borrow. So instead, we put in a
load_borrow knowing that the move checker will convert it to a load_borrow
assuming that the two pass exclusivity checking.
NOTE: Because of some missing functionality in subsequent tests, I had to
disable one test (moveonly_escaping_definite_initialization.swift) and also add
some checks for copy of noncopyable object errors. They will go away in the next
2 commits.
rdar://108510987
AbstractionPattern.
The old logic was wrong for vanishing tuples: a non-tuple substituted
type might correspond to multiple lowered parameters if it's the result
of substituting into a vanishing tuple that also contains empty pack
expansions.
Test to follow later in this PR.
As I've been iterating on this work, I've been gradually mulling these
over, and I think this is the way to go for now. These should make it
a lot less cumbersome to write these kinds of traversals correctly.
The intent is to the sunset the existing expanded-components stuff
after I do a similar pass for function parameters.
The subexpression of a MaterializePackExpr (which is always a tuple value
currently) is emitted while preparing to emit a pack expansion expr, and its
elements are projected from within the dynamic pack loop. This means that a
materialized pack is only evaluated once, rather than being evaluated on
every iteration over the pack elements.
More missing infrastructure. In this case, it's really *existing*
missing infrastructure, though; we should have been imploding tuples
this way all along, given that we're doing it in the first place.
I don't like that we're doing all these extra tuple copies. I'm not
sure yet if they're just coming out of SILGen and eliminated immediately
after in practice; maybe so. Still, it should be obvious that they're
unnecessary.
This is all relatively nicely abstracted, which is not to say that
it didn't take an awful lot of plumbing to get it to work. The basic
problem here is inherent: we need to do component-specific setup and
teardown, and unfortunately in the current representation we have to
do that with separate loops and without any dominance relationships.
(This is the same thing preventing us from doing borrows in the
general case.) The result is that the general case of result emission
is to emit every element of the expansion into a temporary tuple
(requiring a pack loop before the call to initialize the pack), then
process those elements in the body of a second pack loop after the
call. And that's terrible enough that we really have to do the work
to try to avoid it, which makes all the APIs more complicated.
Anyway, most of the way through the basic plumbing for variadic
generics now. Next is reabstraction, I think, which I hope will
mostly mean fixing bugs in the infrastructure I've already written.
I'm not really convinced that the existing implementation here is
correct in general; it might work for the type checker's use cases,
but I don't think we can rely on not seeing opened element archetypes
from other expansions in the type we're processing here. But we can
at least tread water while offering a more convenient API.
This required quite a bit of infrastructure for emitting this kind of
tuple expression, although I'm not going to claim they really work yet;
in particular, I know the RValue constructor is going to try to explode
them, which it really shouldn't.
It also doesn't include the caller side of returns, for which I'll need
to teach ResultPlan to do the new abstraction-pattern walk. But that's
next.
When an expression accessing a move-only type through a `_read`
accessor, it can only be borrowed. While a simple access like
`someClass.moveOnlyField` would get recognized in SILGen and properly
borrowed, if you did any further access off of that then you'd get an
illegal sequence involving a copy that is hard to eliminate. In
particular, if you wrote `someClass.moveOnlyField.method()` then we
would emit something like:
```
(%borrowedMO, %coro) = begin_apply #SomeClass.moveOnlyField!.read(...)
%copiedMO = copy_value %borrowedMO
end_apply %coro
= apply #MoveOnlyType.method(%copiedMO) // param is just @guaranteed
```
That's wrong, since we need to use the borrow to call the method, but
that borrow's lifetime ends at the `end_apply`.
Turns out the fix is rather subtle. The reason the access above wouldn't
work is that it did _not_ have a `LoadExpr` around it, which is what the
code in the `ArgEmitter` was expecting when doing an ad-hoc check to see
if it needs to emit as a borrow.
Previously, typechecking and SILGen would treat a function body as fragile as long as the declaration had a `@backDeployed` attribute, regardless of the platform specified by the attribute. This was overly conservative since back deployed functions are only emitted into the client on specific platforms. Now a `@backDeployed` function can reference non-`public` declarations on the platforms it is resilient on:
```
@backDeployed(before: iOS 15)
public func foo() {
#if os(iOS)
// Fragile; this code may be emitted into the client.
#else
// Resilient; this code won't ever be exposed to clients.
#endif
}
```
Resolves rdar://105298520
Although nonescaping closures are representationally trivial pointers to their
on-stack context, it is useful to model them as borrowing their captures, which
allows for checking correct use of move-only values across the closure, and
lets us model the lifetime dependence between a closure and its captures without
an ad-hoc web of `mark_dependence` instructions.
During ownership elimination, We eliminate copy/destroy_value instructions and
end the partial_apply's lifetime with an explicit dealloc_stack as before,
for compatibility with existing IRGen and non-OSSA aware passes.
Consider the following example:
```
class Klass {}
@_moveOnly struct Butt {
var k = Klass()
}
func mixedUse(_: inout Butt, _: __owned Butt) {}
func foo() {
var y = Butt()
mixedUse(&y, y)
}
```
In this case, we want to have an exclusivity violation. Before this patch, we
did a by-value load [copy] of y and then performed the inout access. Since the
access scopes did not overlap, we would not get an exclusivity violation.
Additionally, since the checker assumes that exclusivity violations will be
caught in such a situation, we convert the load [copy] to a load [take] causing
a later memory lifetime violation as seen in the following SIL:
```
sil hidden [ossa] @$s4test3fooyyF : $@convention(thin) () -> () {
bb0:
%0 = alloc_stack [lexical] $Butt, var, name "y" // users: %4, %5, %8, %12, %13
%1 = metatype $@thin Butt.Type // user: %3
// function_ref Butt.init()
%2 = function_ref @$s4test4ButtVACycfC : $@convention(method) (@thin Butt.Type) -> @owned Butt // user: %3
%3 = apply %2(%1) : $@convention(method) (@thin Butt.Type) -> @owned Butt // user: %4
store %3 to [init] %0 : $*Butt // id: %4
%5 = begin_access [modify] [static] %0 : $*Butt // users: %7, %6
%6 = load [take] %5 : $*Butt // user: %10 // <————————— This was a load [copy].
end_access %5 : $*Butt // id: %7
%8 = begin_access [modify] [static] %0 : $*Butt // users: %11, %10
// function_ref mixedUse2(_:_:)
%9 = function_ref @$s4test9mixedUse2yyAA4ButtVz_ADntF : $@convention(thin) (@inout Butt, @owned Butt) -> () // user: %10
%10 = apply %9(%8, %6) : $@convention(thin) (@inout Butt, @owned Butt) -> ()
end_access %8 : $*Butt // id: %11
destroy_addr %0 : $*Butt // id: %12
dealloc_stack %0 : $*Butt // id: %13
%14 = tuple () // user: %15
return %14 : $() // id: %15
} // end sil function '$s4test3fooyyF'
```
Now, instead we create a [consume] access and get the nice exclusivity error we
are looking for.
NOTE: As part of this I needed to tweak the verifier so that [deinit] accesses
are now allowed to have any form of access enforcement before we are in
LoweredSIL. I left in the original verifier error in LoweredSIL and additionally
left in the original error in IRGen. The reason why I am doing this is that I
need the deinit access to represent semantically what consuming from a
ref_element_addr, global, or escaping mutable var look like at the SIL level so
that the move checker can error upon it. Since we will error upon such
consumptions in Canonical SIL, such code patterns will never actually hit
Lowered/IRGen SIL, so it is safe to do so (and the verifier/errors will help us
if we make any mistakes). In the case of a non-escaping var though, we will be
able to use deinit statically and the move checker will make sure that it is not
reused before it is reinitialized.
rdar://101767439
- SILPackType carries whether the elements are stored directly
in the pack, which we're not currently using in the lowering,
but it's probably something we'll want in the final ABI.
Having this also makes it clear that we're doing the right
thing with substitution and element lowering. I also toyed
with making this a scalar type, which made it necessary in
various places, although eventually I pulled back to the
design where we always use packs as addresses.
- Pack boundaries are a core ABI concept, so the lowering has
to wrap parameter pack expansions up as packs. There are huge
unimplemented holes here where the abstraction pattern will
need to tell us how many elements to gather into the pack,
but a naive approach is good enough to get things off the
ground.
- Pack conventions are related to the existing parameter and
result conventions, but they're different on enough grounds
that they deserve to be separated.
If a function body references a declaration with the `@_backDeploy(before:)` attribute and that function body will only execute on deployment targets for which the ABI version of the decl is available then it is unnecessary to thunk the reference to the decl. Function bodies that may be emitted into other modules (e.g. `@inlinable`) must always use the thunk.
Resolves rdar://90729799
Example: (_borrow f).callFunction()
This still does not support _borrow for get/set and more general accessors. That
change will be coming in a forthcoming commit.
rdar://103888591
Otherwise, we down the normal load [copy] path which will cause us to have a
tight exclusivity scope.
One thing to note is that if one accesses a field of a moveonly class one will
still get the tight exclusivity scope issue since SILGenLValue will emit the
moveonly class as a base of the field causing us to use the non-borrow codegen.
rdar://102746971
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
This ensures that the address move checker does not have to perform any unsound
access scope expansions. One note is that the current approach does not work for
class member refs since in SILGenLValue, a class is considered a base of the
SILGenLValue access which is immediately evaluated (causing a copy) rather than
evaluated later at formal evaluation time. I have a few ways of working around
this issue but am going to fix it in a subsequent commit when I fix this for
classes and also read coroutines.
rdar://99616492
The generalized ActorIsolation is enough to represent everything that
ImplicitActorHopTarget can do, and we were mapping between the two way
too often, so collapse them.
This change ensures all store_borrows are ended with an end_borrow, and uses of the store_borrow
destination are all in the enclosing store_borrow scope and via the store_borrow return address.
Fix tests to reflect new store_borrow pattern
We had two notions of canonical types, one is the structural property
where it doesn't contain sugared types, the other one where it does
not contain reducible type parameters with respect to a generic
signature.
Rename the second one to a 'reduced type'.
Due to some changes in how the AST is constructed by CSApply to handle
global actors from @preconcurrency declarations, the AST for a force-call to
an optional ObjC method that is part of a global-actor qualified protocol, such as:
```
import Foundation
@MainActor
@objc protocol P {
@objc optional func generateMaybe() async
}
extension P {
func test() async -> Void {
await self.generateMaybe!()
}
}
```
now contains a function conversion in between the forced-value operation and the dynamic-ref:
```
(force_value_expr type='@MainActor () async -> ()'
(optional_evaluation_expr implicit type='(@MainActor () async -> ())?'
(inject_into_optional implicit type='(@MainActor () async -> ())?'
(function_conversion_expr implicit type='@MainActor () async -> ()' <<<<< new!
(bind_optional_expr implicit type='() async -> ()'
(dynamic_member_ref_expr type='(() async -> ())?' ... )))))
```
For compatibility with how ObjC does message sends to these optional methods, in Swift there
is a difference between how something like `a.method!()` and the following are compiled:
```
let meth = a.method!
meth()
```
The former will directly call the optional method and let the "unknown selector" error be emitted
if it's not implemented. But the latter will query the dynamic method and inject that result into an
`Optional<...>` to then be forced, yielding a "force-unwrap nil" error. It's a subtle difference but
those two scenarios lead to different code paths in SILGen.
Now, this patch fixes the issue by enhancing the recognition of these direct call scenarios so that it
can look past these function conversions. Because that recognition already tries to ignore implicit
conversions, this is not something new. The problem was that we weren't considering implicit conversions
between the optional-evaluation and bind-optional expressions.
This patch is intentionally precise about what kind of function conversions can be skipped, because I
do not know if all of them are OK to blindly skip or not. We might need to expand that in the future.
Resolves rdar://97646309
