Page MenuHomePhabricator

[libcxx] Fix using the vcruntime ABI with _HAS_EXCEPTIONS=0 defined
Needs ReviewPublic

Authored by mstorsjo on Wed, Jun 9, 1:29 AM.

Details

Reviewers
phosek
zero9178
ldionne
Group Reviewers
Restricted Project
Summary

_HAS_EXCEPTIONS=0 allows disabling the exception parts of the MS STL
and vcruntime, and e.g. compiler-rt/lib/fuzzer sets this define (to
work around issues with MS STL). If using libc++ instead of MS STL,
this define previously broke the libc++ headers.

If _HAS_EXCEPTIONS is set to 0, the vcruntime_exception.h header
doesn't define the ABI base class std::exception. If no exceptions
are going to be thrown, this probably is fine (although it also
breaks using subclasses of it as regular objects that aren't thrown),
but it requires ifdeffing out all subclasses of all exception/error
derived objects (which are sprinkled throughout the headers).

Instead use the libc++ provided std::exception class in this case,
making the class hierarchies complete. Define _LIBCPP_NO_EXCEPTIONS
to avoid throwing exceptions.

In this build configuration, one can still create instances of
exception subclasses, and those objects will be ABI incompatible
with the ones from when _HAS_EXCEPTIONS isn't defined to 0 - but
that's IMO a pathological/self-imposed problem in that case.

Diff Detail

Unit TestsFailed

TimeTest
640 mslibcxx CI GCC-next/C++20 > libc++.std/atomics/atomics_types_operations/atomics_types_operations_req::atomic_is_lock_free.pass.cpp
Script: -- : 'COMPILED WITH'; /usr/bin/g++-11 /home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/libcxx/test/std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_is_lock_free.pass.cpp -v -include /home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/libcxx/test/support/nasty_macros.h -nostdinc++ -I/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/include/c++/v1 -I/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/projects/libcxx/include/c++build -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/libcxx/test/support -std=c++2b -Werror -Wall -Wextra -Wshadow -Wundef -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type -Wno-aligned-allocation-unavailable -Wno-atomic-alignment -Wno-sized-deallocation -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -Wno-misleading-indentation -D_LIBCPP_DISABLE_AVAILABILITY -Wno-macro-redefined -D_LIBCPP_HAS_THREAD_API_PTHREAD -Wno-macro-redefined -D_LIBCPP_ABI_VERSION=1 -lc++experimental -L/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -Wl,-rpath,/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -L/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -Wl,-rpath,/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -nodefaultlibs -lc++ -lm -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc -latomic -o /home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc…
1,780 mslibcxx CI GCC-next/C++20 > libc++.std/iterators/iterator_primitives/range_iter_ops/range_iter_ops_advance::advance.pass.cpp
Script: -- : 'COMPILED WITH'; /usr/bin/g++-11 /home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/libcxx/test/std/iterators/iterator.primitives/range.iter.ops/range.iter.ops.advance/advance.pass.cpp -v -include /home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/libcxx/test/support/nasty_macros.h -nostdinc++ -I/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/include/c++/v1 -I/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/projects/libcxx/include/c++build -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/libcxx/test/support -std=c++2b -Werror -Wall -Wextra -Wshadow -Wundef -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type -Wno-aligned-allocation-unavailable -Wno-atomic-alignment -Wno-sized-deallocation -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -Wno-misleading-indentation -D_LIBCPP_DISABLE_AVAILABILITY -Wno-macro-redefined -D_LIBCPP_HAS_THREAD_API_PTHREAD -Wno-macro-redefined -D_LIBCPP_ABI_VERSION=1 -lc++experimental -L/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -Wl,-rpath,/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -L/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -Wl,-rpath,/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -nodefaultlibs -lc++ -lm -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc -latomic -o /home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc…
1,290 mslibcxx CI GCC-next/C++20 > libc++.std/iterators/iterator_primitives/range_iter_ops/range_iter_ops_next::iterator_count.pass.cpp
Script: -- : 'COMPILED WITH'; /usr/bin/g++-11 /home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/libcxx/test/std/iterators/iterator.primitives/range.iter.ops/range.iter.ops.next/iterator_count.pass.cpp -v -include /home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/libcxx/test/support/nasty_macros.h -nostdinc++ -I/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/include/c++/v1 -I/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/projects/libcxx/include/c++build -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/libcxx/test/support -std=c++2b -Werror -Wall -Wextra -Wshadow -Wundef -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type -Wno-aligned-allocation-unavailable -Wno-atomic-alignment -Wno-sized-deallocation -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -Wno-misleading-indentation -D_LIBCPP_DISABLE_AVAILABILITY -Wno-macro-redefined -D_LIBCPP_HAS_THREAD_API_PTHREAD -Wno-macro-redefined -D_LIBCPP_ABI_VERSION=1 -lc++experimental -L/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -Wl,-rpath,/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -L/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -Wl,-rpath,/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -nodefaultlibs -lc++ -lm -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc -latomic -o /home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc…
1,330 mslibcxx CI GCC-next/C++20 > libc++.std/iterators/iterator_primitives/range_iter_ops/range_iter_ops_next::iterator_count_sentinel.pass.cpp
Script: -- : 'COMPILED WITH'; /usr/bin/g++-11 /home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/libcxx/test/std/iterators/iterator.primitives/range.iter.ops/range.iter.ops.next/iterator_count_sentinel.pass.cpp -v -include /home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/libcxx/test/support/nasty_macros.h -nostdinc++ -I/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/include/c++/v1 -I/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/projects/libcxx/include/c++build -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/libcxx/test/support -std=c++2b -Werror -Wall -Wextra -Wshadow -Wundef -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type -Wno-aligned-allocation-unavailable -Wno-atomic-alignment -Wno-sized-deallocation -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -Wno-misleading-indentation -D_LIBCPP_DISABLE_AVAILABILITY -Wno-macro-redefined -D_LIBCPP_HAS_THREAD_API_PTHREAD -Wno-macro-redefined -D_LIBCPP_ABI_VERSION=1 -lc++experimental -L/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -Wl,-rpath,/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -L/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -Wl,-rpath,/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -nodefaultlibs -lc++ -lm -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc -latomic -o /home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc…
1,550 mslibcxx CI GCC-next/C++20 > libc++.std/iterators/iterator_primitives/range_iter_ops/range_iter_ops_next::iterator_sentinel.pass.cpp
Script: -- : 'COMPILED WITH'; /usr/bin/g++-11 /home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/libcxx/test/std/iterators/iterator.primitives/range.iter.ops/range.iter.ops.next/iterator_sentinel.pass.cpp -v -include /home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/libcxx/test/support/nasty_macros.h -nostdinc++ -I/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/include/c++/v1 -I/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/projects/libcxx/include/c++build -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/libcxx/test/support -std=c++2b -Werror -Wall -Wextra -Wshadow -Wundef -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type -Wno-aligned-allocation-unavailable -Wno-atomic-alignment -Wno-sized-deallocation -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -Wno-misleading-indentation -D_LIBCPP_DISABLE_AVAILABILITY -Wno-macro-redefined -D_LIBCPP_HAS_THREAD_API_PTHREAD -Wno-macro-redefined -D_LIBCPP_ABI_VERSION=1 -lc++experimental -L/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -Wl,-rpath,/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -L/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -Wl,-rpath,/home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc-next/./lib -nodefaultlibs -lc++ -lm -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc -latomic -o /home/libcxx-builder/.buildkite-agent/builds/869a2815bc20-1/llvm-project/libcxx-ci/build/generic-gcc…
View Full Test Results (42 Failed)

Event Timeline

mstorsjo requested review of this revision.Wed, Jun 9, 1:29 AM
mstorsjo created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptWed, Jun 9, 1:29 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript

Microsofts STL does seem to be doing the same as can be seen here: https://github.com/microsoft/STL/blob/62137922ab168f8e23ec1a95c946821e24bde230/stl/inc/exception#L63.

It's a bit sad that it's an ABI break, but it's basically unavoidable.

ldionne requested changes to this revision.Wed, Jun 9, 7:08 AM
ldionne added a subscriber: ldionne.

Is this configuration being tested by a bot? Who is it important for?

This looks good to me, except for the principle that we should not attempt to half-support configurations that we don't commit to testing - instead we should clearly state that those are not supported and simplify the library to not even try to support them. I'm 100% fine with this patch and supportive of this if I can get an answer to the questions above.

I'm hitting on that nail again because I happened to be looking at some CMake complexity yesterday that was introduced by attempting to port libc++ to Windows a few years back. I wasn't sure what the status was and whether it was still necessary (I suspect not), but it did prevent me from making simplifications to the code. I'm trying to prevent these situations where we feel blocked from making improvements to avoid breaking <some configuration>, without knowing whether it actually even matters.

This revision now requires changes to proceed.Wed, Jun 9, 7:08 AM

Is this configuration being tested by a bot? Who is it important for?

This looks good to me, except for the principle that we should not attempt to half-support configurations that we don't commit to testing - instead we should clearly state that those are not supported and simplify the library to not even try to support them. I'm 100% fine with this patch and supportive of this if I can get an answer to the questions above.

This is important for us, I'm trying to set up Fuchsia toolchain build for Windows and I ran into this issue in the runtimes build, this manifests when building compiler-rt (libFuzzer) using the just built Clang and libc++. I hope this also answers the question of testing, once this lands I'll (re-)enable the use of libc++ in our Windows toolchain build which is going cover this configuration.

We could also consider setting up Buildkite pipeline for Windows if we want coverage in libc++ presubmit testing although that's probably more work.

I'm hitting on that nail again because I happened to be looking at some CMake complexity yesterday that was introduced by attempting to port libc++ to Windows a few years back. I wasn't sure what the status was and whether it was still necessary (I suspect not), but it did prevent me from making simplifications to the code. I'm trying to prevent these situations where we feel blocked from making improvements to avoid breaking <some configuration>, without knowing whether it actually even matters.

Understood, I'd like to get to a state where libc++ could be reliably used on Windows to build Clang itself which I think is a good baseline (that is self-hosting).

phosek added inline comments.Wed, Jun 9, 10:22 AM
libcxx/include/__config
225

Microsoft STL seems to be using _HAS_EXCEPTIONS unconditionally presumably because vcruntime always defines it? I wonder if we should do the same to avoid accidentally going in the else branch if someone sets _LIBCPP_ABI_VCRUNTIME even when vcruntime isn't being used, I'd rather get an error in that case.

Is this configuration being tested by a bot? Who is it important for?

This looks good to me, except for the principle that we should not attempt to half-support configurations that we don't commit to testing - instead we should clearly state that those are not supported and simplify the library to not even try to support them. I'm 100% fine with this patch and supportive of this if I can get an answer to the questions above.

This is important for us, I'm trying to set up Fuchsia toolchain build for Windows and I ran into this issue in the runtimes build, this manifests when building compiler-rt (libFuzzer) using the just built Clang and libc++. I hope this also answers the question of testing, once this lands I'll (re-)enable the use of libc++ in our Windows toolchain build which is going cover this configuration.

We could also consider setting up Buildkite pipeline for Windows if we want coverage in libc++ presubmit testing although that's probably more work.

It's the bare minimum for a configuration to be considered as supported. We already have a Windows bot, but I'm actually not sure whether it's using MinGW or straight Windows. @mstorsjo will know. Maybe it's trivial to add another Windows configuration to test this?

rnk added a subscriber: rnk.Wed, Jun 9, 2:02 PM

I think we can say that _HAS_EXCEPTIONS=0 is an important configuration. We use it in LLVM, you can grep for it:

$ git grep _HAS_EXCEPTIONS ../llvm
../llvm/cmake/modules/AddLLVM.cmake:      list(APPEND LLVM_COMPILE_DEFINITIONS _HAS_EXCEPTIONS=0)
... others

Chromium also uses it, but apparently they already found this problem and worked around it:
https://source.chromium.org/chromium/chromium/src/+/main:build/config/compiler/BUILD.gn;l=1881?q=_HAS_EXCEPTIONS&ss=chromium

# libc++ uses the __has_feature macro to control whether to use exceptions,
# so defining this macro is unnecessary. Defining _HAS_EXCEPTIONS to 0 also
# breaks libc++ because it depends on MSVC headers that only provide certain
# declarations if _HAS_EXCEPTIONS is 1. Those MSVC headers do not use
# exceptions, despite being conditional on _HAS_EXCEPTIONS.

I can't speak to or improve the state of libc++ testing, but I think we'd start using this configuration if libc++ supported it. We have plans to work on Windows testing in LLVM, and that might include libc++, but the timeline is early 2022, so I'm not sure we should wait for that.

It's the bare minimum for a configuration to be considered as supported. We already have a Windows bot, but I'm actually not sure whether it's using MinGW or straight Windows. @mstorsjo will know. Maybe it's trivial to add another Windows configuration to test this?

It would be fairly straightforward/near trivial to add a CI configuration with this setup - but it's more about how much CI resources it's ok to spend on this; when I set up the first libcxx windows CI runner some months ago, I was given the go-ahead for one config (and I ended up adding two) but not for a large matrix of configurations - and if the number of configs are limited, there might be more useful other configurations to test instead of this one (like MinGW based configs).

(Regarding testing this; to test the actual real world setup, one would build libc++ normally but define _HAS_EXCEPTIONS=0 while using/testing it. I have no idea how much of our tests it would break if one would run the tests that way - I guess it could work mostly, if hooked up to TEST_HAS_NO_EXCEPTIONS.)

Overall, I'm not entirely sure if this in particular is a very useful configuration after all - the define was added as some sort of warning workaround in D57119 (but I'm not seeing the exact full picture there), and apparently hasn't bit other actual users of libc++ on Windows so far.

