functions to compute them directly without a TypeLowering object, and
change a lot of getTypeLowering call sites to just use that.
There is one subtle change here that I think is okay: SILBuilder used to
use different TypeExpansionContexts when inserting into a global:
- getTypeLowering() always used a minimal context when inserting into
a global
- getTypeExpansionContext() always returned a maximal context for the
module scope
The latter seems more correct, as AFAIK global initializers are never
inlinable. If they are, we probably need to configure the builder with
an actual context properly rather than making global assumptions.
This is incremental progress towards computing this for most types
without a TypeLowering, and hopefully eventually removing TL entirely.
`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.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Call `swift_clearSensitive` after destroying or taking "sensitive" struct types.
Also, support calling C-functions with "sensitive" parameters or return values. In SIL, sensitive types are address-only and so are sensitive parameters/return values.
Though, (small) sensitive C-structs are passed directly to/from C-functions. We need re-abstract such parameter and return values for C-functions.
Rather than materializing the metadata on demand during visitation, only
collect the types that may be required. Finally, materialize everything
that's needed at the end.
Gather the circumstances under which the collector should be used and
what it should collect separately and then collect only in one place if
collection should happen.
Given a releasable value which contains a noncopyable value type with a
deinit, that values outlined release function, among other things, must
call the deinit of that noncopyable value type. In order to do that,
its type metadata must be passed to the value function if it has an
archetype.
Some outlined functions call deinits for noncopyable values. These
deinits require the metadata for the full type.
Teach the OutliningMetadataCollector to collect the metadata for these
types, when the new needsDeinit flag is set.
Also add the new needsLayout flag. For now, all outlined functions need
it.
Previously it was testing for opened existentials specifically.
We should really teach outlining to handle local archetypes properly.
We'd have to build a generic signature for the lowered type, and that
probably means also adding requirements that are relevant to value
operations, but it would mean outlining would benefit all types, and
it would let us avoid bundling in unnecessary information from the
enclosing generic environment.
A minor side-effect of this is that we no longer bind names to
opened element type values. The names were things like \tau_1_0,
which is not very useful, especially in LLVM IR where \tau is
printed with two UTF-8 escapes.
The `deinit` takes full responsibility for destroying the value, using the
user-defined deinit body and implicitly destroying any remaining resources
not consumed during the deinit.
Remaining to do after this patch:
- Run the deinit for enums
- Pass generic arguments for generic move-only types
- Handle deinits that take their parameter indirectly
- Teach value witness layout about when types are move-only and/or have
deinits, so that we don't attempt to give move-only types standard
value witness tables or share box metadata with copyable payloads
In the case of constrained existentials metadata instantiation was not
supported pre 5.7, so using metadata for value operations is prohibited.
rdar://101250193
In preparation for moving to llvm's opaque pointer representation
replace getPointerElementType and CreateCall/CreateLoad/Store uses that
dependent on the address operand's pointer element type.
This means an `Address` carries the element type and we use
`FunctionPointer` in more places or read the function type off the
`llvm::Function`.
Motivation: `GenericSignatureImpl::getCanonicalSignature` crashes for
`GenericSignature` with underlying `nullptr`. This led to verbose workarounds
when computing `CanGenericSignature` from `GenericSignature`.
Solution: `GenericSignature::getCanonicalSignature` is a wrapper around
`GenericSignatureImpl::getCanonicalSignature` that returns the canonical
signature, or `nullptr` if the underlying pointer is `nullptr`.
Rewrite all verbose workarounds using `GenericSignature::getCanonicalSignature`.
box descriptors
We want to substitute opaque result types in addTypeRef but when we pass
SILFunctionTypes this would fail because AST type substitution does not
support lowered SIL types.
Instead add addLoweredTypeRef which substitutes based on SILTypes.
rdar://54529445
Doing so will cause linkage errors and is not neccessary since we call
the witness of the enclosing type as soon as its fields are not ABI
accessible.
rdar://40868358
They're not used inside the thunk so it's a waste passing them in, and
if they involve private types from a different translation unit we will
get a linking error from referencing the metadata accessor function.
Fixes the test case in <rdar://problem/39470607>, but the more general
problem remains.
Fixes a regression in the source compatibility suite which I had a
lot of trouble extracting into a separate test case.
Most of this patch is just moving the outlining code into a separate
file and organizing it into a helper class instead of copy/pasting
so much code. The main functional change is implicit in the difference
between collecting formal metadata and collecting it for layout, which
then is exploited in bindMetadataParameters.
As a secondary change, stop collecting metadata for class-bounded
archetypes; we don't actually need it to do value operations.
