<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 14, 2014 at 1:55 PM, Saleem Abdulrasool <span dir="ltr"><<a href="mailto:abdulras@fb.com" target="_blank">abdulras@fb.com</a>></span> wrote:<br><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"><span class=""><br>
On Oct 14, 2014, at 10:56 AM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
<br>
> On Tue, Oct 14, 2014 at 10:20 AM, Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org">compnerd@compnerd.org</a>> wrote:<br>
> Author: compnerd<br>
> Date: Tue Oct 14 12:20:14 2014<br>
> New Revision: 219696<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=219696&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=219696&view=rev</a><br>
> Log:<br>
> CodeGen: correct mangling for blocks<br>
><br>
> This addresses a regression introduced with SVN r219393.  A block may be<br>
> contained within another block.  In such a scenario, we would end up within a<br>
> BlockDecl, which is not a NamedDecl (as the names are synthesised).  The cast to<br>
> a NamedDecl of the DeclContext would then assert as the types are unrelated.<br>
><br>
> Restore the mangling behaviour to that prior to SVN r219393.  If the current<br>
> block is contained within a BlockDecl, walk up to the parent DeclContext,<br>
> recursively, until we have a non-BlockDecl.  This is expected to be a NamedDecl.<br>
> Add in a couple of asserts to ensure that the assumption that we only encounter<br>
> a block within a NamedDecl or a BlockDecl.<br>
><br>
> What about nested global blocks or blocks in CapturedDecls?<br>
<br>
</span>What do you mean by global blocks here?  I assume you mean blocks at the file scope rather than global blocks in reference to Global vs Stack vs Heap blocks.  If so, yes, those are broken, Ive not fixed that (yet), but I intend to do that soon.  I had these two ready, so I decided to at least improve the state rather than leave it as broken as it is currently.  That was partially the reason that I added the assertion, so that the assertion triggered would be much easier to catch it.</blockquote><div><br></div><div>Yeah, file scope. The mangler uses the name mangleGlobalBlock, so that's what I went with. :)</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"><span class="">
> Also, I don't think we need distinct manglings for blocks in different Ctor variants. We can probably significantly simplify the API if we always mangle the block using the "base" variant of the ctor/dtor.<br>
<br>
</span>The change didn’t really touch the ctor/dtor behaviour.  Im afraid that Im not really following you here.</blockquote><div><br></div><div>I guess I'm saying that mangleCtorBlock's API seems broken by design, because we shouldn't invent different manglings for the same block across different ctor variants.</div></div></div></div>