r199247 - Clarify driver/frontend -fms-compatibility help text

Alp Toker alp at nuanti.com
Thu Jan 16 10:49:51 PST 2014


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.

Let's keep an eye on this. Might be easier to turn a blind eye for the 
next few weeks and develop a plan post MSVC-selfhost, given that 
everyone's racing towards functional completeness right now.

Alp.


>
> There's already the case with -fdelayed-template-parsing that Clang
> accepts broken user-code without any notice and bails on certain valid
> things (like template and constexpr combinations), and it's enabled by
> default.
>
> -Nico
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

-- 
http://www.nuanti.com
the browser experts




More information about the cfe-commits mailing list