[cfe-dev] Question about Decls representing member classes of class templates

Keane, Erich via cfe-dev cfe-dev at lists.llvm.org
Fri Sep 7 08:14:03 PDT 2018


I seem to remember adding a bit to the Attr.td class to do exactly this (have an attribute propagate to instantiations).  It seems to have changed names unfortunately and my git-fu seems to have failed me here, but there if I would guess, I'd say the following is the current incantation:

// Set to true if this attribute meaningful when applied to or inherited
  // in a class template definition.
  bit MeaningfulToClassTemplateDefinition = 0;


You should be able to put 
"MeaningfulToClassTemplateDefintion = 1" in your review and have it work I think?



-----Original Message-----
From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Louis Dionne via cfe-dev
Sent: Friday, September 7, 2018 8:08 AM
To: Clang Dev <cfe-dev at lists.llvm.org>
Subject: [cfe-dev] Question about Decls representing member classes of class templates

Hi,

This is a noob question.

I'm working on the no_extern_template attribute discussed at [1] and I encountered something I don't understand in Clang. I traced through the code but couldn't find an answer, so I thought I'd ask here in case the question is easy to answer for someone else.

I have the following class with an explicit template instantiation:

    template <typename T>
    struct Foo {
        struct __attribute__((no_extern_template)) member_class { };
    };

    template struct Foo<int>;

The no_extern_template is the attribute I'm trying to add. My problem is that in Sema::InstantiateClassMembers (triggered by the explicit instantiation), the Decl representing member_class does not seem to have any attribute applied to it. However, I was able to trace code in ProcessDeclAttribute() (in Sema/SemaDeclAttr.cpp) where a Decl representing member_class does have the no_extern_template associated to it. I also noticed that the Decl in ProcessDeclAttribute() and in Sema::InstantiateClassMembers() were different Decl objects, but both representing the same type (or at least they have the same getNameAsString()). Note that I don't have the same problem with static/non-static member functions -- only member classes seem to have multiple Decls going around with different attributes.

My questions are:
- Why are there two Decl instances representing the same class?
- How can I make sure that all Decl instances representing the same class get the same attributes?

I uploaded the patch I have so far here to give some context: https://reviews.llvm.org/D51789

Thanks,
Louis

[1]: http://lists.llvm.org/pipermail/cfe-dev/2018-August/059024.html

_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


More information about the cfe-dev mailing list