Due to the way type units work, this would lead to a declaration in a
type unit of a local type in a CU - which is ambiguous. Rather than
trying to resolve that relative to the CU that references the type unit,
let's just not try to simplify these names.
Longer term this should be fixed by not putting the template
instantiation in a type unit to begin with - since it references an
internal linkage type, it can't legitimately be duplicated/in more than
one translation unit, so skip the type unit overhead. (but the right fix
for that is to move type unit management into a DICompositeType flag
(dropping the "identifier" field is not a perfect solution since it
breaks LLVM IR linking decl/def merging during IR linking))
Lambda names aren't entirely canonical (as demonstrated by the
cross-project-test added here) at the moment (we should fix that for a
bunch of reasons) - even if the template referencing them is
non-simplified, other names referencing /that/ template can't be
simplified either because type units might cause a different template to
be picked up that would conflict with the expected name.
(other than for roundtripping precision, it'd be OK to simplify types
that reference types that reference lambdas - but best be consistent
between the roundtrip/verify mode and the actual simplified template
names mode)
Matching a recent clang change I've made, now 'int[3]' is formatted
without the space between the type and array bound. This commit updates
libDebugInfoDWARF/llvm-dwarfdump to match that formatting.
Actually we can, for now, remove the explicit "operator" handling
entirely - since clang currently won't try to flag any of these as
rebuildable. That seems like a reasonable state for now, but it could be
narrowed down to only apply to conversion operators, most likely - but
would need more nuance for op> and op>> since they would be incorrectly
flagged as already having their template arguments (due to the trailing
'>').
I'm not sure if there's a way to make this a bit more general - the
property that matters is that there's /some/ itanium ABI target the
tests can use to compile - not link or run in this case. But this seems
sufficient for the llgdb tests, so it should be sufficient (though
perhaps not necessary) for this roundtrip test.
Compilation is all that's needed here - linking helped avoid certain
false positives in llvm-dwarfdump --verify related to overlapping
functions when those functions were actually in distinct sections.
That's since been fixed, so we can adjust the test to only compile, and
not link.
This test was failing on the PS4 bot because the test attempts to link, but the PS4 platform requires an external
linker that is not present, causing the test to fail. This should get the PS4 bot green again.
David Blaikie