diseraluca wrote:

> > I gave it a quick try, and we would still end up with the same result in 
> > our codebase. But, generally, this would not probably be feasible for us as 
> > a solution.
> do you have an idea why? Can you show the diff of the changes you made? Is 
> the void specialization not explicit?

I did a quick test with this:

diff --git a/clang/lib/AST/QualTypeNames.cpp b/clang/lib/AST/QualTypeNames.cpp
index 26aaa96a1dc6..8b882eda83bb 100644
--- a/clang/lib/AST/QualTypeNames.cpp
+++ b/clang/lib/AST/QualTypeNames.cpp
@@ -287,8 +287,13 @@ static NestedNameSpecifier 
         // Make the situation is 'useable' but looking a bit odd by
         // picking a random instance as the declaring context.
-        if (ClassTempl->spec_begin() != ClassTempl->spec_end()) {
-          Decl = *(ClassTempl->spec_begin());
+        auto specialization_iterator = std::find_if(
+            ClassTempl->spec_begin(), ClassTempl->spec_end(), [](auto a) {
+              return !a->isExplicitInstantiationOrSpecialization();
+            });
+        if (specialization_iterator != ClassTempl->spec_end()) {
+          Decl = *specialization_iterator;
           Outer = dyn_cast<NamedDecl>(Decl);
           OuterNS = dyn_cast<NamespaceDecl>(Decl);

Do please let me know if this is incorrect or if I misunderstood your proposal.

We do have explicit references to the void specialization in the codebase so it 
would explain the previous choice. But I'm not aware of why it would be chosen 
as a non-explicit one too.

I can try to debug that on Monday if that can be useful. Albeit it might take 
some time.

cfe-commits mailing list

Reply via email to