[cfe-commits] r142797 - in /cfe/trunk: lib/Frontend/CompilerInvocation.cpp test/Lexer/ms-extensions.c

[Douglas Gregor]

On Oct 24, 2011, at 11:04 AM, David Blaikie wrote:

>> -fms-extensions = allow Microsoft extensions without sacrificing language conformance
>> 
>> -fms-compatibility = do crazy non-standard things to try to eat the broken code that Microsoft's compiler accepts. In other words, try to be as MSVC-like as Clang can be.
> 
> Well it means "eat the broken code that Microsoft's compiler accepts"
> but in some cases (I believe) the same code compiles with both
> compilers but may have different semantics, right?

Yes, it can happen.

> So if I'm ever
> compiling my code with MSVC I sort of want to compile/test it with
> -fms-compatibility to make sure I don't get subtle changes in behavior
> due to different name lookup, for example. Or is this perhaps a 3rd
> distinction that isn't explicitly captured by either of these flags (&
> instead is a subset of ms-compatibility)? Ideally I don't want to
> depend on those differences either way (in any case where standard C++
> would find a different name from MSVC I'd like a warning/error so I
> can avoid it) & then I wouldn't compile with -fms-compatibility, I
> suppose.


Standard C++ code usually works with Clang and MSVC. -fms-compatibility is only there for those cases where you're stuck with a MSVC++ code base that you can't change.

This "third case" isn't something that either -fms-extensions or -fms-compatibility is designed for. Clang doesn't produce warnings such as "MSVC would find a different name here", and I don't think we should go there: it's not worth the extra complexity or computational overhead to produce such warnings, because there's no way we could approximate MSVC's behavior in Clang to a useful degree. If you have a code base that's meant to compile with MSVC and Clang, compile and test with MSVC and Clang :)

	- Doug