<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 16, 2014 at 10:49 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 16/01/2014 18:28, Nico Rieck wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 16.01.2014 19:04, Reid Kleckner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think "full" here is OK.  In general, I *want* people to file bugs if<br>
there code compiles with cl and not clang -fms-compatibility, but I agree<br>
there are limits to how compatible we can be.  There are some areas where<br>
we can never be compatible, and we'll have to close them with wontfix /<br>
infeasible.  Users should be able to understand that.<br>
</blockquote>
How are warnings treated there?<br>
<br>
For example currently Clang ignores dllimport on typedefs and enums<br>
without warning with -fms-extensions. Aside from the fact that this, if<br>
at all, belongs to -fms-compatibility, the question remains. The<br>
original problem that introduced this is on rdar so I don't know what it<br>
is. I'd much rather axe that special treatment.<br>
<br>
And if -fms-compatibility is supposed to be required to compile with<br>
WinSDK headers, it would be a shame if these workarounds must always be<br>
applied globally.<br>
</blockquote>
<br></div>
I agree it's an unfortunate setup to have the full -fms-compatibility on by default on 'win' targets, given that we advertise clang as a standards-compliant frontend. That's after all the killer feature over MSVC which will get Windows developers looking our way, not the fact that we're a freebie replacement.<br>

<br>
On the other hand with MSVC ABI and header support tantalizingly close, the "drop-in by default" aspect is quite compelling.<br>
<br>
I think there's scope for tuning the default as a first step. Also possibly restricting the most odious workarounds so they only apply to system header source locations(?) -- but that's increasing the scope of an already large task, so there doesn't appear to be a clear immediate solution.<br>
</blockquote><div><br></div><div>In an ideal world, the way it's supposed to work is that every time we accept invalid code for compatibility purposes, we have a -Wmicrosoft warning that's supposed to fire.  Naturally, this would be suppressed in system headers.</div>
<div><br></div><div>In practice, -Wmicrosoft is a little unloved.  During a self-host, it fires on portable code in SROA due to some funny name lookup rules.  -Wmsvc-include, recently added, has similar problems.  I also doubt that it fires enough.</div>
<div><br></div><div>Echoing Alp, I see these diagnostic issues as lower priority than getting a working self-host build.  I can do it with local patches, but now I have to go back and reimplement inalloca with a new design, so it'll take longer.  =/</div>
</div></div></div>