The goal here is to make the short demangling as short and readable as possible, also at the cost of omitting some information.
The assumption is that whenever the short demangling is displayed, there is a way for the user to also get the full demangled name if needed.
*) omit <where ...> because it does not give useful information anyway
Deserializer.deserialize<A where ...> () throws -> [A]
--> Deserializer.deserialize<A> () throws -> [A]
*) for multiple specialized functions only emit a single “specialized”
specialized specialized Constructible.create(A.Element) -> Constructible<A>
--> specialized Constructible.create(A.Element) -> Constructible<A>
*) Don’t print function argument types:
foo(Int, Double, named: Int)
--> foo(_:_:named:)
This is a trade-off, because it can lead to ambiguity if there are overloads with different types.
*) make contexts of closures, local functions, etc. more readable by using “<a> in <b>” syntax
This is also done for the full and not only for the simplified demangling.
Renderer.(renderInlines([Inline]) -> String).(closure #1)
--> closure #1 in Renderer.renderInlines
*) change spacing, so that it matches our coding style:
foo <A> (x : A)
--> foo<A>(x: A)
Simply mangling the derived method is no longer sufficient. Now also
mangle the base method, so that eventually we handle this sort of
scenario:
class Base {
// introduces: Base.method
func method(_: Int, _: Int) {}
}
class First : Base {
// overrides: Base.method
// introduces: First.method
override func method(_: Int?, _: Int) {}
}
class Second : First {
// overrides: Base.method, First.method
// introduces: Second.method
override func method(_: Int?, _: Int?) {}
}
Here, the override of Base.method by Second.method and the
override of First.method by Second.method require distinct
manglings even though the derived method (Second.method) is
the same in both cases.
Note that while the new mangling is longer, vtable thunks are
always emitted with private linkage, so with the exception of
the standard library which is built with -sil-serialize-all
they will not affect the size of dylibs.
The standard library itself has very few classes so it doesn't
matter there either.
This patch doesn't actually add any support to introduce new
vtable entries for methods that override; this is coming up
next.
Textual SIL was sometimes ambiguous when SILDeclRefs were used, because the textual representation of SILDeclRefs was the same for functions that have the same name, but different signatures.
Textual SIL was sometimes ambiguous when SILDeclRefs were used, because the textual representation of SILDeclRefs was the same for functions that have the same name, but different signatures.
For this we need to store the linkage of the “original” method implementation in the vtable.
Otherwise DeadFunctionElimination thinks that the method implementation is not public but private (which is the linkage of the thunk).
The big part of this change is to extend SILVTable to store the linkage (+ serialization, printing, etc.).
fixes rdar://problem/29841635
