[PATCH] D70537: [clang] CGDebugInfo asserts `!DT.isNull()` when compiling with debug symbols

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

Yeah, this is working around a more fundamental representational issue.

Like member function templates, member variable templates shouldn't be pre-emptively built or ever appear in the "members" list of the type (because that list isn't closed - we don't know what instantiations would be needed when the type is built so member template instantiations never appear in the member list, but instead the type appears as the scope of the member template instantiation and are added as member DIEs during DWARF emission lazily (eg: if a member function template instantiation gets optimized away, nothing of it remains and no member function template declaration of that instantiation will appear in as a child of the type DIE))

For instance, it seems creating two instantiations of a member variable template seems to get messed up by having a member list with the same instantiation twice:

  !9 = !DIDerivedType(tag: DW_TAG_member, name: "variable", scope: !10, file: !3, line: 3, baseType: !12, flags: DIFlagStaticMember, extraData: i32 0)
  !10 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "type", file: !3, line: 1, size: 8, flags: DIFlagTypePassByValue, elements: !11, identifier: "_ZTS4type")
  !11 = !{!9, !9}

Even though !7 is another member variable template instantiation.

(here's the source:

  struct type {
    template <typename T>
    inline static auto variable = T();
  };
  int main() {
    type t;
    int i = type::variable<int>;
    float f = type::variable<float>;
  }

So clearly something is modifying the "members" list (since it'd be created empty after the "type t;" line, then a member variable template for the variable<int> would be added to the member list, then when it goes to add "variable<float>" it gets messed up and adds another copy of !9)

Oh... both variable<int> and variable<float> definitions share a single declaration DIDerivedType... that's no good.

I'm also generally wondering if variable template instantiations should have the template parameters in their name, same as function templates - currently they don't in LLVM's output at least. Building GCC 9.2 to compare there.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70537/new/

https://reviews.llvm.org/D70537