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.
The runtime function `swift_willThrowTyped` takes its argument
`@in_guaranteed`. In opaque values SIL, that's passed directly. Don't
store non-address errors before passing them to the function.
In address-lowered mode, to initialize tuple-typed memory in a single
step, tuple_addr_constructor must generally be used because it's not
possible to construct a tuple any of whose fields are address-only. In
opaque values mode, there is no problem constructing such a tuple. So
construct the tuple and then assign it into the tuple-typed memory; the
single instruction that initializes the memory will be the assign.
When storing an instance of some type that conforms to Hashable into an
lvalue of type AnyHashable, the source rvalue needs to be emitted within
a new SGFContext. Otherwise, the LocalVarInitialization for the var of
type AnyHashable would be used and an attempt would be made to store the
instance of the conforming type into the projected box.
In opaque values mode, emit the new weak copy instructions to convert as
follows:
strong_copy_weak_value: `@owned $sil_weak T?` -> `@owned $T?`
weak_copy_value: `@owned $T?` -> `@owned $@sil_weak T?`
Doing so is necessary in opaque values mode where it is needed to deal
with weak values directly rather than indirectly via `load_weak`s and
`store_weak`s.
When a value's preferred existential representation is opaque, if the
value is not an address (which can only happen in opaque values mode),
emit open_existential_value rather than open_existential_addr.
When constructing r-values during keypath setter emission, consider
whether the argument's type is trivial and construct the relevant
r-value based on that. This worked before without opaque values because
the value is always an address.
When setting a value at a key-path, in opaque values mode, don't create
a temporary and store the new value into it. That is necessary when
using lowered addresses because intrinsic's signature is
```
sil @swift_setAtWritableKeyPath : $@convention(thin) <τ_0_0, τ_0_1> (@inout τ_0_0, @guaranteed WritableKeyPath<τ_0_0, τ_0_1>, @in τ_0_1) -> ()
```
but is incorrect in opaque values mode where values are passed directly
to `@in` parameters.
It is necessary for opaque values where for casts that will newly start
out as checked_cast_brs and be lowered to checked_cast_addr_brs, since
the latter has the source formal type, IRGen relies on being able to
access it, and there's no way in general to obtain the source formal
type from the source lowered type.
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
When a throwing function which returns a generic (this is the simplest
example) is back deployed, it gets a back deploy thunk. This back
deploy thunk calls one of two variations of the function, depending on
availability, both which have the same signature and in particular both
return a generic. The result type of that function signature is an
unbound generic.
Previously, that result type was used as is. Consequently the success
blocks for the try_apply instructions in these thunks had arguments of
unbound generic type.
Here, that type is mapped into the context of the function being
emitted. The thunks now have the appropriate bound generic type.
When branching to the exit block, flatten an @out tuple return value
into its components, as is done for all other return values.
In the exit block, when constructing the @out tuple to return, visit the
tuple-type-tree of the return value to reconstruct the nested tuple
structure: @out tuple returns are not flattened, unlike regular tuple
returns.
The old syntax was
@opened("UUID") constraintType
Where constraintType was the right hand side of a conformance requirement.
This would always create an archetype where the interface type was `Self`,
so it couldn't cope with member types of opened existential types.
Member types of opened existential types is now a thing with SE-0309, so
this lack of support prevented writing SIL test cases using this feature.
The new syntax is
@opened("UUID", constraintType) interfaceType
The interfaceType is a type parameter rooted in an implicit `Self`
generic parameter, which is understood to be the underlying type of the
existential.
Fixes rdar://problem/93771238.
Previously, when emitting block arguments, the value category of the
SILType was overridden to be address for indirect arguments. With
opaque types, that distinction is made later during AddressLowering. So
only do that when opaque types are disabled.
The main point of this change is to make sure that a shared function always has a body: both, in the optimizer pipeline and in the swiftmodule file.
This is important because the compiler always needs to emit code for a shared function. Shared functions cannot be referenced from outside the module.
In several corner cases we missed to maintain this invariant which resulted in unresolved-symbol linker errors.
As side-effect of this change we can drop the shared_external SIL linkage and the IsSerializable flag, which simplifies the serialization and linkage concept.
This does not eliminate the entrypoints on SILBuilder yet. I want to do this in
two parts so that it is functionally easier to disentangle changing the APIs
above SILBuilder and changing the underlying instruction itself.
rdar://33440767
Protocol name mangling didn’t always go through a path that allowed the use
of standard substitutions. Enable standard substitutions for protocol name
manglings where they make sense.
Removes ~277k from the standard library binary size.
The SILGen testsuite consists of valid Swift code covering most language
features. We use these tests to verify that no unknown nodes are in the
file's libSyntax tree. That way we will (hopefully) catch any future
changes or additions to the language which are not implemented in
libSyntax.
I am going to leave in the infrastructure around this just in case. But there is
no reason to keep this in the tests themselves. I can always just revert this
and I don't think merge conflicts are likely due to previous work I did around
the tooling for this.
