<div dir="ltr">LGTM as a solution to the immediate issue, at least.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 11, 2013 at 7:10 PM, Faisal Vali <span dir="ltr"><<a href="mailto:faisalv@yahoo.com" target="_blank">faisalv@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi rsmith, doug.gregor,<br>
<br>
A quick fix to the bug introduced by generic-lambda-capturing that broke libc++.<br>
See <a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-November/033369.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-November/033369.html</a> for discussion on cfe-dev.<br>
<br>
This fix explicitly checks whether we are within the declcontext of a lambda's call operator - which is what I had intended to be true (and assumed would be true if getCurLambda returns a valid pointer) before checking whether we should check to see if the lambda can capture.<br>

<br>
A deeper fix (that addresses why getCurLambda() returns a valid pointer when perhaps it shouldn't?) - as proposed by Richard Smith in <a href="http://llvm.org/bugs/show_bug.cgi?id=17877" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=17877</a> - has been suggested as a FIXME.<br>

<br>
Will try and implement that at a later date - figured it is prolly important to not leave libc++ broken for too long (sorry about that).<br>
<br>
<br>
<br>
<br>
<a href="http://llvm-reviews.chandlerc.com/D2144" target="_blank">http://llvm-reviews.chandlerc.com/D2144</a><br>
<br>
Files:<br>
  lib/Sema/SemaExprCXX.cpp<br>
<br>
Index: lib/Sema/SemaExprCXX.cpp<br>
===================================================================<br>
--- lib/Sema/SemaExprCXX.cpp<br>
+++ lib/Sema/SemaExprCXX.cpp<br>
@@ -5988,9 +5988,24 @@<br>
   //   full-expression +n + ({ 0; }); ends, but it's too late for us to see that<br>
   //   we need to capture n after all.<br>
<br>
-  LambdaScopeInfo *const CurrentLSI = getCurLambda();<br>
-  if (CurrentLSI && CurrentLSI->hasPotentialCaptures() &&<br>
-      !FullExpr.isInvalid())<br>
+  LambdaScopeInfo *const CurrentLSI = getCurLambda();<br>
+  // FIXME: PR 17877 showed that CurrentLSI can exist even when the<br>
+  // CurContext is not a lambda call operator. Refer to that Bug Report<br>
+  // for an example of the code that might cause this asynchrony.<br>
+  // By checking whether we are in the context of a lambda's call operator<br>
+  // we can fix the bug (we only need to check whether we need to capture<br>
+  // if we are within a lambda's body); but per the comments in that<br>
+  // PR, a proper fix would entail :<br>
+  //   "Alternative suggestion:<br>
+  //   - Add to Sema an integer holding the smallest (outermost) scope<br>
+  //     index that we are *lexically* within, and save/restore/set to<br>
+  //     FunctionScopes.size() in InstantiatingTemplate's<br>
+  //     constructor/destructor.<br>
+  //  - Teach the handful of places that iterate over FunctionScopes to<br>
+  //    stop at the outermost enclosing lexical scope."<br>
+  const bool IsInLambdaDeclContext = isLambdaCallOperator(CurContext);<br>
+  if (IsInLambdaDeclContext && CurrentLSI &&<br>
+      CurrentLSI->hasPotentialCaptures() && !FullExpr.isInvalid())<br>
     CheckLambdaCaptures(FE, CurrentLSI, *this);<br>
   return MaybeCreateExprWithCleanups(FullExpr);<br>
 }<br>
</blockquote></div><br></div>