variadic-tuple results. There are three parts to this.
First, fix the emission of indirect result parameters to do a
proper abstraction-pattern-aware traversal of tuple patterns.
There was a FIXME here and everything.
Second, fix the computation of substituted abstraction
patterns to properly handle vanishing tuples. The previous code
was recursively destructuring tuples, but only when it saw a
tuple as the substituted type, which of course breaks on vanishing
tuples.
Finally, fix the emission of returns into vanishing tuple
patterns by allowing the code to not produce a TupleInitialization
when the tuple pattern vanishes. We should always get a singleton
element initializer in this case.
Fixes rdar://109843932, plus a closely-related test case for
vanishing tuples that I added myself.
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.
