r205197 - Sema: Check dll attributes on redeclarations
Reid Kleckner
rnk at google.com
Mon Aug 4 14:29:36 PDT 2014
On Wed, Jul 16, 2014 at 2:00 PM, Alp Toker <alp at nuanti.com> wrote:
>
> On 16/07/2014 23:03, Reid Kleckner wrote:
>
> On Wed, Jul 16, 2014 at 7:13 AM, Nico Rieck <nico.rieck at gmail.com
>> <mailto:nico.rieck at gmail.com>> wrote:
>>
>> On 14.07.2014 16:33, Alp Toker wrote:
>> > We just started internal integration testing for 3.5. This
>> commit breaks
>> > cross-compilation bootstrap builds to Windows from Fedora 20, Ubuntu
>> > 14.04 and other current distributions, I believe due to a
>> MinGW64 header
>> > bug that was only fixed upstream in April 2014.
>> >
>> > We'll want to remove setInvalidDecl() and make the diagnostic
>> either (a)
>> > a DefaultError warning complete with a warning group name or (b) a
>> > SuppressInSystemHeader error.
>> >
>> > Do you know what the correct recovery is when accepting the invalid
>> > code? Should we drop or accept the attribute, and does that decision
>> > change based on whether we're in GCC or MSVC compatibility mode?
>>
>> GCC's behavior here seems strange. They don't diagnose the case of
>> adding a dll attribute. If you define a function, then declare it as
>> imported, the definition will be emitted, but the imported declaration
>> is used. Which code triggers this diagnostic?
>>
>>
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-
> Mon-20140331/102567.html
>
> (At this point I'm in favour of relaxing the warning as much as necessary
> in order not to regress MinGW support in the upcoming release.)
>
>
>
>> So for GCC-compat the attribute has to be accepted. But I have no idea
>> whether user code relies on this so I would tend to (a).
>>
>>
>> I don't think this extension-of-an-extension is so bad that it needs a
>> DefaultError warning. I'd just do a regular warning, which of course will
>> be silenced in a system header.
>>
>
> A warning is fine by me. Reid / Nico, could you suggest a name for the
> diagnostic group?
As a strawman, -Wdll-attributes? It would fit into this existing warning
hierarchy:
def NSobjectAttribute : DiagGroup<"NSObject-attribute">;
def UnknownAttributes : DiagGroup<"unknown-attributes">;
def IgnoredAttributes : DiagGroup<"ignored-attributes">;
def Attributes : DiagGroup<"attributes", [UnknownAttributes,
IgnoredAttributes]>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140804/9078dcb7/attachment.html>
More information about the cfe-commits
mailing list