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

[Rafael Espíndola]

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

> On Jan 23, 2015, at 11:04 AM, Rafael Espíndola <rafael.espindola at gmail.com>
> wrote:
>
>> 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.
>>
>
> The bug first got reported to us while trying to build glibc. The bug
> Richard noticed was fixed in gcc because it was breaking the linux kernel.
> If anyone thinks it is productive to try to get them to change, go for it.
>
>
> Sorry, do these open-source projects no longer accept patches?  Adding
> section attributes after a definition does not seem defensible to me, and I
> would guess that the declarations are actually in the same file, just in
> the wrong order.
>
>
Maybe, but I have better things to do than being a message boy between your
opinion on gnu extensions and their use of them.


> “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.
>>
>>
> It is an example where we *were* diagnosing. Except that then we cannot
> build firefox or chrome. You are also more than welcome to get them to
> change because you don't like how gcc implemented an extension.
>
>
> There are ways to work with projects so that you can carefully roll out a
> diagnostic without completely shutting down development for everyone.  This
> is a danger literally every time we add a warning.  We’re not going to stop
> adding warnings.
>
>
If anyone is interested. Check the thread on r175326.That were we decide to
go with "We should just not cache visibility for types." which created the
horrible situation in PR16187.

Going back would required chrome (and any other project trying to optimize
their .so really) to add visibility attributes to every forward declaration
of a type if the definition has it.

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