[PATCH] D34588: Check for _MSC_VER before define _LIBCPP_MSVCRT

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd added a comment.

In https://reviews.llvm.org/D34588#802533, @bruno wrote:

> > Thinking more about this, on Windows, is there a strong reason to default to a different libc by default on Windows?
>
> I'm mostly concerned with `-fms-extensions` + darwin, which doesn't apply to this scenario, maybe someone else knows a better answer here.


Could something like _WIN32 && _MSC_VER make this better?  That would allow us to differentiate between the various environments.  It's kinda icky, but, does make sense in a round about way.

> 
> 
>> @bruno would reusing `-ffreestanding` work for you here?
> 
> I think forcing the use of `-ffreestanding` with Apple platforms just for this is too restrictive.

Okay, was worth the shot anyways.

>> Or is there something else that we can identify about the target environment that can indicate that the MS CRT is unavailable?  I think that what is weird to me about this is that this is not about compatibility with Visual Studio but about the underlying libc.  It feels like it would be similar in spirit to say that libc++ defaults to libSystem as the underlying libc on Linux.
> 
> Right, makes total sense. I'm assuming that `-fms-extensions` for other targets (Linux) will also rely in not using `_LIBCPP_MSVCRT`, however #ifdefing for other platforms here doens't seem to add much because they usually do not set `_MSC_VER` anyways. Additional ideas?

Another bad idea: -U_MSC_VER.  The undefine should come after the preprocessor is initialized and should have the same effect as not having it defined.


https://reviews.llvm.org/D34588