Match what we do in `emitThrow`. Both of these should be unified and
generalized, relying on the AST to provide the necessary conversions
rather than having SILGen re-derive them.
Introduce SILGen support for reabstractions thunks that change the
error, between indirect and direct errors as well as conversions
amongst error types (e.g., from concrete to `any Error`).
The code here was materializing the value in this case, but then re-loading it, which is unnecessary
since call emission will materialize the value to match the callee's calling convention already.
It does look like a copy into formal evaluation scope is necessary to get the correct lifetimes
in some circumstances. The move-only checker doesn't like any additional copies at all because
it thinks they're consumes, so only borrow in the case where the value is move-only.
We must avoid emitting applies of `_diagnoseUnavailableCodeReached()` in
function bodies that are already marked unreachable since there isn't a valid
insertion point once an `unreachable` instruction has been emitted. A function
body may be marked unreachable if, for example, the parameters of the function
are uninhabited.
Resolves rdar://116246677
I think from SIL's perspective, it should only worry about whether the
type is move-only. That includes MoveOnlyWrapped SILTypes and regular
types that cannot be copied.
Most of the code querying `SILType::isPureMoveOnly` is in SILGen, where
it's very likely that the original AST type is sitting around already.
In such cases, I think it's fine to ask the AST type if it is
noncopyable. The clarity of only asking the ASTType if it's noncopyable
is beneficial, I think.
The payload is stored maximally-abstracted, so make sure we respect
that to avoid a crash when the 'async let' binding has a function type.
Fixes rdar://114823719.
The property descriptors of `@backDeployed` properties aren't available on OSes
prior to the "back deployed before" OS version, so the descriptors cannot be
referenced by clients that may run against older versions of the library
that defines the property.
See https://github.com/apple/swift/pull/59214 for prior art.
Resolves rdar://106517386
This is a futile attempt to discourage future use of getType() by
giving it a "scary" name.
We want people to use getInterfaceType() like with the other decl kinds.
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.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
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.
We can probably avoid this copy in more circumstances, but make the change only for
noncopyable types for now, since that's the case where it's most semantically apparent.
rdar://109161396
Calls to getters are implicit because the compiler inserts them on a property
access, but the location is useful in backtraces so it should be preserved.
rdar://109123395
The form of the AST changes slightly when a type has a read and a modify.
Specifically, we now have a load on the subscript and an inout_expr on the base.
I dealt with this by making the inout_expr something that when we look for
storage we look through and by tweaking the load lookthrough code.
I also added a bunch of tests that showed the behavior of subscripts/other accessors with the following combinations of semantics:
1. get only.
2. get/set.
3. get/modify.
4. read/set.
5. read/modify.
rdar://109746476
When opaque values are enabled, we do not need this store_borrow. This was
caught by the following tests:
Swift(macosx-x86_64) :: SILGen/opaque_values_silgen.swift
Swift(macosx-x86_64) :: SILGen/opaque_values_silgen_resilient.swift
This ensures that given a class that contains a noncopyable type that contains
another noncopyable type:
```
@_moveOnly struct S2 {}
@_moveOnly struct S { var s2: S2 }
class C { var s: S }
```
if we call a resilient function that takes C.S.S2:
```
borrowVal(c.s.s2)
```
we properly spill s2 onto the stack using a store_borrow.
Why Do This?
------------
Currently SILGenLValue treats ref_element_addr as a base that it needs to load
from for both copyable and non-copyable types. We keep a separation of concerns
and require emission of resilient functions to handle these loaded values. For
copyable types this means copying the value and storing it into a temporary
stack allocation. For noncopyable types, we never actually implemented this so
we would hit an error in SILGenApply telling us that our resilient function
expected an address argument, but we are passing an object.
To work around this, I updated how we emit borrowed lvalue arguments to in this
case to spill the value into a temporary allocation using a store_borrow. I also
included a test that validates that we properly have a read exclusivity scope
around the original loaded from memory for the entire call site so even though
we are performing a load_borrow and then spilling it, we still have read
exclusivity to the original memory for the entire region meaning that we still
preserve the semantics.
rdar://109171001
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.
