On 15/01/2014 05:59, Nico Weber wrote:
On Tue, Jan 14, 2014 at 11:13 AM, Alp Toker <[email protected]
<mailto:[email protected]>> wrote:
Author: alp
Date: Tue Jan 14 13:13:00 2014
New Revision: 199247
URL: http://llvm.org/viewvc/llvm-project?rev=199247&view=rev
Log:
Clarify driver/frontend -fms-compatibility help text
Better describe the flag that enables drop-in MSVC compatibility,
including
ability to parse MS standard headers. This is intended to
distinguish it from
-fms-extensions, the more established and 'gentler' flag also
supported by GCC.
The new wording matches up with the internal description
introduced in r198936.
Still room for improvement (e.g. C++ is part of the product name,
yet the flag
also applies to C) but it's a step forward from "Microsoft mode".
Modified:
cfe/trunk/include/clang/Driver/Options.td
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.
In so far as it enables the "full" set of compatibility features this
one works well.
Other options evaluated:
* "drop-in": Sounds like a knock off or clone, and could be taken
literally (I deleted cl.exe and dropped it in!)
* "seamless": Implies subtlety and non-breaking of existing code,
which isn't always the case.
* No word: Same problem as 'seamless'. "Compatible with existing code,
or compatible with MSVC?"
* "mode": There are other modes which only make minor changes to the
parser -- this didn't work out in past
* "Microsoft system headers": none -fms-compatibility is currently
restricted to system headers -- it fully changes the behaviour of
the compiler in various ways.
Also, facepalm link:
"Clang does't compile gcc compatible c++ code? -fms-compatibility is
your friend"
http://codingdave.blogspot.co.uk/2012/08/clang-doest-compile-gcc-compatible-c.html
/"Although this parameter was introduced to make clang compile visual
c++ headers, it also fixes problems like the one above."/
That's why we'd do well to move away from the "ms sdk header" wording
(even if it's the current goal).
I think it's about right now, but suggestions on the back of a postcard
welcome.
Alp.
def fmsc_version : Joined<["-"], "fmsc-version=">,
Group<f_Group>, Flags<[CC1Option, CoreOption]>,
- HelpText<"Version of the Microsoft C/C++ compiler to report in
_MSC_VER (0 = don't define it (default))">;
+ HelpText<"Microsoft compiler version number to report in
_MSC_VER (0 = don't define it (default))">;
def fdelayed_template_parsing : Flag<["-"],
"fdelayed-template-parsing">, Group<f_Group>,
HelpText<"Parse templated function definitions at the end of the "
"translation unit">, Flags<[CC1Option]>;
_______________________________________________
cfe-commits mailing list
[email protected] <mailto:[email protected]>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
--
http://www.nuanti.com
the browser experts
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
