[PATCH] D91311: Add new 'preferred_name' attribute.

[David Blaikie via Phabricator via cfe-commits]

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