<div dir="ltr">Is the real problem that we're entering the lambda scope too early? The scope shoudn't start until we get to the body -- things referenced from within the parameter-declaration-clause of the inner lambda should not be captured by it, so the LSI->Lambda pointer for the inner lambda should never be referenced until we're ready to capture.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 29, 2015 at 10:09 AM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ping<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Apr 23, 2015 at 11:31 AM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>> wrote:<br>
> Ping<br>
><br>
> On Fri, Apr 10, 2015 at 10:08 AM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>> wrote:<br>
>> PR23021 demonstrates a case where diagnostic reporting on an inner<br>
>> lambda would crash due to a null pointer dereference. Since captures<br>
>> happen from calling ParseParameterDeclarationClause, which is before<br>
>> the semantic lambda object is created, another mechanism is required<br>
>> to get the lambda introducer location.<br>
>><br>
>> This patch addresses it by storing the introducer location into the<br>
>> scope object directly, and using that location when reporting the<br>
>> diagnostics. The result is the same, but no longer relies on a lambda<br>
>> object being created first.<br>
>><br>
>> ~Aaron<br>
</div></div></blockquote></div><br></div>