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

[Reid Kleckner]

On Wed, Jan 15, 2014 at 11:42 AM, Nico Weber <thakis at chromium.org> wrote:

> On Wed, Jan 15, 2014 at 3:17 AM, Alp Toker <alp at nuanti.com> wrote:
>
>>
>> On 15/01/2014 05:59, Nico Weber wrote:
>>
>>  On Tue, Jan 14, 2014 at 11:13 AM, Alp Toker <alp at nuanti.com> wrote:
>>>
>>> Modified: cfe/trunk/include/clang/Driver/Options.td
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=199247&r1=199246&r2=199247&view=diff
>>>
>>> ==============================================================================
>>> --- cfe/trunk/include/clang/Driver/Options.td (original)
>>> +++ cfe/trunk/include/clang/Driver/Options.td Tue Jan 14 13:13:00 2014
>>> @@ -575,9 +575,9 @@ def fmessage_length_EQ : Joined<["-"], "
>>>  def fms_extensions : Flag<["-"], "fms-extensions">, Group<f_Group>,
>>> Flags<[CC1Option]>,
>>>    HelpText<"Accept some non-standard constructs supported by the
>>> Microsoft compiler">;
>>>  def fms_compatibility : Flag<["-"], "fms-compatibility">,
>>> Group<f_Group>, Flags<[CC1Option]>,
>>> -  HelpText<"Enable Microsoft compatibility mode">;
>>> +  HelpText<"Enable full Microsoft Visual C++ compatibility">;
>>>
>>
>>  Isn't "full" too strong? I thought this was more "enough to parse ms
>> sdk headers and link to mscrt", not "full" compatibility.
>>
>>
>> It isn't perfect, but we ran through a lot of options and this is the
>> only one that standard.
>>
>> That's why we'd do well to move away from the "ms sdk header" wording
>> (even if it's the current goal).
>>
>
> Yeah. With the "full compat" text, I'm afraid that people will keep doing
> this and file bugs on clang if their code doesn't build with -fms-compat
> even though it builds with cl.
>

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.


> I think it's about right now, but suggestions on the back of a postcard
>> welcome.
>>
>
> To me the difference between -fms-extensions and -ms-compat is that the
> first enables some relatively harmless things, while the latter enables
> things that actively contradict the standard, so I'd try to express this in
> the help text somehow.
>

The C++ ABI also implies lots of non-standards compliant behavior.  For
example, member pointers use a completely different model.  Inheriting from
two bases that override a method in a shared virtual base with different
covariant return types also doesn't work.  And those are just the ones I
can think of at the moment.  :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140116/eaf12c1d/attachment.html>