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

[Reid Kleckner]

On Thu, Jan 16, 2014 at 10:49 AM, Alp Toker <alp at nuanti.com> 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.
 =/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140116/c6652dfd/attachment.html>