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

[David Majnemer]

On Fri, Jan 23, 2015 at 12:25 AM, 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.
>
> 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.  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.
>

Some of my argument against eagerly emitting IR comes stems from how we
handle the following:
struct S;

typedef void (*FP)(struct S);

void f(FP x) { }

struct S { int i; };

void g() { f(0); }

When we are emitting f, we decide that FP should have IR type {}*.
However, the definition of 'S' is available when we are emitting 'g' and so
we decide that FP have IR type void (i32)*.

The fact that types change from under us is very surprising.


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