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.
A constructor can constrain generic parameters more than the
type itself, either because there is a 'where' clause on the
constructor, or because the constructor is defined inside an
extension with a 'where' clause.
In this case, when the constructor calls a stored property
initializer to implicitly initialize a stored property with
an initial value, we must apply substitutions to get the
correct result type for the call.
If the original type of the stored property lowers differently
based on the abstraction pattern, for example if it is a
function type, then emitApply() would by default re-abstract
the result to the most specific abstraction pattern possible.
However, this was wrong because we store the result value into
the stored property, and a stored property's type should
always be lowered with the most generic abstraction pattern.
In practice, this meant if you have a stored property of type
(T) -> (), and an initializer with 'where T == String' for
example, we would call the initializer, to produce a value with
lowered type (@in_guaranteed String) -> (), then thunk it to a
(@guaranteed String) -> (), and try to store the thunk into
the stored property -- which has type (@in_guaranteed String) -> ().
This would either miscompile or trigger an assertion.
To get around this, we want to bypass the orig-to-subst
conversion performed in emitApply(). My chosen solution is
to have emitApply() emit the result into a
ConvertingInitialization set up to perform a subst-to-orig
conversion.
Now that ConvertingInitialization is smart enough to
peephole away matched pairs of orig-to-subst and subst-to-orig
conversions, this always reduces to a no-op, and the
emitApply() call produces and stores a value with the
correct abstraction pattern.
Fixes <rdar://problem/67419937>.
