These instructions have the following attributes:
1. copyably_to_moveonlywrapper takes in a 'T' and maps it to a '@moveOnly
T'. This is semantically used when initializing a new moveOnly binding from a
copyable value. It semantically destroys its input @owned value and returns a
brand new independent @owned @moveOnly value. It also is used to convert a
trivial copyable value with type 'Trivial' into an owned non-trivial value of
type '@moveOnly Trivial'. If one thinks of '@moveOnly' as a monad, this is how
one injects a copyable value into the move only space.
2. moveonlywrapper_to_copyable takes in a '@moveOnly T' and produces a new 'T'
value. This is a 'forwarding' instruction where at parse time, we only allow for
one to choose it to be [owned] or [guaranteed].
* moveonlywrapper_to_copyable [owned] is used to signal the end of lifetime of
the '@moveOnly' wrapper. SILGen inserts these when ever a move only value has
its ownership passed to a situation where a copyable value is needed. Since it
is consuming, we know that the no implicit copy checker will ensure that if we
need a copy for it, the program will emit a diagnostic.
* moveonlywrapper_to_copyable [guaranteed] is used to pass a @moveOnly T value
as a copyable guaranteed parameter with type 'T' to a function. In the case of
using no-implicit-copy checking this is always fine since no-implicit-copy is a
local pattern. This would be an error when performing no escape
checking. Importantly, this instruction also is where in the case of an
@moveOnly trivial type, we convert from the non-trivial representation to the
trivial representation.
Some important notes:
1. In a forthcoming commit, I am going to rebase the no implicit copy checker on
top of these instructions. By using '@moveOnly' in the type system, we can
ensure that later in the SIL pipeline, we can have optimizations easily ignore
the code.
2. Be aware of is that due to SILGen only emitting '@moveOnly T' along immediate
accesses to the variable and always converts to a copyable representation when
calling other code, we can simply eliminate from the IR all moveonly-ness from
the IR using a lowering pass (that I am going to upstream). In the evil scheme
we are accomplishing here, we perform lowering of trivial values right after
ownership lowering and before diagnostics to simplify the pipeline.
On another note, I also fixed a few things in SILParsing around getASTType() vs
getRawASTType().
Specifically:
* isMoveOnly() -> isMoveOnlyWrapped()
* asMoveOnly() -> addingMoveOnlyWrapper()
* withoutMoveOnly() -> removingMoveOnlyWrapper()
* copyMoveOnly() -> copyingMoveOnlyWrapper()
This is just pure renaming to resolve confusion from the reader.
The only place outside of SILType that uses getRawASTType() is in SILPrinter. It
is really an inner detail of SILType that we don't want to expose. With that in
mind, in this commit we:
1. Made SILType::getRawASTType() private.
2. Forward declared SILPrinter in SILType.h. We don't define it so no one can
use it, but the declaration still lets us make it a friend class of SILType
(allowing SILPrinter to still access getRawASTType()).
Previously we gave them the same SIL linkage as the method, then changed
the LLVM IR linkage to 'internal' (which is roughly equivalent to
SIL 'private') in IRGen.
This would crash in the SIL verifier if an @objc method was
'@_alwaysEmitIntoClient'. While such a combination of attributes is
silly since '@objc' methods are intrinsically part of the ABI, we
should not crash in this case.
The simplest fix is to just set the linkage to private at the SIL
level, avoiding the IRGen hack entirely.
TypeConverter doesn't know by itself what SILModule it's currently lowering on
behalf of, so the existing code forming the TypeExpansionContext for opaque types
incorrectly set the isWholeModule flag to always false. This created a miscompile
when a public API contained a closure that captured a value involving private types
from another file in the same module because of mismatched type expansion contexts
inside and outside the closure. Fixes rdar://93821679
This is done by introducing the API SILType::getSemanticASTType(). This can be
used in contexts for type queries like getStructOrBoundGenericStruct() where one
wants to look through the move only wrapper to the underlying type.
If a function's parameter or return types involve nominal types that
have been moved across modules using @_originallyDefinedIn, we must
take care to always mangle the opaque result type's name using the
original module names and not the current module names.
This was a problem with DWARF mangling, which normally disables
@_originallyDefinedIn for other purposes. Make sure to always
temporarily re-enable it when mangling an opaque result type.
Fixes rdar://problem/93822207.
As we do with field indices for struct instructions.
This avoids quadratic behavior in case of enums with lots of cases.
Also: cache field and enum case indices in the SILModule.
`salvageDebugInfo` is called during SIL Mem2Reg and could produce misleading debug info in the following case:
```
%a = alloc_stack $MyModel.TangentVector, var, name "self", argno 1, implicit, loc "debug2.swift":37:17 ...
...
store %b to %a : $*MyModel.TangentVector
```
Such SIL could be created as a result of inlining (where store comes from the inlined function).
Before this patch we'd end with `debug_value` instruction with variable information, but without or incorrect location.
This caused LLVM IR debug info verifier assertions when there might be another instruction with complete debug info (including location) for the same argument.
After this patch we always reuse it from destination alloca
Fixes#58660
If a `convert_function` instruction operates on a function with indirect
results, or changes the type of direct results, then we can transform
an application of the converted function into an application of the
original function followed by bitwise conversions of the results, just
like we have done for arguments. Now that closures are emitted at their
context abstraction level, they are more likely to be emitted with
indirect results, so the inability to simplify function conversions
in this case would lead to missed inlining opportunities we used to
take.
This might fix the randomly occuring errors of:
```
SIL verification failed: cannot have a serialized function after the module has been serialized: !F->isSerialized() || !mod.isSerialized() || mod.isParsedAsSerializedSIL()
```
This makes `SILCloner::getASTTypeInClonedContext` and `getTypeInClonedContext`,
which use `QueryTypeSubstitutionMapOrIdentity`, work for nested opened archetypes
and consequently fixes inlining of instructions involving these archetypes.
With this change, the SILVerifier should now catch and reject the appearance
of a hop_to_executor between the get_continuation and await_continuation
instructions.
- Add a `[reflection]` bit to `alloc_box` instructions, to indicate that a box
should be allocated with reflection metadata attached.
- Add a `@captures_generics` attribute to SILLayouts, to indicate a type layout
that captures the generic arguments it's substituted with, meaning it can
recreate the generic environment without additional ABI-level arguments, like
a generic partial application can.
Previously, the AbstractionPattern that was used for the value
"returned" (i.e. via a completion handler) from ObjC mostly (but not
quite always) was "type".
The generated completion handler correctly (because this is required in
order to call _resumeUnsafeContinuation) reabstracted the block (e.g.
from @convention(block) to @substituted <T> () -> @out T for <()>). The
callee of the ObjC function, however, loaded the function from the block
as if it were not reabstracted (e.g. () -> ()).
On most platforms, that happened to work. On arm64e, that difference in
types caused in a difference in pointer signing, resulting in a failure
at runtime.
rdar://85526879
rdar://85526916
Smaller values of FormalLinkage are actually wider scopes,
so std::min'ing with PublicUnique actually just gives you
a result that's always PublicUnique. And we need to start
with PublicNonUnique because even things derived solely
from uniquely-emitted types are not themselves generally
unique.
I don't want to immediately open the can of worms that fixing
this for everyone would entail, so I'm just adding the new
version in parallel and moving new clients to it gradually.
