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.
The reason why is that we want to distinguish inbetween SILFunction's that are
marked as unspecified by SILGen and those that are parsed from textual SIL that
do not have any specified isolation. This will make it easier to write nice
FileCheck tests against SILGen output on what is the inferred isolation for
various items.
NFCI.
Using mapTypeIntoContext() is incorrect here, because we might not
be calling the default argument from the callee's context. Instead,
use the substitutions from the ConcreteDeclRef.
Fixes <rdar://problem/55739617>.
When applying a solution to a nil literal of Optional type, we would
build a direct reference to Optional<T>.none instead of leaving the
NilLiteralExpr in place, because this would generate more efficient
SIL that avoided the call to the Optional(nilLiteral: ()) witness.
However, a few places in the type checker build type-checked AST, and
they build NilLiteralExpr directly. Moving the peephole to SILGen's
lowering of NilLiteralExpr allows us to simplify generated SIL even
further by eliding an unnecessary metatype value. Furthermore, it
allows SILGen to accept NilLiteralExprs that do not have a
ConcreteDeclRef set, which makes type-checked AST easier to build.
Instead of building ArgumentShuffleExprs, lets just build a TupleExpr,
with explicit representation of collected varargs and default
arguments.
This isn't quite as elegant as it should be, because when re-typechecking,
SanitizeExpr needs to restore the 'old' parameter list by stripping out
the nodes inserted by type checking. However that hackery is all isolated
in one place and will go away soon.
Note that there's a minor change the generated SIL. Caller default
arguments (#file, #line, etc) are no longer delayed and are instead
evaluated in their usual argument position. I don't believe this actually
results in an observable change in behavior, but if it turns out to be
a problem, we can pretty easily change it back to the old behavior with a
bit of extra work.
