dblaikie added a comment.
While looking into some debug info issues* I've come across what I think are
some inconsistencies in the handling of this attribute - @rsmith mind taking a
look?
Firstly, it looks like something isn't handled when it comes to templates where
only the declaration of a template with a preferred name is instantiated, but
not the definition:
template<typename T>
struct t1;
using t1i = t1<int>;
template<typename T1>
struct
#ifdef PREF
__attribute__((__preferred_name__(t1i)))
#endif
t1 {
};
template<typename T>
struct t2 {
};
int main() {
t2<t1i> v1;
#ifdef DEF
t1i v2;
#else
t1<long> v2; // just leave this here so AST dump is similar with/without
the t1i definition
#endif
}
Compile with `-DPREF -Xclang -ast-dump` and compare the output with/without
`-DDEF`. With the definition, the ast dump uses the preferred name when
printing the use of `t1i` as `t2`'s template argument, without the definition
it dumps as the raw `t1<int>` instead:
CXXConstructorDecl 0x10d9cd48 <col:8> col:8 implicit constexpr t2 'void
(const t2<t1i> &)' inline default trivial noexcept-unevaluated 0x10d9cd48
CXXConstructorDecl 0x120cb0f8 <col:8> col:8 implicit constexpr t2 'void
(const t2<t1<int>> &)' inline default trivial noexcept-unevaluated 0x120cb0f8
(unrelated to this, but related to how I came across this: I think it might be
desirable to have a PrintingPolicy to turn off using the preferred name,
specifically so we can use this when rendering a template name in DWARF - so
the name is consistent with the `DW_TAG_template_type_parameter` - better
chance of cross-compiler compatibility, etc - I've considered going the other
way, and using the preferred name in the `DW_TAG_template_type_parameter` but
worry that'll cause even more divergence between compilers & make things more
difficult for the consumer (but they could support it, if they looked through
typedefs/alias templates when doing structural equivalence between template
descriptions in DWARF (which they kind of have to do anyway, because there's a
bunch of other ways that names aren't exactly the same all the time - which,
maybe that's a reason not to worry about the use of preferred names in the
textual description today? Since the names aren't directly matchable anyway...
- I haven't tested that too much to see how much divergence there is ignored by
existing consumers))
- The preferred name shows up in template type parameters - but that then
mismatches with the `DW_TAG_template_type_parameter` which uses the underlying
type. I have been experimenting with a patch to use the preferred type even
there, but that might cause more significant/problematic mismatch between DWARF
produced by different compilers, unless they're able to look through
typedefs/alias templates when structurally comparing two type descriptions.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D91311/new/
https://reviews.llvm.org/D91311
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
