On Wed, Jan 15, 2014 at 11:42 AM, Nico Weber <[email protected]> wrote:
> On Wed, Jan 15, 2014 at 3:17 AM, Alp Toker <[email protected]> wrote: > >> >> On 15/01/2014 05:59, Nico Weber wrote: >> >> On Tue, Jan 14, 2014 at 11:13 AM, Alp Toker <[email protected]> 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. :)
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
