<div dir="ltr">On Tue, Jun 18, 2013 at 6:41 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.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 style="word-wrap:break-word"><div><div><div>On Jun 12, 2013, at 4:42 PM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>> wrote:</div>

<blockquote type="cite"><div dir="ltr">Take a C++ function like the following:<div><br></div><div><font face="courier new, monospace">inline void f() {</font></div><div><font face="courier new, monospace">  ^{</font></div>

<div style="margin:0px"><font face="courier new, monospace">    static int i = 0;</font></div><div style="margin:0px"><font face="courier new, monospace">    printf("%d\n", ++i);</font></div><div style="margin:0px">

<font face="courier new, monospace">  }();</font></div><div><font face="courier new, monospace">}</font></div><div><br></div><div>Looks pretty simple, right?  Unfortunately, trunk clang doesn't handle this correctly.  The primary issue here is we haven't defined the correct way to mangle the name of "i", and clang's current scheme is unusable because it depends on the details of IRGen.  (There's also the matter that we don't compute the linkage correctly, but that's a simple IRGen bug.)</div>


<div><br></div><div>I'm attaching a patch which expands the scheme we use for mangling lambda expressions in this sort of context to also work for block literals.  The patch is still a bit of a mess: there's a bunch of copy-paste code I still need to clean up, I haven't included tests, and it would probably be nice to include the parameter types of the block in the mangling.  That said, it essentially implements everything necessary.</div>

</div></blockquote><div><br></div></div>Unlike lambdas, we never actually need to mangle a block declaration;  we just encounter it as a context for local statics and types.  And much like we do with lambdas, we should just ignore the block as a context and mangle the static/type as a local declaration within the actual enclosing declaration.</div>

</div></blockquote><div><br></div><div>We discussed this in person; basically, we do in fact mangle lambdas into the context.</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 style="word-wrap:break-word"><div><div><blockquote type="cite"><div dir="ltr">
<div>Note that this doesn't touch the mangling scheme for the actual function definitions for blocks; they don't need to be externally visible, so we don't need to change the current mangling. </div>
<div><br></div><div>I'd like some feedback to make sure my patch is actually implementing something sane.</div></div></blockquote><div><br></div></div>Other than the mangling scheme, this seems reasonable.</div><div>

<div><br></div><blockquote type="cite"><div dir="ltr">Any suggestions for a better name than LambdaBlockMangleContext are also welcome.</div></blockquote><div><br></div></div><div>How about ClosureOwningContext?</div><span></span></div>

</blockquote></div><br></div><div class="gmail_extra">I ended up choosing MangleNumberingContext, given that we might need to add more to it in the future (e.g. static local variables).<br><br></div><div class="gmail_extra">
Attaching updated patch; this fixes some details like avoiding some of the code duplication, fixing the mangling so it makes a bit more sense, and includes some fixes to make our linkage computations for static local variables a bit more accurate.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-Eli<br></div></div>