FWIW, the current CI configs use MSVC toolchains. (Both MSVC and MinGW produce binaries that run on "straight Windows", while one is a first party official SDK and the other is a third party SDK.)

Testing MinGW based toolchains in CI would be great, but that requires a decent amount of changes to the CI environment, that I'm not sure I'm comfortable requesting - quite yet at least. I do run a nightly build of libc++ in the configurations I care about, but that doesn't give instant feedback though.

This looks good to me, except for the principle that we should not attempt to half-support configurations that we don't commit to testing - instead we should clearly state that those are not supported and simplify the library to not even try to support them. I'm 100% fine with this patch and supportive of this if I can get an answer to the questions above.

Overall regarding this, I totally agree that codepaths that aren't easily testable are problematic to maintain - but I wouldn't want to go quite as far as suggesting to rip out any configuration not set up in CI either. (Asynchronous private buildbots and similar, as many downstreams use, do test a number of more configurations, but you don't know exactly what ends up tested there though...)

That said I'm not arguing hard for or against this particular change (it's an odd configuration, but the fix seems fairly straightforward) - WDYT @rnk regarding whether this configuration makes sense and whether we should spend CI resources on it?

libcxx/include/__config
225

I think the distinction is that __config here can be included before vcruntime.h (which sets the default) gets included, so we can't (easily) check what it sets it to, only check if the user has indicated a specific desire e.g. on the command line.

