[cfe-commits] [PATCH] PR12917: fix lambda mangling within templates

[Douglas Gregor]

On Jul 16, 2012, at 3:28 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> Hi,
> 
> As PR12917 notes, the mangling of lambads within templates is currently wrong -- not only do we not follow the ABI, we sometimes give the same mangled name to multiple lambdas. We use the templated declaration as the mangling context rather than the instantiation, and we don't take into account that the mangling number can depend on the number of template arguments if the template is variadic.
> 
> The attached patch fixes this by delaying the computation of the mangling information for a lambda in a dependent context until after instantiation.
> 
> Please review!

@@ -128,9 +126,12 @@
       }
     }        
     
+    unsigned ManglingNumber;
     switch (Kind) {
       case Normal:
-        if (CurContext->isDependentContext() || isInInlineFunction(CurContext))
+        if ((!ActiveTemplateInstantiations.empty() &&
+             !(ContextDecl && isa<ParmVarDecl>(ContextDecl))) ||
+            isInInlineFunction(CurContext))
           ManglingNumber = Context.getLambdaManglingNumber(Method);
         else
           ManglingNumber = 0;
@@ -140,7 +141,10 @@
         break;
         
       case StaticDataMember:
-        if (!CurContext->isDependentContext()) {
+        if (ActiveTemplateInstantiations.empty()) {
+          // A mangling number for a lambda in a static data member of a class
+          // template is only assigned when the data member is instantiated
+          // from the template.
           ManglingNumber = 0;
           ContextDecl = 0;
           break;

I don't understand why we're checking ActiveTemplateInstantiations.empty() in these cases. That only tells us whether there's an instantiation occurring at any point; it isn't necessarily the right answer if we're instantiating, e.g., the declaration of a member template within a class template instantiation.

	- Doug