It's possible for a value of a non-trivial type to have no cleanup,
if the value was constructed from a no-payload enum case. Tweak
the assert to check the value's ownership instead of checking the
type.
Fixes <https://bugs.swift.org/browse/SR-12000>, <rdar://problem/58455443>.
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`.
Make sure we use the generic environment derived from the
generic signature of the vtable thunk itself, which can now
be different than the generic signature of the derived
method.
This allows vtable thunks that re-abstract generic requirements
to lower all the way through to IRGen.
Rather than having the type checker look for the specific witness to
next() when type checking the for-each loop, which had the effect of
devirtualizing next() even when it shouldn't be, leave the formation
of the next() reference to SILGen. There, form it as a witness
reference, so that the SIL optimizer can choose whether to
devirtualization (or not).
Rather than having the type checker form the ConcreteDeclRef for
makeIterator, have SILGen do it, because it's fairly trivial.
Eliminates some redundant state from the AST.
This ensures that the optimizer has a summary of where the ref_tail_addr will no
longer be used. This is important when analyzing the lifetime of the base of the
ref_tail_addr.
I also cleaned up a little the description around the specification for this in
OperandOwnership. Now all instructions that are "INTERIOR_POINTER_PROJECTIONS"
have their own section/macro as a form of self documenting.
This change has a subtle impact on debug info emission and causes
a regression with a subsequent patch I'm about to commit.
This reverts commit 62d1adb409.
For some reason, doing it in the other order causes a crash.
I suspect this is because we create new instructions below,
but if there's no insertion point, the instruction is never
added to a basic block.
We had two predicates that were used to determine whether the default
argument for a wrapped property in the memberwise initializer would be
of the wrapper type (e.g., Lazy<Int>) vs. the wrapped type
(Int). Those two predicates could disagree, causing a SILGen assertion
and crash. Collapse the two predicates into one correct one,
fixing rdar://problem/57545381.
Complete the refactoring by splitting the semantic callers for the original decl of a dynamically replaced declaration.
There's also a change to the way this attribute is validated and placed. The old model visited the attribute on any functions and variable declarations it encountered in the primary. Once there, it would strip the attribute off of variables and attach the corresponding attribute to each parsed accessor, then perform some additional ObjC-related validation.
The new approach instead leaves the attribute alone. The request exists specifically to perform the lookups and type matching required to find replaced decls, and the attribute visitor no longer needs to worry about revisiting decls it has just grafted attributes onto. This also means that a bunch of parts of IRGen and SILGen that needed to fan out to the accessors to ask for the @_dynamicReplacement attribute to undo the work the type checker had done can just look at the storage itself. Further, syntactic requests for the attribute will now consistently succeed, where before they would fail dependending on whether or not the type checker had run - which was generally not an issue by the time we hit SIL.
We want to be able to use different representations for function types with otherwise compatible
calling conventions. Distinguish these concepts in the `checkForABIDifferences` SIL APIs, so that
we correctly handle representation-only conversions, which can be handled by `convert_function`,
from full reabstractions, making sure to note that the representation-only case is not transitive
for function arguments, since a function that takes a function with a representation change needs
a thunk to change the argument's representation.
All the context dependencies in SIL type lowering have been eradicated, but IRGen's
type info lowering is still context-dependent and doesn't systemically pass generic
contexts around. Sink GenericContextScope bookkeeping entirely into IRGen for now.
Lowering a SIL type should be a pure function of the formal type of a value and the
abstraction pattern it's being lowered against, but we historically did not carry
enough information in abstraction patterns to lower generic parameter types, so we
relied on a generic context signature that would be pushed and popped before lowering
interface types. This patch largely eliminates the necessity for that, by making it
so that `TypeClassifierBase` and its subclasses now take an `AbstractionPattern`
all the way down, and fixing up the visitor logic so that it derives appropriate
abstraction patterns for tuple elements, function arguments, and aggregate fields too.
This makes it so that type lowering is independent of the current generic context.
(Unfortunately, there are still places scattered across the code where we use the
current generic context in order to build abstraction patterns that we then feed
into type lowering, so we can't yet completely eliminate the concept.)
This then enables us to integrate substituted function type construction into type
lowering as well, since we can now lower a generic parameter type against an
abstraction pattern without that generic parameter having to be tied to the same
generic signature (or any generic signature at all, which in the case of a
substituted function type hasn't necessarily even been finalized yet.)
