[patch][pr22217] Use the most recent decl for mangling

[John McCall]

> On Jan 23, 2015, at 5:43 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> On 23 January 2015 at 03:25, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
> > On Jan 22, 2015, at 4:52 PM, Rafael Espíndola <rafael.espindola at gmail.com <mailto:rafael.espindola at gmail.com>> wrote:
> >
> > Sent the email a bit early.
> >
> >
> >>> That is not what I am seeing with gcc. Given
> >>>
> >>> int pr22217_foo;
> >>> int *b = &pr22217_foo;
> >>> extern int pr22217_foo __attribute__((section("zed")));
> 
> This should be an error in both C and C++.  I see absolutely no reason to allow a declaration following a definition (even a tentative definition) to add a section attribute.  We should not be afraid to reject stupidly-written code when it abuses language extensions, even when they’re not “our” extensions.
> 
> 
> Not sure if that is viable fight on our side, but we can try making it an error and see.

How is it not a viable fight?  Is the section attribute coming from a completely different place?  Or are you suggesting that it is never viable to tell people that they ought to fix their code, no matter how unnecessarily perverse it is?  A section should be an intrinsic part of an definition, saying that you can’t define the same thing in multiple inconsistent ways is not even slightly unreasonable.
 
> There are fair arguments against our current emit-as-you-go IRGen model, but allowing us to more perfectly emulate GCC’s bugs is not one of them.  Nor is there a need to exactly copy GCC’s visibility model in every conceivable case.
> 
> So, the case in pr16187 is one where I think there is no question that our answer is worse than gcc's. The *same* type shows up as both hidden and default. If this was a new language we were designing, it is hard to imagine a worse compromise.
> 
> The reason we got there is that we tried and failed to enforce a stricter models. First one that says that we can compute the type early and then one that says we can compute it on first "use". Both have failed to build real world software, which IMHO is a fundamental requirement for clang.

“Build everything GCC can without modification” has never been a fundamental requirement for clang, though, and that appears to be your standard.

PR16187 is an example that I would feel fairly comfortable diagnosing.  You could certainly construct a more challenging example, though.

> The case of "typedef struct {...} foo;" doesn't look as widespread, but it is unfortunately a core part of the language (not a gcc extension) that we cannot currently implement.

You’ll need to remind me what it is that we can’t implement here.

Also, I don’t think there’s ever a case where we initiate IRGen during the parsing of a top-level declaration (we even take this to unnecessary extremes, e.g. with namespaces), and if there is, it should not be too difficult to avoid doing so.

John.
 
>   One very nice incidental advantage of emit-as-you-go is that it encourages us to ensure that language decisions are made locally by the declarations involved, which — beyond simply being better language design in and of itself — also means that they’re not susceptible to random breakage by differences in module import.
> 
> An interesting language design advice, but given the requirement that clang continues to build real c++ code, it is important to ask if we are not pushing ourselves to solutions that are worse than what gcc does (which I am sure is the case in pr16187).
> 
> Cheers,
> Rafael
> 

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