Top level modules don't need requires because they're only built when their headers are included.
Details
- Reviewers
ldionne Mordante - Group Reviewers
Restricted Project - Commits
- rG72a006b33855: [libc++][Modules] Remove unnecessary `requires` from the module map
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
For background, requires is generally used like this.
module ABC { header "plain.h" module NeedsCPP { requires cplusplus header "needs_cpp.hpp" } }
Building ABC would normally precompile both headers, but with the requires in place, needs_cpp.hpp will be skipped if the module is built in pure C mode. If NeedsCPP is a top level module, the requires isn't necessary anymore and dirties up the module map. In the libc++ case, not all the requires are even accurate, some of the headers are include-able without the feature. e.g. stdatomic.h doesn't actually require C++23, it will #include_next in earlier versions and still be buildable. I found that out while testing D157364 but figured this deserved its own review.
Are you sure they are not needed? In the previous version of the module map I had to add them. I see the modular build failing too. I really want to see it green.
Trying to figure out why the modular build is failing, doesn't look related but I need to check it out.
home/libcxx-builder/.buildkite-agent/builds/google-libcxx-builder-8997ed9990e4-1/llvm-project/libcxx-ci/build/generic-modules/include/c++/v1/__algorithm/pstl_backends/cpu_backends/for_each.h:52:10: error: no member named 'for_each' in namespace 'std'; did you mean 'for_each'? 52 | std::for_each(__first, __last, __func); | ~~~~~^ home/libcxx-builder/.buildkite-agent/builds/google-libcxx-builder-8997ed9990e4-1/llvm-project/libcxx-ci/build/generic-modules/include/c++/v1/__algorithm/for_each.h:22:74: note: 'for_each' declared here 22 | inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX20 _Function for_each(_InputIterator __first, | ^
Looks like that was a transient failure, all that's left is the (I think known) AIX failures.
LGTM, but I like @ldionne to have a look at this too.
I assume we don't need to backport this patch to LLVM-17. Is that correct?
I'm not really sure. If we want D157364 for v17 because it adds things back to the std module that we removed, then we'll need this too.
We backported the hard-coded __std_clang_module header to LLVM 17.
We'll never add new headers to LLVM 17 so we don't need to backport the __std_clang_module header generator script.
Does that answer your question? If not maybe reach out on Discord.
We did, but the hard coded __std_clang_module header didn't include as much things as the previous std module did since it put so many headers behind unnecessary macro guards. Maybe that's not a big deal.
This makes sense to me, we had talked about doing this when we reviewed @iana 's original modulemap patch. The CI failure is only AIX, which is known to fail right now, so this LGTM.
However, we should be updating the LIBCXX_CONFIGURED_WITHOUT_SUPPORT_FOR_THIS_HEADER stuff in CMakeLists.txt as well.
I left the LIBCXX_CONFIGURED_WITHOUT_SUPPORT_FOR_THIS_HEADER stuff in CMakeLists.txt because the experimental headers are all still in a single module, so they still use LIBCXX_ENABLE_LOCALIZATION. I could get rid of the other ones, but I thought it was best to leave them all in case other experimental headers use other ones. Also if we go back to grouping private headers together, we'll need some more requires.