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.
Because people put all sorts of nonsense into @objc enums (most
reasonably, "private cases", which represent valid values that are not
API), the Swift-synthesized implementation of 'hash(into:)' needs to
not expect a switch statement to be exhaustive. And since
Swift-defined @objc enums are supposed to behave enough like C-defined
enums, they should at least handle simple method calls with an invalid
raw value, which means that 'rawValue' likewise should not use a
switch.
This patch provides alternate implementations that look like this:
extension ImportedEnum {
public var rawValue: Int {
return unsafeBitCast(self, to: Int.self)
}
public func hash(into hasher: inout Hasher) {
hasher.combine(self.rawValue)
}
}
rdar://problem/41913284
The SILGen testsuite consists of valid Swift code covering most language
features. We use these tests to verify that no unknown nodes are in the
file's libSyntax tree. That way we will (hopefully) catch any future
changes or additions to the language which are not implemented in
libSyntax.
Small potential perf win...or rather regain, since we apparently used
to do this. It's a bit trickier to say whether we should do the same
for resilient enums, since /in theory/ a later version of the library
might decide to use different raw values.
https://bugs.swift.org/browse/SR-7094
