<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 16, 2014 at 7:13 AM, Nico Rieck <span dir="ltr"><<a href="mailto:nico.rieck@gmail.com" target="_blank">nico.rieck@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 14.07.2014 16:33, Alp Toker wrote:<br>
> We just started internal integration testing for 3.5. This 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 MinGW64 header<br>
> bug that was only fixed upstream in April 2014.<br>
><br>
> We'll want to remove setInvalidDecl() and make the diagnostic 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>
</div>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>
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).</blockquote><div><br></div><div>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.</div>
</div></div></div>