WIP Patch: Introduce a proper mangling scheme for block literals

[John McCall]

On Jun 21, 2013, at 6:19 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Tue, Jun 18, 2013 at 6:41 PM, John McCall <rjmccall at apple.com> wrote:
> On Jun 12, 2013, at 4:42 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> Take a C++ function like the following:
>> 
>> inline void f() {
>>   ^{
>>     static int i = 0;
>>     printf("%d\n", ++i);
>>   }();
>> }
>> 
>> 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.)
>> 
>> 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.
> 
> 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.
> 
> We discussed this in person; basically, we do in fact mangle lambdas into the context.

Okay.  __block_prefix is still an unnecessarily long thing to put in the mangling, and I don't understand why you need to use a different mangling for an internal-linkage entity; that seems like it adds special cases to demangling for no reason.

Why not always "Ub <nonnegative-number> _"?

>> 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. 
>> 
>> I'd like some feedback to make sure my patch is actually implementing something sane.
> 
> Other than the mangling scheme, this seems reasonable.
> 
>> Any suggestions for a better name than LambdaBlockMangleContext are also welcome.
> 
> How about ClosureOwningContext?
> 
> I ended up choosing MangleNumberingContext, given that we might need to add more to it in the future (e.g. static local variables).

Static locals and anonymous types in general.

> 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.

Looks good.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130627/fee3cfbf/attachment.html>