[cfe-dev] Problems with injected-class-name in decl list for class template specializations

[Andrew Rogers via cfe-dev]

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'm a clang newbie, so would appreciate any feedback you could give - TIA! Further details are in PR37399<https://llvm.org/PR37399>.

Yours, Andrew R
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180512/9d8adb50/attachment.html>