Building with libc++ on Windows instead of MSVC STL

[joyeecheung]

During the V8 13.6 upgrade we noticed a crash on Windows that's likely caused by a bug of the std::unordered_map implementation in MSVC STL #57753 (comment) - workaround in 4d7da6c. I am not entirely sure but it could come from the combination of ClangCL + MSVC STL, and MSVC STL might've been otherwise working with MSVC, though we've already dropped MSVC support so it's difficult to find out.

Since MSVC support has been dropped in V8, so does MSVC STL. Maybe we should consider switching to libc++ somehow (which is what the upstream supports on Windows), to prevent this kind of bug from happening again. I could see that it can be challenging for us (IIUC, Chromium/V8 solves this by just pulling the source code of libc++ and directly build against it) as well as for addons authors (this means that they likely need to do the switch as well due to incompatible ABI). But it does seem to be an idea worthy of more discussions.

The other way is to continue supporting ClangCL + MSVC STL, which can lead to more difficult-to-investigate bugs and the bugfix may not always be upstreamable if they get complicated enough. For now it may be manageable but it's difficult to tell how it'll pan out.

cc @nodejs/platform-windows @nodejs/build @StefanStojanovic @targos

[targos]

It seems that libc++ can be built using ClangCL: https://releases.llvm.org/19.1.0/projects/libcxx/docs/BuildingLibcxx.html#support-for-windows

[deepak1556]

It seems that libc++ can be built using ClangCL:

Not sure how clang-cl is pulled in today, but there is also the standalone script from chromium to download prebuilt clang binaries for a revision https://source.chromium.org/chromium/chromium/src/+/main:tools/clang/scripts/update.py;l=1 which could be parsed from https://chromium.googlesource.com/v8/v8.git/+/refs/heads/main/DEPS#311

(this means that they likely need to do the switch as well due to incompatible ABI)

Incase it is helpful, in Electron we disabled trivial abi clang extensions of shared_ptr (_LIBCPP_ABI_ENABLE_SHARED_PTR_TRIVIAL_ABI) and unique_ptr (_LIBCPP_ABI_ENABLE_UNIQUE_PTR_TRIVIAL_ABI) that led to crashes for Nan based native modules, full background in linked blog post of this patch https://github.com/electron/electron/blob/main/patches/chromium/build_make_libcxx_abi_unstable_false_for_electron.patch. Ideal solution is for these addons to use the same libc++ build as the runtime or use the ABI stable N-API.