In asserts builds, the lexicality of packs is verified via an
alternative code-path that walks into aggregates. That walk needs to
proceed through packs.
rdar://107283101
Substitution of a pack expansion type may now produce a pack type.
We immediately expand that pack when transforming a tuple, a function
parameter, or a pack.
I had to duplicate the component-wise transformation logic in the
simplifyType transform, which I'm not pleased about, but a little
code duplication seemed a lot better than trying to unify the code
in two very different places.
I think we're very close to being able to assert that pack expansion
shapes are either pack archetypes or pack parameters; unfortunately,
the pack matchers intentionally produce expansions of packs, and I
didn't want to add that to an already-large patch.
This change aims at reducing the need for SIL passes to check into the AST
storage of SILLocations. The end goal is to eventually merge this with the
autogenerated flag, but at the moment the emergent semantics of both properties
are not identical.
The pointsToEnd flag is only meaningful when combined with an AST node, and
moving it into the AST pointer frees up a bit in the flags bitfield for later
use.
needs to be lowered, use an opaque abstraction pattern.
As I argue in the comment, we know that the orig type is now either
an opaque type or a type with high-level structure that is invariant
to lowering. Substitution will not change the latter property, and
an opaque abstraction pattern is correct for the former. Attempting
to create a "truer" abstraction pattern that preserves more structure
from the orig type is both pointless and problematic. The
substitutions we just did may have replaced pack references with
non-pack types if there are active expansions in progress; this cannot
be easily explained in terms of substitutions. (In theory, we could
pass a more opaque concept of substitutions through AbstractionPattern,
which might help with this. That would also make it harder to catch
bugs with signature mismatches, though.)
whichever case it happens to be in.
This is a basic fix so that parallel walks on tuples and function
types in the substituted type will work . Separately, though, I
do not think the places that use this really need to be passed an
orig type; this is used for computing type properties, and I am
not aware of any reason we should need an orig type to compute
type properties. Additionally, the orig types computed by this
function are not really correct because of the substitution being
done in some cases, so it'd be very nice to rip this all out.
I'm not good to look into that right now, though.
The verify-di-hole SILVerifier pass is very useful in catching incorrectly set
SILDebugScopes, but it can be very tedious to track down the root cause of a
verification failure. This patch replicates much of its functionality inside an
assertion in SILBuilder, which will result in a backtrace pointing directly to
where the offending scope is being set.
and not also drop a subst parameter.
This turned out to be more convenient for certain clients (e.g. SILGenPoly)
than requiring the full subst param list to be passed in. These clients
want to process the subst param list separately, and dropping self early
can be convenient for that. The only fundamental reason we need this
flag is for working with the orig type, so just use it for that; clients
that need to use this feature can reasonably be expected to cooperate.
This is necessary because the use patterns in SILGenPoly require
walking two orig+subst sequences in parallel, which poses problems
for a callback-centric design like the one I addded before. An
inversion of control is necessary; this is basically a manual
coroutine. But frankly it's a nicer interface than the callback
design, too; I switched the implementation of forEachFunctionParam
to use the generator just to avoid code duplication, but I might
try to remove it and switch all the clients over to the generator.
The main problems with the callback design are that (1) I wasn't
sure which values clients would want, and the result is that there
are a *lot* of parameters and (2) (relatedly) the types of those
parameters have to be written out explicitly, and some of them
are quite large. The generator code is just much nicer. Maybe
I can still give the generator a little unparameterized callback
to keep lexical loops simple.
I'll need to do this same thing for tuples. One at a time.
This still does not have the complete behavior that we want since we are not yet
inserting the debug_value undef to invalidate after performing moves.
NOTE: In printed SIL, I decided to make the flag implicit if we have a
noncopyable type. This is just to reduce the bloat in SIL. If one needs this
property for a copyable type though, it is mandatory.
This is in preparation for wiring up debug info support for noncopyable
values. Originally this flag name made sense since it was set when we performed
consume operator checking. Now I am going to use it for noncopyable types as
well. I think the new name uses_moveable_value_debuginfo actually describes what
the flag is supposed to do, tell IRGen that the value may be moved since it
needs to use moveable value debug info emission.
The old code assumed that thunk signatures would only possibly refer to a
single opened existential archetype. To generalize this to opened element
archetypes, it needs to both support multiple archetypes and, of course,
support the new kind of local archetype. So here's a bunch of code to
clone element signatures and support multiple local archetypes. It fell out
to also make this support multiple opened existential archetypes, if we
ever have code patterns that require that.
As I've been iterating on this work, I've been gradually mulling these
over, and I think this is the way to go for now. These should make it
a lot less cumbersome to write these kinds of traversals correctly.
The intent is to the sunset the existing expanded-components stuff
after I do a similar pass for function parameters.
