This is an archive of the discontinued LLVM Phabricator instance.

[libc++][Modules] Remove unnecessary `requires` from the module map
ClosedPublic

Authored by iana on Aug 7 2023, 11:25 PM.

Details

Summary

Top level modules don't need requires because they're only built when their headers are included.

Diff Detail

Event Timeline

iana created this revision.Aug 7 2023, 11:25 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 7 2023, 11:25 PM
Herald added a subscriber: ributzka. · View Herald Transcript
iana requested review of this revision.Aug 7 2023, 11:25 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 7 2023, 11:25 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
iana added a comment.Aug 7 2023, 11:42 PM

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.

iana added a comment.EditedAug 8 2023, 12:34 PM

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,

    |                                                                          ^
iana added a comment.EditedAug 9 2023, 1:18 PM

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.

Looks like that was a transient failure, all that's left is the (I think known) AIX failures.

iana updated this revision to Diff 548797.Aug 9 2023, 3:50 PM

Rebase

Mordante accepted this revision as: Mordante.Aug 10 2023, 9:56 AM

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?

iana added a comment.Aug 10 2023, 1:35 PM

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.

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.

iana added a comment.Aug 11 2023, 12:35 PM

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.

ldionne requested changes to this revision.Aug 11 2023, 2:24 PM

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.

This revision now requires changes to proceed.Aug 11 2023, 2:24 PM
iana added a comment.Aug 11 2023, 2:28 PM

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.

ldionne accepted this revision.Aug 14 2023, 12:03 PM

LGTM. CI issue is AIX, so everything is green.

This revision is now accepted and ready to land.Aug 14 2023, 12:03 PM
This revision was landed with ongoing or failed builds.Aug 14 2023, 12:07 PM
This revision was automatically updated to reflect the committed changes.