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.
Previously we would emit an alloc_ref_dynamic followed by a call
of the initializing entry point when calling an @objc dynamic
initializer in a class.
However this is unnecessary now that the allocating entry point
does the right alloc_ref_dynamic.
If the initializer witnesses a protocol requirement, the protocol witness
thunk references the allocating entry point directly, since it has no
vtable entry. For this reason we must use alloc_ref_dynamic and not
alloc_ref to ensure the right type of instance is allocated.
Fixes <rdar://problem/49560721>, <https://bugs.swift.org/browse/SR-10285>.
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.
Consider a class hierarchy like the following:
class Base {
func m1() {}
func m2() {}
}
class Derived : Base {
override func m2() {}
func m3() {}
}
The SIL vtable for 'Derived' now records that the entry for m1
is inherited, the entry for m2 is an override, and the entry
for m3 is a new entry:
sil_vtable Derived {
#Base.m1!1: (Base) -> () -> () : _T01a4BaseC2m1yyF [inherited]
#Base.m2!1: (Base) -> () -> () : _T01a7DerivedC2m2yyF [override]
#Derived.m3!1: (Derived) -> () -> () : _T01a7DerivedC2m3yyF
}
This additional information will allow IRGen to emit the vtable
for Derived resiliently, without referencing the symbol for
the inherited method m1() directly.
The allocating thunk handles the `dynamic`-ness of the initializing entry point, which maps to an underlying `-initWith*:` ObjC method, and cannot itself be treated as `dynamic`. Fixes SR-5223 | rdar://problem/32778104.
