[patch] libcxx win32 support

[Nico Rieck]

On 27.08.2013 16:55, G M wrote:
> As can be seen by the table above, the effect of the earlier change
> means that some files that might have previously only compiled #if
> _MSC_VER are now instead getting compiled in the more general _WIN32 mode,
> letting clang etc. in which is a situation they aren't prepared for.

Then why not just revert to the previous state by taking Mingw out of 
_LIBCPP_MSVCRT (because they aren't fully compatible to the real one),
and change a few guards here and there to include Mingw? I've attached a 
patch like that before.

It only changes a few spots and makes a lot of your changes unnecessary. 
To me that seems a lot easier instead of pulling on all the workarounds 
not intended for Mingw.

> I wonder if at that time those files were written _MSC_VER might have been
> meant "for Microsoft's compiler only" but I don't know, But in any case, I
> think this is what broke the mingw/gnu toolset that I use so it no longer
> compiled "out of the box".

I want to ask again: How do you (or did you) compile libc++ with Mingw 
"out of the box"? Because if I do so, I get undefined references when 
linking, so can't further check up on this.

> I don't know the intent of the changes above and without that I
> personally find the new macro's more confusing than just using #if _WIN32
> etc. here, but I don't feel confident enough to argue that case.

The intent is stated in r187593. If you have clang and a different C 
standard library (I wrote one from scratch for clang) then a lot of the 
workarounds are unnecessary/wrong/problematic. And the latter were 
pulled in unnecessarily because of wrong guards. And not every 
Windows-specific code are compiler or standard library workarounds 
(though libc++ does not include anything in this category yet).


Regarding your patch, just a small note, there is quite a bit of noise 
in there (e.g. unnecessary whitespace changes). It wuold be nicer to not 
include those.


-Nico