On Thu, Jan 16, 2014 at 10:49 AM, Alp Toker <[email protected]> wrote: > > On 16/01/2014 18:28, Nico Rieck wrote: > >> On 16.01.2014 19:04, Reid Kleckner wrote: >> >>> I think "full" here is OK. In general, I *want* people to file bugs if >>> there code compiles with cl and not clang -fms-compatibility, but I agree >>> there are limits to how compatible we can be. There are some areas where >>> we can never be compatible, and we'll have to close them with wontfix / >>> infeasible. Users should be able to understand that. >>> >> How are warnings treated there? >> >> For example currently Clang ignores dllimport on typedefs and enums >> without warning with -fms-extensions. Aside from the fact that this, if >> at all, belongs to -fms-compatibility, the question remains. The >> original problem that introduced this is on rdar so I don't know what it >> is. I'd much rather axe that special treatment. >> >> And if -fms-compatibility is supposed to be required to compile with >> WinSDK headers, it would be a shame if these workarounds must always be >> applied globally. >> > > 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. > > On the other hand with MSVC ABI and header support tantalizingly close, > the "drop-in by default" aspect is quite compelling. > > 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. >
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. 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. 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. =/
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
