This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Remove _LIBCXX_MODULES_BUILD and ext/ headers from header tests
ClosedPublic

Authored by philnik on Mar 3 2022, 5:33 AM.

Diff Detail

Event Timeline

philnik created this revision.Mar 3 2022, 5:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2022, 5:33 AM
Herald added a subscriber: arichardson. · View Herald Transcript
philnik requested review of this revision.Mar 3 2022, 5:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2022, 5:33 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
ldionne accepted this revision.Mar 3 2022, 6:17 AM
This revision is now accepted and ready to land.Mar 3 2022, 6:17 AM
Quuxplusone accepted this revision.Mar 3 2022, 6:51 AM

It occurred to me this morning that there's yet another option for dealing with <ext/foo>. We could add them to the modulemap as textual headers, and then (to avoid the -Wprivate-header diagnostic on <__algorithm/is_permutation.h>) change them back to including all of <algorithm> instead of just <__algorithm/is_permutation.h>. <algorithm> is a public header, so it would be fine to include from a textual header. Then we wouldn't even need to skip their tests in the modules build.

But I don't object to this direction now and maybe someone'll investigate that direction later. I think the stakes here are low.

It occurred to me this morning that there's yet another option for dealing with <ext/foo>. We could add them to the modulemap as textual headers, and then (to avoid the -Wprivate-header diagnostic on <__algorithm/is_permutation.h>) change them back to including all of <algorithm> instead of just <__algorithm/is_permutation.h>. <algorithm> is a public header, so it would be fine to include from a textual header. Then we wouldn't even need to skip their tests in the modules build.

But I don't object to this direction now and maybe someone'll investigate that direction later. I think the stakes here are low.

I'd want to avoid that, because after removing <experimental/algorithm> we could mechanically check for #include <algorithm> to make sure no one's going to include it directly again.

I'd want to avoid that, because after removing <experimental/algorithm> we could mechanically check for #include <algorithm> to make sure no one's going to include it directly again.

I support that mechanical-check idea (lint_headers.sh.py :)) but it'd be 100% trivial to just exclude ext/hash_set from that particular check. If we go in @ldionne's suggested direction, of decoupling ext/ from libc++ proper and moving it into a third-party directory where it is no longer considered part of libc++, we should make it stop including detail headers anyway.