[cfe-dev] [Possible regression?] Canonical decl of friend template decls in dependent contexts

[John McCall via cfe-dev]

> On Oct 13, 2017, at 5:02 AM, Vassil Vassilev via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> On 13/10/17 00:17, slycelote wrote:
>> Consider the following:
>> 
>> 
>> template<typename T>
>> struct C; // d1
>> 
>> template<typename T>
>> class D {
>>     static void f() {}
>> 
>>     template<typename>
>>     friend struct C; // d2
>> };
>> 
>> template<typename T>
>> struct C { }; // d3
>> 
>> int main() { }
>> 
>> 
>> Here there are 3 declarations corresponding to class template C (marked
>> as d1, d2 and d3).
>> 
>> In clang 3.9 getCanonicalDecl() for all 3 of them returns d1. Starting
>> from clang 4.0, d2->getCanonicalDecl() == d2. As far as I can tell, this
>> is caused by commit 291753 [1].
>   That was intentional because keeping friend declarations in the redecl chain confuses the template instantiator. That's visible especially with modules.
>> 
>> Is this intended? It looks to me, that, for example,
>> clang::declaresSameEntity(d1, d2) [2] will return a wrong result.
>   Richard, would it be feasible to not add the fiend decl to the redecl chain but to still rewire it to the 'right' canonical decl. That way getMostRecentDecl() won't return d2 (in some cases) and declaresSameEntity(d1,d2) will return true?

This would've been useful when I was implementing access control originally.  There's some pretty low-level complexity forced by the attempt to maintain a single chain of redeclarations.  I'm thinking particularly of how friend declarations have to inherit the right IDNS from the original declaration because they replace it as the most recent declaration.

And in practice it's possible for lookup to find an older declaration anyway (because of things like UsingShadowDecls).

John.

>> 
>> 
>> [1] https://llvm.org/viewvc/llvm-project?view=revision&revision=291753 <https://llvm.org/viewvc/llvm-project?view=revision&revision=291753>
>> [2]
>> https://clang.llvm.org/doxygen/namespaceclang.html#ad9d926b16adbdbc93705737b69d47cae <https://clang.llvm.org/doxygen/namespaceclang.html#ad9d926b16adbdbc93705737b69d47cae>
>> 
>> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171013/02edeb1f/attachment.html>