<div dir="ltr">On Fri, Jun 14, 2013 at 10:01 AM, Faisal Vali <span dir="ltr"><<a href="mailto:faisalv@gmail.com" target="_blank">faisalv@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Thu, Jun 13, 2013 at 12:58 PM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>> wrote:<br>
> On Tue, Jun 11, 2013 at 10:05 PM, Faisal Vali <<a href="mailto:faisalv@gmail.com">faisalv@gmail.com</a>> wrote:<br></div><div class="im">
> @@ -547,6 +550,18 @@<br>
><br>
> /// \brief The type of the call method.<br>
> TypeSourceInfo *MethodTyInfo;<br>
> +<br>
> + /// \brief The Lambda call method<br>
> + CXXMethodDecl *CallOperator;<br>
> +<br>
> + /// \brief The Lambda conversion operator, for non-capturing lambdas<br>
> + CXXConversionDecl *ConversionOperator;<br>
> +<br>
> + /// \brief The Lambda static method invoker, for non-capturing lambdas<br>
> + CXXMethodDecl *StaticInvoker;<br>
> +<br>
> + LambdaExpr *ParentLambdaExpr;<br>
><br>
> It's not obvious why you're making this change... we try to keep the AST as<br>
> small as possible.<br>
><br>
<br>
</div>I see, but how do you suggest I access this data when I need it?<br></blockquote><div><br></div><div>If you really do need it all, it's okay, I guess... it was just a bit surprising at first glance. Taking another look, it doesn't look like you're actually using getLambdaConversionOperator() (and in clang's implementation, lambdas can have multiple conversion operators).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
><br>
> + ParmVarDecl *PVD = cast<ParmVarDecl>(Param);<br>
> + // Handle 'auto' within a generic lambda.<br>
> + // FVQUESTION: Should I use getOriginalType here - how do i<br>
> + // know when to use which?<br>
> + QualType ParamType = PVD->getType();<br>
><br>
> If you're unsure, getType() is probably the right choice... I don't think it<br>
> matters here, though.<br>
><br>
<br>
</div>Thanks! What is the difference between the two?<br></blockquote><div><br></div><div>getOriginalType() returns the undecayed type; getType() returns the semantic type of the declaration.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> + if (getLangOpts().CPlusPlus1y && ParamType->getContainedAutoType()) {<br>
> + TemplateTypeParmDecl *TemplateParam =<br>
> + Actions.ActOnLambdaAutoParameter(getCurScope(), PVD,<br>
> + CurTemplateDepth, CurAutoParameterIndex);<br>
> + TemplateParams.push_back(TemplateParam);<br>
> + }<br>
><br>
> We generally prefer to avoid having code in Parser/ inspect AST types. Can<br>
> you move building the TemplateParameterList into<br>
> ActOnStartOfLambdaDefinition?<br>
><br>
<br>
<br>
</div>In my initial implementation of generic lambdas, I had encased this<br>
transformation<br>
entirely within ActOnStartOfLambdaDefinition (which is called once the parameter<br>
declaration clause has been constructed). In that version, I reconstructed<br>
the typesourceinfo and function type of the call operator after it was initially<br>
parsed and semanalyzed, by replacing each auto with a template type paramater,<br>
creating the template prameter list, and using a visitor to fix all<br>
subsequent references (ugh!)<br>
<br>
Based on sage advice from Doug, I moved the transformation upstream<br>
and the code changes<br>
have proved to be much leaner.<br></blockquote><div><br></div><div>Okay.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In regards to avoiding having the Parser inspect AST types What I<br>
could do is nest<br>
ActOnAutoParameter within ActOnParamDeclarator. Is it ok that I pass<br>
in a vector<br>
of TemplateTypeParamDecl* as an out parameter to ParseParameterDeclarationClause<br>
which I will then need to pass in to ActOnParamDeclarator? Or is it<br>
important that I find a way to do it without passing that vector around?<br></blockquote><div><br></div><div>That should be fine.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> +// The name of the static invoker function that will forward<br>
> +// to the corresponding lambda call operator.<br>
> +static inline const char* getSecretLambdaStaticInvokerStringID() {<br>
> + return "__invoker";<br>
> +}<br>
><br>
> I'm not sure how this abstraction is actually helpful, given the function<br>
> only has one use.<br>
><br>
<br>
</div>I figured it might be less brittle if more uses cropped up in the future. But<br>
I can just insert the name: "__invoker" in the one place i need it, and drop<br>
this function?<br></blockquote><div><br></div><div>I think so. We can always change it when we add more uses.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> + // FVQUESTION? When a generic lamdba call operator is being instantiated,<br>
> if<br>
> + // for some reason instantiation fails, the SemaDiagnosticEmitter ends up<br>
> + // emitting the entire instantiation stack, and since local pending<br>
> + // instantiations are called recursively,<br>
><br>
> We should not be instantiating the lambda in your example more than once at<br>
> the same time. If we are, it's probably a bug.<br>
><br>
<br>
<br>
</div>Does my workaround seem reasonable?<br><br></blockquote><div><br></div><div>Sorry, I'm not really an expert on template instantiation. Hopefully Doug will chime in.</div><div><br></div><div>-Eli </div></div><br>
</div></div>