-fms-extensions/LangOptions::Microsoft

I see that LangOptions::Microsoft no longer defaults to true in a Visual Studio build, but that it is passed in from the driver.

What is the reason for that?

I’m concerned about the implications of the differences in behavior between default compilation of a file with clang vs. clang-cc.

For example, compiling a file that includes stdio.h with clang-cc on Windows will now by default break unless -fms-extensions is used. It will work if compiled with clang.

Thus if I have a test that includes stdio.h and uses clang-cc, I have no way to do it generically because I would ahve to use -fms-extensions to make it work on Windows.

I see that LangOptions::Microsoft no longer defaults to true in a Visual Studio build, but that it is passed in from the driver.

What is the reason for that?

clang and clang-cc are being merged into a single executable.

I'm concerned about the implications of the differences in behavior between default compilation of a file with clang vs. clang-cc.

For example, compiling a file that includes stdio.h with clang-cc on Windows will now by default break unless -fms-extensions is used. It will work if compiled with clang.

clang-cc is an implementation detail that users should never call. What matters is the behavior that we see with "clang". If it's doing the right thing, we're fine.

Thus if I have a test that includes stdio.h and uses clang-cc, I have no way to do it generically because I would ahve to use -fms-extensions to make it work on Windows.

Well, the test could use "clang".

  - Doug

I see that LangOptions::Microsoft no longer defaults to true in a Visual
Studio build, but that it is passed in from the driver.

What is the reason for that?

Basically, my reasoning is as follows. I don't like having conditional
"logic" in multiple places; since the Driver will always have to have
some amount of "logic", I would rather put it all there.

The advantage of this approach is that "clang-cc" itself behaves very
predictively, which is nice for testing and reasoning about the
compiling -- you can look at the clang-cc line and have a good idea
what the compiler will do, without having to think about whether a
target does something funky.

At the internal API level, this amounts to not giving targets the
ability to override LangOptions. Because that is such an open ended
and far reaching extension point, I chose to kill it off by moving
more of the "logic" to the driver. Otherwise, to really reason about
what the compiler is doing you have to also take into account what the
target might do.

I would like to kill off TargetInfo::setForcedLangOptions for exactly
the same reasons (and because it is always nice to have objects which
are immutable-following-creation).

I'm concerned about the implications of the differences in behavior between
default compilation of a file with clang vs. clang-cc.

For example, compiling a file that includes stdio.h with clang-cc on
Windows will now by default break unless -fms-extensions is used. It will
work if compiled with clang.

Thus if I have a test that includes stdio.h and uses clang-cc, I have no way
to do it generically because I would ahve to use -fms-extensions to make it
work on Windows.

Generally, we want tests to be portable and predictable so the "right
way" to do this is to make the test not dependent on system headers.
If the test is specifically testing an -ms-extensions, it can always
pass -fms-extensions and test that on all platforms.

If the test is really dependent on system headers (for example, it is
aiming to test that we parse "stdio.h"), then the "right way" is to
use clang, since that is effectively an end user test.

- Daniel