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.
And include some supplementary mangling changes:
- Give the first generic param (depth=0, index=0) a single character mangling. Even after removing the self type from method declaration types, 'Self' still shows up very frequently in protocol requirement signatures.
- Fix the mangling of generic parameter counts to elide the count when there's only one parameter at the starting depth of the mangling.
Together these carve another 154KB out of a debug standard library. There's some awkwardness in demangled strings that I'll clean up in subsequent commits; since decl types now only mangle the number of generic params at their own depth, it's context-dependent what depths those represent, which we get wrong now. Currying markers are also wrong, but since free function currying is going away, we can mangle the partial application thunks in different ways.
Swift SVN r32896
If these are actually resulting from something we should diagnose, we
should have already emitted diagnostics on these when emitting
diagnostics on the callee function.
This was reported as a compiler crash resulting from hitting an
llvm_unreachable() in the diagnostics code because we're attempting to
emit a diagnostic about a constructor not having a return value on some
path (and the code does not expect to be emitting these diagnostics from
constructors).
It turns out this was extremely difficult to reproduce because it
required a constructor with a compiler generated apply to a function
with an UnreachableInst in it that does not get replaced by another
diagnostics pass, DiagnoseUnreachable.
To satisfy the last of these conditions, I've added '-assert-config
Release' to the run line, because this results in a call to a no-return
function (one of the fatal error reporting functions) not getting
emitted because it is stripped out due to the assert configuration (and
DiagnoseUnreachable would have stripped the code after the no-return
function, and that code would have included the UnreachableInst that
triggers the crash this is fixing).
Fixes the rest of rdar://problem/20663080.
Swift SVN r28452
