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

[Rafael Espíndola]

On 23 January 2015 at 03:25, John McCall <rjmccall at apple.com> wrote:

> > On Jan 22, 2015, at 4:52 PM, Rafael Espíndola <
> 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.


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

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.


>   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/9e5fab16/attachment.html>