[libc++] Make sure that all headers can be included with modules enabled

[ldionne]

Summary

This commit ensures that we can include all libc++ headers with modules
enabled. It adds a test to ensure that this doesn't regress, which is
necessary because our modules CI job does not build in all Standard modes.

[ldionne]

Related to D97044

[ldionne]

Add test

[ldionne]

Will ship once CI is complete, I tested and this fixes the LLDB issues on Green Dragon.

[ldionne]

Expand patch to fix incorrect annotations for other headers.

[ldionne]

Fix C++03

[ldionne]

Try to fix Apple CI by adding missing include

[ldionne]

Unsupport test on Windows, where system headers appear to not be modules-friendly.

[ldionne]

More UNSUPPORTED to get CI to pass

[ldionne]

Hopefully fix CI.

[ldionne]

Fix CI with bootstrapping build -- hopefully this doesn't break another job.

[EricWF]

libcxx/include/barrier

54 ↗

(On Diff #431716)

As a side note, I really don't love that headers are conditionally included. It just makes things weirder for our users, and even for us (it's an easy way to write portability bugs).

[ldionne]

libcxx/include/barrier

54 ↗

(On Diff #431716)

I agree -- I think we should only conditionally include headers when including the headers *doesn't* work (i.e. including iostream on a platform that doesn't have localization). Adding a TODO to my list.

[phosek]

FYI our builders have started running out of disk space, and while investigating the issue we pinpointed it to this change. The problem is that Clang started writing files to [CACHE]/clang/ModuleCache (on Linux that's either ${HOME}/.cache/clang/ModuleCache or ${XDG_CACHE_HOME}/clang/ModuleCache when XDG_CACHE_HOME is set), which on our builders is located on a partition with limited disk space, and a single run of libc++ test suite now generates 3.1G of data. I don't think we need to do anything for this change since Clang is behaving as intended, instead we'll need to make sure that ${XDG_CACHE_HOME} is on a volume with enough space, but I'm still reporting this since it was unexpected and others might run into this issue as well.

[tra]

Would it be possible to split modules_include.sh.cpp and possibly other tests into multiple files, so lit could run them in parallel?

Running all of these test cases sequentially often results in this test being the lonely remaining test that continues to run long after all other tests in ninja check are done. Splitting it would noticeably reduce ninja check wall time for many users.

[ldionne]

In D125331#3883141, @tra wrote:

Would it be possible to split modules_include.sh.cpp and possibly other tests into multiple files, so lit could run them in parallel?

Running all of these test cases sequentially often results in this test being the lonely remaining test that continues to run long after all other tests in ninja check are done. Splitting it would noticeably reduce ninja check wall time for many users.

This is currently impossible because we generate the test and want to keep it in a single file. However, it would be possible to implement a test format where Lit will actually create one Lit test per run line and then those could run in parallel. So -- not impossible, but requires some work in Lit.