Hi Argyrios, Richard,
I raised PR37399 and have been discussing how to fix it with Reid.
The root of the problem is an interaction between the MSCXXABI code and the fact that an injected-class-name is inserted into the decl list for class template specializations after the MSCXXABI code has added an attribute to the decl for the class template specialization (in a case involving a dependent base of the class template where the MSCXXABI code is invoked before the injected-class-name is instantiated).
The two options for fixing this problem either involve working around the fact that the injected-class-name is inserted into the decl list for the class template specialization by copying the MSCXXABI attribute to the injected-class-name decl when it’s added to the list (this works but feels ugly), or not inserting the injected-class-name into the decl list for the class template specialization (this causes a number of other tests to fail, possibly because ClassTemplateSpecializationDecl::getMostRecentDecl() explicitly works around the fact that there will be injected-class-names in the decl list for class template specializations, though as yet unconfirmed).
I have noticed that you have both put comments on ClassTemplateSpecializationDecl::getMostRecentDecl() which seem to suggest the fact that the injected-class-name is inserted into the decl list for the class template specialization seems to be an error in and of itself. Does it make more sense to try and clean up the fact that injected-class-names are inserted into the decl list, resulting in a broader change, or just try and point-fix the MSCXXABI issue?
I’m a clang newbie, so would appreciate any feedback you could give – TIA! Further details are in PR37399.
Yours, Andrew R
Hi Argyrios, Richard,
I raised PR37399 <https://llvm.org/PR37399> and have been discussing how
to fix it with Reid.
The root of the problem is an interaction between the MSCXXABI code and
the fact that an injected-class-name is inserted into the decl list for
class template specializations after the MSCXXABI code has added an
attribute to the decl for the class template specialization (in a case
involving a dependent base of the class template where the MSCXXABI code is
invoked before the injected-class-name is instantiated).
The two options for fixing this problem either involve working around the
fact that the injected-class-name is inserted into the decl list for the
class template specialization by copying the MSCXXABI attribute to the
injected-class-name decl when it’s added to the list (this works but feels
ugly), or not inserting the injected-class-name into the decl list for the
class template specialization (this causes a number of other tests to fail,
possibly because ClassTemplateSpecializationDecl::getMostRecentDecl()
explicitly works around the fact that there will be injected-class-names in
the decl list for class template specializations, though as yet
unconfirmed).
I have noticed that you have both put comments on
ClassTemplateSpecializationDecl::getMostRecentDecl() which seem to
suggest the fact that the injected-class-name is inserted into the decl
list for the class template specialization seems to be an error in and of
itself. Does it make more sense to try and clean up the fact that
injected-class-names are inserted into the decl list, resulting in a
broader change, or just try and point-fix the MSCXXABI issue?
I think it makes sense to try to clean this up more generally, if you're
interested in giving that a go. Here's the design that I would try: add a
new TypeDecl subclass for the injected-class-name (maybe
InjectedClassNameDecl), and represent the injected-class-name of all
classes as an InjectedClassNameDecl rather than a CXXRecordDecl.
I’m a clang newbie, so would appreciate any feedback you could give – TIA!