Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
A begin_apply token may be used by operands that do not end the coroutine:
mark_dependence.
We need an API that gives us only the coroutine-ending uses. This blocks
~Escapable accessors.
end_borrow is considered coroutine-ending even though it does not actually
terminate the coroutine.
We cannot simply ask isLifetimeEnding, because end_apply and abort_apply do not
end any lifetime.
When lazy typechecking is enabled, extensions that do not typecheck can make it
to TBDGen, which would crash during its AST walk because `SILSymbolVisitor`
tried to dereference the null nominal type for the extension.
Resolves rdar://139320515.
We currently load it for prespecialization when it wasn't loaded initially.
This causes an inadvertant issue for invertible protocols.
When we don’t have the stdlib loaded initially, we “synthesize” the
invertible protocol from the Builtin module by creating a new `ProtocolDecl*`
and stashing it on the `ASTContext`.
If the stdlib gets loaded later, deserialized stdlib types conform to the deserialized `Escapable` protocol
which has a different `ProtocolDecl *` pointer for `Escapable`.
So queries like `conformsToInvertible` fail because they are using the wrong `ProtocolDecl*`
for `Copyable`/`Escapable` while looking up the ConformanceTable.
In case the control flow ends in a dead-end block there can be begin-borrow instructions which have no corresponding end-borrow uses.
After duplicating such a block, the re-borrow flags cannot be recomputed correctly for inserted phi arguments.
Therefore just disable duplicating such blocks, e.g. in jump-threading.
ClangImporter synthesized declarations inherently do not have user written
code. Unfortunately, despite that they are not always marked implicit as they
should be. This was causing a crash when attempting to generate profile
coverage maps for synthesized constructors for imported structs.
I tried marking the constructors implicit, but that had too many knock-on
effects in tests. This more targeted fix unblocks compatibility suite testing
without trying to grapple with the implications of that more fundamental fix.
Resolves rdar://139486938.
This ended up in creating a lot of Array functions, even if a program didn't use Array at all.
Now, only add specialization attributes if a function is already there.
Otherwise remember the attributes and add them to a function once it is created.
I am adding this instruction to express artificially that two non-Sendable
values should be part of the same region. It is meant to be used in cases where
due to unsafe code using Sendable, we stop propagating a non-Sendable dependency
that needs to be made in the same region of a use of said Sendable value. I
included an example in ./docs/SIL.rst of where this comes up with @out results
of continuations.
This predicate is meant to ask if the loweredType is equal to
`getLoweredType(pattern, formalType)` for *some* abstraction pattern.
If the formal type contained an opaque archetype, we performed a
different check, because we asked if loweredEqual is equal to
`getLoweredType(AbstractionPattern(formalType), formalType)`.
This caused a spurious SIL verifier failure when the payload of an
existential contained an opaque archetype, because we lower the
payload with the most general AbstractionPattern, so that
@thin metatypes become @thick, etc.
The regression test exercises this bug, and also another bug that was
present in 6.0 but was already fixed on main by one of my earlier
refactorings.
Fixes rdar://problem/138655637.
Collect all types in the substitution map which constitute
type-dependent operands and record them in the instruction's operand
list. Fixes a bug where open_existential_metatype (e.g.) is deleted as
dead because it has no users even when the type it defines is used in a
substitution map of a builtin.
`Builtin.FixedArray<let N: Int, T: ~Copyable & ~Escapable>` has the layout of `N` elements of type `T` laid out
sequentially in memory (with the tail padding of every element occupied by the array). This provides a primitive
on which the standard library `Vector` type can be built.
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.
The thunk's parameter needs the @in_guaranteed convention if it's a
const reference parameter. However, that convention wasn't being used
because clang importer was removing the const reference from the
type and SILGen was computing the type of the parameter based on the
type without const reference.
This commit fixes the bug by passing the clang function type to
SILDeclRef so that it can be used to compute the correct thunk type.
This fixes a crash when a closure is passed to a C function taking a
pointer to a function that has a const reference struct parameter.
This recommits e074426 with fixes to
serialization/deserialization of function types. The fixes prevent clang
types of functions from being dropped during serialization.
rdar://131321096
In Embedded Swift, witness method lookup is done from specialized witness tables.
For this to work, the type of witness_method must be specialized as well.
Otherwise the method call would be done with wrong parameter conventions (indirect instead of direct).
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.
For now this will only be used for HopToMainActorIfNeeded thunks. I am creating
this now since in the past there has only been one option for creating
thunks... to create the thunk in SILGen using SILGenThunk. This code is hard to
test and there is a lot of it. By using an instruction here we get a few benefits:
1. We decouple SILGen from needing to generate new kinds of thunks. This means
that SILGenThunk does not need to expand to handle more thunks.
2. All thunks implemented via ThunkInst will be easy to test in a decoupled way
with SIL tests.
3. Even though this stabilizes the patient, we still have many thunks in SILGen
and various parts of the compiler. Over time, we can swap to this model,
allowing us to hopefully eventually delete SILGenThunk.