Also, checking an undefined preprocessor macro is normally not a hard error in most setups (it's a warning at most) so that doesn't guard much against shooting oneself in the foot anyway I think.

I think we can say that _HAS_EXCEPTIONS=0 is an important configuration.

Oh, that's good to know, thanks for clarifying it!

I can't speak to or improve the state of libc++ testing, but I think we'd start using this configuration if libc++ supported it. We have plans to work on Windows testing in LLVM, and that might include libc++, but the timeline is early 2022, so I'm not sure we should wait for that.

So I guess it's mostly up to @goncharov and the resources of the current windows runners and how much load they have from the current CI setups (from what I've seen lately, they run their tasks with little to no wait so they seem fine?), whether it's ok to add another config. If it is, I could try looking into adding a config for this.

I think we can say that _HAS_EXCEPTIONS=0 is an important configuration.

Oh, that's good to know, thanks for clarifying it!

I can't speak to or improve the state of libc++ testing, but I think we'd start using this configuration if libc++ supported it. We have plans to work on Windows testing in LLVM, and that might include libc++, but the timeline is early 2022, so I'm not sure we should wait for that.

So I guess it's mostly up to @goncharov and the resources of the current windows runners and how much load they have from the current CI setups (from what I've seen lately, they run their tasks with little to no wait so they seem fine?), whether it's ok to add another config. If it is, I could try looking into adding a config for this.

I'm not sure if it's of any help, but we will also cover this configuration in our CI since we want to start building and distributing Clang toolchain for Windows to our partners; this issue is actually our last blocker.

mstorsjo updated this revision to Diff 351387.Fri, Jun 11, 3:12 AM

Updated with CI testing hooked up. Unfortunately, things don't work quite cleanly:

  • There's a case of spurious warnings about misleading indentation when built with MSVC, when some braces are ifdeffed out, I filed that as PR50676. As other warnings are added after LIBCXX_TEST_COMPILER_FLAGS, we can't just pass -Wno-misleading-indentation there, because it ends up overridden by e.g. -Wall which is added later. This is hackily worked around by unconditionally adding -Wno-misleading-indentation in the list of global warning flags.
  • When built with vcruntime exceptions normally, but when used without vcruntime exceptions from some translation units, those translation units see a different declaration of e.g. std::runtime_error, and the DLL doesn't export e.g. runtime_error::what(). I dunno what's the cleanest fix for this (one probably would need to use different fully-inline declarations of those classes for those cases). This causes around 28 test failures at the moment.

I'm not sure if I'm interested in pouring more effort into this configuration right now, but this at least shows the current state of things and what has to be worked on for it to really work properly.

I.e., feel free to pick up and continue on this patch.