<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 16, 2014 at 2:00 PM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
On 16/07/2014 23:03, Reid Kleckner wrote:<div class=""><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Wed, Jul 16, 2014 at 7:13 AM, Nico Rieck <<a href="mailto:nico.rieck@gmail.com" target="_blank">nico.rieck@gmail.com</a> <mailto:<a href="mailto:nico.rieck@gmail.com" target="_blank">nico.rieck@gmail.com</a>>> wrote:<br>

<br>
    On 14.07.2014 16:33, Alp Toker wrote:<br>
    > We just started internal integration testing for 3.5. This<br>
    commit breaks<br>
    > cross-compilation bootstrap builds to Windows from Fedora 20, Ubuntu<br>
    > 14.04 and other current distributions, I believe due to a<br>
    MinGW64 header<br>
    > bug that was only fixed upstream in April 2014.<br>
    ><br>
    > We'll want to remove setInvalidDecl() and make the diagnostic<br>
    either (a)<br>
    > a DefaultError warning complete with a warning group name or (b) a<br>
    > SuppressInSystemHeader error.<br>
    ><br>
    > Do you know what the correct recovery is when accepting the invalid<br>
    > code? Should we drop or accept the attribute, and does that decision<br>
    > change based on whether we're in GCC or MSVC compatibility mode?<br>
<br>
    GCC's behavior here seems strange. They don't diagnose the case of<br>
    adding a dll attribute. If you define a function, then declare it as<br>
    imported, the definition will be emitted, but the imported declaration<br>
    is used. Which code triggers this diagnostic?<br>
<br>
</blockquote>
<br>
</div><a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140331/102567.html" target="_blank">http://lists.cs.uiuc.edu/<u></u>pipermail/cfe-commits/Week-of-<u></u>Mon-20140331/102567.html</a><br>
<br>
(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.)<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
    So for GCC-compat the attribute has to be accepted. But I have no idea<br>
    whether user code relies on this so I would tend to (a).<br>
<br>
<br>
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.<br>
</blockquote>
<br></div>
A warning is fine by me. Reid / Nico, could you suggest a name for the diagnostic group?</blockquote><div><br></div><div>As a strawman, -Wdll-attributes?  It would fit into this existing warning hierarchy:</div><div><br>
</div><div><div>def NSobjectAttribute : DiagGroup<"NSObject-attribute">;</div><div>def UnknownAttributes : DiagGroup<"unknown-attributes">;</div><div>def IgnoredAttributes : DiagGroup<"ignored-attributes">;</div>
<div>def Attributes : DiagGroup<"attributes", [UnknownAttributes,</div><div>                                          IgnoredAttributes]>;</div></div></div></div></div>