Remove the use of microsoft STL extension in file.cpp

[FatihBAKIR]

Standard std::[io]fstream does not have a constructor from std::wstring, but from std::string or const wchar_t*. Microsoft STL has an extension that supports a std::wstring constructor, which the current code depends on. However, that extension does not exist in libc++ and therefore fails when trying to use libc++ with clang-cl on Windows.

This patch uses the standard-compliant constructor and builds with libc++.

https://en.cppreference.com/w/cpp/io/basic_ifstream/basic_ifstream.html
https://en.cppreference.com/w/cpp/io/basic_ifstream/basic_ofstream.html

[tlively]

It looks like the best place for a fix would be in the definition of the USE_WSTRING_PATHS macro in support/path.h.

Does that sound right, @dschuff?

[dschuff]

Yeah, USE_WSTRING_PATH is certainly the thing that controls whether we try to use std::wstring for paths. In addition to the constructors, there are also calls to ifstream::open() (e.g. in support/file.cpp) that basically have the same purpose (the purpose was to make sure that paths with non-ASCII are handled correctly, e.g. see test/lit/unicode-filenames.wast ). Are those calls also problematic for libc++?
And moreover, if we just disable USE_WSTRING_PATH on libc++ with windows, does that test still work? Mostly I'm just wondering whether the need to use std::wstring is a function of the c++ stdlib, or of the underlying OS.

More generally I am interested in having support for using libc++ with windows; we ship our emsdk binaries with libc++ on the other platforms, so it might be nice to do that for Windows too. How good is the support for that these days? How are you configuring your build?