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.
Details
Details
- Reviewers
ldionne EricWF - Group Reviewers
Restricted Project - Commits
- rG643df8fa8ef5: [libc++] Make sure that all headers can be included with modules enabled
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
Will ship once CI is complete, I tested and this fixes the LLDB issues on Green Dragon.
| 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). |
| 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. |
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.