Examine pack expansion pattern to determine whether expression
result could be discarded without a warning (applies to tuples
with a single unlabeled pack expansion element as well).
Resolves: rdar://108064941
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.
and lowered pack types.
The "approximate" thing is kindof a representational/testing wart.
Really, all that we care about is that we have a formal pack type
with the right shape. (We don't *really* need a formal pack type ---
we could use anything that can represent the shape --- but we seem
to be standardizing on `PackType` for that.) We could just use the
reduced shape for that, but for some reason I've been resisting that.
Not sure I have a compelling reason, though, and if we decide to
use reduced shapes, we can eliminate the approximate formal packs
stuff.
Inducing packs from tuple slices is a more permanently-useful thing.
This required quite a bit of infrastructure for emitting this kind of
tuple expression, although I'm not going to claim they really work yet;
in particular, I know the RValue constructor is going to try to explode
them, which it really shouldn't.
It also doesn't include the caller side of returns, for which I'll need
to teach ResultPlan to do the new abstraction-pattern walk. But that's
next.
- SILPackType carries whether the elements are stored directly
in the pack, which we're not currently using in the lowering,
but it's probably something we'll want in the final ABI.
Having this also makes it clear that we're doing the right
thing with substitution and element lowering. I also toyed
with making this a scalar type, which made it necessary in
various places, although eventually I pulled back to the
design where we always use packs as addresses.
- Pack boundaries are a core ABI concept, so the lowering has
to wrap parameter pack expansions up as packs. There are huge
unimplemented holes here where the abstraction pattern will
need to tell us how many elements to gather into the pack,
but a naive approach is good enough to get things off the
ground.
- Pack conventions are related to the existing parameter and
result conventions, but they're different on enough grounds
that they deserve to be separated.
