Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
I suspect there are latent bugs here with generic-class-constrained existentials,
same-element requirements involving packs, etc. We can't assume that the
local archetypes don't have "hidden" dependencies on the outer parameters
that are not encoded in the thunk's interface type.
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.
This is largely a matter of changing the main loop over subst
params in TranslateArguments to use the generators I added,
then plugging back into the general reabstraction infrastructure.
Because we don't have pack coroutines, we're kind of stuck in
the code generation for pack reabstraction: we have to write
+1 r-values into a temporary tuple and then write those tuple
element addresses into the output pack. It's not great. We
also have lifetime problems with things like non-escaping
closures --- we have that problem outside of reabstraction
thunks, too.
Other than that glaring problem, I'm feeling relatively good
about the code here. It's missing some peepholes, but it should
work. But that that's not to say that arity reabstraction works
in general; my attempts to test it have been exposing some
problems elsewhere, and in particular the closure case crashes,
which is really bad. But this gets a few more things working,
and this PR is quite large already.
