Specializations are implementation details, and thus shouldn't be
public, even if they are specializing a public function. Without this
downgrade, the ABI of a module depends on random internal code
(could change inlining decisions etc.), as well as swiftc's optimiser.
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)
When DynamicSelfType occurs outside of a class body (for example,
inside of a SIL function), it is not enough to simply utter 'Self',
because then we lose the underlying type.
Instead, print it out as '@dynamic_self Foo', where 'Foo' is the
underlying class type or archetype, and add parser support for
the same.
Fixes <rdar://problem/27735857>.
For long names this is easier to read and in most cases the omitted information can be seen in the actual SIL code.
With the option -Xllvm -sil-full-demangle the old behavior can be restored.
