[Draft][libc++][modules] Adds std module.

[Mordante]

Summary

Implements parts of

• P2465R3 Standard Library Modules std and std.compat

This patch is based on work by @ChuanqiXu.

This patch not intended to be landed is this form, it's intended to get
a feeling of modules in libc++ and improve upon it. This patch will be
used to discuss the further approach regarding modules in libc++.

[EricWF]

Cool deal. Thanks for working on this.

[ldionne]

libcxx/stdmodules/std-format.cppm

12 ↗

(On Diff #502156)

Well, if nobody like synopsis in headers, we can also remove them :-). Let's chat about that.

To be clear, you are not opposed to keeping the synopsis comment in test files that describes what we're testing, right? I think those are definitely useful and we should not stop those.

Pinging @var-const @huixie90 for thoughts. If folks agree, I don't want to impose it on people.

FWIW I do agree that storing those in the .cppm files results in something less readable than I thought it would.

[ldionne]

Pinging @iana @Bigcheese for awareness since they are working on Modules.

[philnik]

libcxx/stdmodules/std-format.cppm

12 ↗

(On Diff #502156)

Well, if nobody like synopsis in headers, we can also remove them :-). Let's chat about that.

To be clear, you are not opposed to keeping the synopsis comment in test files that describes what we're testing, right? I think those are definitely useful and we should not stop those.

I'm not sure they are always super useful, but they are definitely in enough cases that it would probably be a bad idea to remove them. They are also much easier to maintain and less error-prone.

[Mordante]

In D144994#4176269, @EricWF wrote:

Cool deal. Thanks for working on this.

Thanks!

In D144994#4173764, @ChuanqiXu wrote:

One of the issues in libc++ is that vendors can decide to disable filesystem header. Since parts of that library are in the dylib the std module can't provide what's in filesystem. Does your method also have that feature?

I disabled the filesystem header directly in the downstream... so I don't have a lot experience in this.

Thanks for the information!

I think we can discuss that and see whether it's a blocker for landing the patch or not. For now I still have issues with ranges (which I have not started to investigate). I have been experimenting with running the test-suite for the modular build. So I will have some more information on that later today, probably on Discord.

Yeah, it is always good to have more experience. And I didn't expect that we can convert all headers and pass all the tests in one shot. It is good enough for me to have a std module which contains a lot of headers and can pass a lot of tests.

I also didn't expect that, but we need to look at when we're comfortable with shipping something. Since libc++ is a system library on some platforms we need to consider that carefully. Obviously there are other non-official ways to ship things too.

It seems quite some tests fail due to using size_t instead of std::size_t and similar C-types. I'm working on patches to use the qualified name instead.

libcxx/stdmodules/std-format.cppm

12 ↗

(On Diff #502156)

Well, if nobody like synopsis in headers, we can also remove them :-). Let's chat about that.

To be clear, you are not opposed to keeping the synopsis comment in test files that describes what we're testing, right? I think those are definitely useful and we should not stop those.

Pinging @var-const @huixie90 for thoughts. If folks agree, I don't want to impose it on people.

FWIW I do agree that storing those in the .cppm files results in something less readable than I thought it would.

+1 for discussing the synopsis. But let's take it to Discord or a libc++ meeting.

[Mordante]

Various improvements.

• Incorporates D145596 CMake 3.26 fix.
• Removes new tests libc++ certainly doesn't want to duplicate all their tests for modules. (The final solution still is unknown.)
• Adds the std.compat module.
• Propagate some libc++ configuration flags to the modules
• Prepared a CI job, this is not used yet since the CI does not have CMake 3.26 and Ninja 1.11 yet.
• Update the test transformation script and did initial tried it locally.
• Small fixes to the module file.
• Added a few now module files.

[aaronmondal]

libcxx/docs/Modules.rst

84

Ah yes this fails due to template (mis)deduction with lambdas if I remember correctly. This works around it but it was decided some time ago that this shouldn't be changed in libc++ due to "work around compiler bug" not being a good reason for a change.

diff --git a/libcxx/include/__compare/synth_three_way.h b/libcxx/include/__compare/synth_three_way.h
index fa8cbda79ba2..a6df1b936c72 100644
--- a/libcxx/include/__compare/synth_three_way.h
+++ b/libcxx/include/__compare/synth_three_way.h
@@ -25,8 +25,8 @@ _LIBCPP_BEGIN_NAMESPACE_STD
 
 // [expos.only.func]
 
-_LIBCPP_HIDE_FROM_ABI inline constexpr auto __synth_three_way =
-  []<class _Tp, class _Up>(const _Tp& __t, const _Up& __u)
+template<class _Tp, class _Up>
+_LIBCPP_HIDE_FROM_ABI inline constexpr auto __synth_three_way(const _Tp& __t, const _Up& __u)
     requires requires {
       { __t < __u } -> __boolean_testable;
       { __u < __t } -> __boolean_testable;

libcxx/stdmodules/std-string_view.cppm

47 ↗

(On Diff #504447)

[h-vetinari]

libcxx/docs/Modules.rst

66

But we need to find the "proper" location to store them. Since this is something new this probably needs some involvement of our packagers. I don't expect the Linux Standard Base has an entry for C++20 modules.

As mentioned already, I think there are strong parallels with distributing headers. The bare minimum should be that they are automatically discoverable by the toolchain that produced them (should be somewhere under INSTALL_PREFIX obviously), but ideally it's in a standard location that's uniform across toolchains (again, relative to a PREFIX), like the headers and libs are too. I'm not sure if SG21 has had discussions about this, or if CMake has already thought about this.

Personally, I think the best might be a separate folder like $PREFIX/something_module_related/foo.cppm, but I wouldn't care much or at all if it's under $PREFIX/include/something_module_related/foo.cppm or $PREFIX/lib/<libname>/foo.cppm, etc., as long as it's discoverable and works.

CC @mgorny as another packager & @ben.boeckel for the CMake side.

[ChuanqiXu]

libcxx/docs/Modules.rst

66

I'm not sure if SG21 has had discussions about this, or if CMake has already thought about this.

As far as I know, sg15 has discussed this for a long time. (If I recall this correctly,) sg15 don't get the final consensus yet. But @ruoso has already made a lot of proposals. We can look at them later.

Personally, I think the best might be a separate folder like $PREFIX/something_module_related/foo.cppm, but I wouldn't care much or at all if it's under $PREFIX/include/something_module_related/foo.cppm or $PREFIX/lib/<libname>/foo.cppm, etc., as long as it's discoverable and works.

I think we need to discuss this in the discourse. Because the patch is going to be a large patch and the topic about distribution is another big topic. It looks not good to discuss two big things in the same page. The direction may be lost.

libcxx/stdmodules/std-compat.cppm

1 ↗

(On Diff #504447)

std.compat.cppm may be a better name. Since std-compat.cppm looks like a partition of the std module to me.

[ChuanqiXu]

libcxx/docs/Modules.rst

66

I created https://discourse.llvm.org/t/rfc-about-the-default-location-for-std-modules/69191 and let's discuss this there.

libcxx/stdmodules/CMakeLists.txt.in

71–75 ↗

(On Diff #504447)

This is what I did in the downstream. I imaged that we will merge this one with libc++.so in the upstream. But maybe I am wrong.
I feel we need to give it another name like libc++-modules. Otherwise it may be conflict with the std modules provided by libstdc++ later.

[ben.boeckel]

libcxx/CMakeLists.txt

108–111

This help string has embedded newlines and indentation (though I see other options do this…). I don't think the UI editors show the help well in this case (testing with ccmake seems to bear this out).

426

Somewhere under libdir would be good unless we know these files are actually arch-independent.

libcxx/docs/Modules.rst

26–27

Note that buildsystems should handle this. I don't know how viable the "just run the compiler by hand" is in the long-term…

43

You cannot ship the P1689 *output*, but it needs to be generated by anything *consuming* it so that the collation step can know to add the right flags (-fmodule-file=…) to the consuming TU compilation.

52–55

Nor should there be IMO. Note that a single build tree may need *multiple* compilations of the module, so I don't think a single "scanning output" is suitable to ship.

66

Personally, I think the best might be a separate folder like $PREFIX/something_module_related/foo.cppm, but I wouldn't care much or at all if it's under $PREFIX/include/something_module_related/foo.cppm or $PREFIX/lib/<libname>/foo.cppm, etc., as long as it's discoverable and works.

Note that libstdc++ is also going to ship std.cppm (possibly with a different extension), so the libname being part of the path sounds best to me. I'll jump in over on Discourse.

72

"not used as a compile flag" perhaps?

117

IMO, no.

163–165

Is this intended to be a stable interface? IMO, support for std modules needs to come from CMake because this is going to be different for every compiler otherwise.

libcxx/stdmodules/CMakeLists.txt

43 ↗

(On Diff #501265)

Instead we need to focus on distributing .cppm files and offer the tools for the user to create the .pcm files for their project. This is something I will investigate further.

I think this is more the job of CMake since asking users to do

cmake
if (<is_clang>)
  setup_clang_libcpp()
elseif (<is_gcc>)
  setup_gcc_libstdcpp()
elseif (<is_msvc>)
  setup_msvc_stl()
endif ()

is awfully narrow IMO. Highly related question: what do you expect to happen in the case of clang with libstdc++ (as many distros end up doing)?

libcxx/stdmodules/CMakeLists.txt.in

7 ↗

(On Diff #504447)

3.26 should have this.

9 ↗

(On Diff #504447)

This UUID changes…regularly. There will probably need to be a table to do this "properly".

10 ↗

(On Diff #504447)

This is specific to CMake's test suite and shouldn't be relevant.

[ldionne]

libcxx/stdmodules/std-cstddef.cppm

13 ↗

(On Diff #504447)

Would this make sense to avoid users having to define all the config site macros? #include <__config_site>

[tahonermann]

libcxx/stdmodules/std-cstddef.cppm

13 ↗

(On Diff #504447)

Named modules don't export/leak macros when imported, so the addition of the #include would have no effect on importers of the module.

[Mordante]

libcxx/CMakeLists.txt

108–111

Yes I indeed copied this from the other scripts. Are there better ways in CMake to have multi-line options?

426

This is used for the .cppm source files so they are arch independent.

libcxx/docs/Modules.rst

66

I'm not sure if SG21 has had discussions about this, or if CMake has already thought about this.

As far as I know, sg15 has discussed this for a long time. (If I recall this correctly,) sg15 don't get the final consensus yet. But @ruoso has already made a lot of proposals. We can look at them later.

Do you have a paper number?

Personally, I think the best might be a separate folder like $PREFIX/something_module_related/foo.cppm, but I wouldn't care much or at all if it's under $PREFIX/include/something_module_related/foo.cppm or $PREFIX/lib/<libname>/foo.cppm, etc., as long as it's discoverable and works.

I think we need to discuss this in the discourse. Because the patch is going to be a large patch and the topic about distribution is another big topic. It looks not good to discuss two big things in the same page. The direction may be lost.

I agree, this list is mainly added for documentation so we know what the status is. It was not intended to be used for discussions during the review.

163–165

I agree this is not the way users should use it. But without build system support this is how it works now.
So I feel this is "good enough" for early adapters. However when we (libc++) know how we want to distribute it
we should reach out to build system vendors and ask them to add proper support in their tools.

I'm not even sure what direction we want to take. For the experimental library we have a Clang flag which
automatically link that library. Do we want to do something similar here or leave it entirely in the hands
of the build system?

libcxx/stdmodules/CMakeLists.txt

43 ↗

(On Diff #501265)

I agree this is narrow and not great. However this patch's main focus it to be able to get modules working in libc++ in the first place.
We definitely need to think about the distribution in a user-friendly way.

I'm not sure whether libc++ needs to consider the configuration of Clang + libstdc++. Do you have something specific in mind?
I expect there need to be things done on the Clang side.

libcxx/stdmodules/CMakeLists.txt.in

7 ↗

(On Diff #504447)

Thanks for the information! I see it landed recently in CMake.

9 ↗

(On Diff #504447)

Is there a public available table for these UUIDs? The last time I needed the one for CMake 3.25 I looked in the CMake git history.

libcxx/stdmodules/std-cstddef.cppm

13 ↗

(On Diff #504447)

The goal is not to leak the macros, but to use the macros to conditionally export symbols. For example in the next file in the patch I use #ifndef _LIBCPP_HAS_NO_WIDE_CHARACTERS to avoid exporting wide character functions when the user configured libc++ without wide character support.

When building the BMI we need to know the configuration of libc++. In a similar fashion we need to disable symbols based on the language version used. For now there are some examples for C++20 vs C++23. Not that we have decided that we want to back port this feature, but we will need this for C++23 vs C++26.

[ben.boeckel]

libcxx/docs/Modules.rst

163–165

I think that some build-system agnostic data (similar to the MSVC STL JSON file linked to on Discourse is best). I don't think every compiler trying to chase umpteen build tool integrations (as compilers tend to be *far* harder to upgrade in the Real World than build system tools IME).

ISO C++'s SG15 is the best place for communication IMO.

libcxx/stdmodules/CMakeLists.txt.in

9 ↗

(On Diff #504447)

The UUID is only documented in the CMake repository's Help/dev/experimental.rst file.

[Mordante]

Adds more modules.

This mostely completes the modules. These modules have been compile
tested but nothing more. They also do not take disabled libc++ parts
into account.

Updates the documentation.

[ldionne]

libcxx/test/libcxx/language.support/support.types/cstddef.compile.pass.cpp

1

IMO it would make sense to split this test like this:

/////////////////////////////////////////////////////////////////////////////
// cstddef.compile.pass.cpp
#include <cstddef>
#include "test_macros.h"

using PtrdiffT = ::ptrdiff_t;
using SizeT = ::size_t;
#if TEST_STD_VER >= 11
using MaxAlignT = ::max_align_t;
#endif

// Supported in C++03 mode too for backwards compatibility with previous versions of libc++
using NullptrT = ::nullptr_t;

// Also ensure that we provide std::nullptr_t in C++03 mode, which is an extension too.
using StdNullptrT = std::nullptr_t;
/////////////////////////////////////////////////////////////////////////////

/////////////////////////////////////////////////////////////////////////////
// cstddef.std.module.verify.cpp
// REQUIRES: modules-build (????)
import std;

#include "test_macros.h"

using PtrdiffT = ::ptrdiff_t; // expected-error {{no ptrdiff_t in global namespace}}
using SizeT = ::size_t; // expected-error {{no size_t in global namespace}}

[ etc... ]
/////////////////////////////////////////////////////////////////////////////

/////////////////////////////////////////////////////////////////////////////
// cstddef.stdcompat.module.compile.pass.cpp
import std.compat;

#include "test_macros.h"

using PtrdiffT = ::ptrdiff_t;
using SizeT = ::size_t;

[ etc... ]
/////////////////////////////////////////////////////////////////////////////

This one would be split up manually since it is extremely relevant to test this with C++23 modules.

However, many other tests are not as useful to test with/without modules. As we discussed, we could perhaps run use_modules_in_test.py on the fly to create a modularized version of the test that we wouldn't check into source control.

[Mordante]

Minor improvements

Ran the tests using the compat module with the tests converted using
the test conversion script. After some minor fixes 222 tests fail and
need triaging. (This are more tests than before, but now the tests use
less headers since most headers are now available as module.)

• Improved the conversion script
  • Imports are moved the the end.
  • Modularized header #ifndefs are grouped.
  • Disables tests using deprecated features. These use a compiler switch that doesn't work with modules.
• Updated the documentation.
• Minor module fixes.

[Mordante]

Updated due to Discourse discussion and minor improvements.

• Use the installation location as proposed on Discourse. This adds a proof-of-concept installer.
• Add CI jobs to test modules with parts disabled.
• Fix modules to work with no localization or no wide characters. Other configurations are errors.
• Adds a few empty modules, their headers export nothing.
• Improve the algorithm module.

[tschuett]

libcxx/docs/Modules.rst

104

C++20

136

I believe this is confusing. I thought that you want to store everything underneath c++? Additionally you use the same path for includes and modules.

[aaronmondal]

libcxx/docs/Modules.rst

136

Typo? Should probably be "Includes are stored in <prefix>/include/c++/v1, modules in <prefix>/modules/c++/v1".

I think this makes sense. Modules can't be #included anyways so there is a need for them to live in an include/ directory. And for those using a different ABIs this leaves the possibility to have

.../include/c++/v1
.../include/c++/v2
.../modules/c++/v1
.../modules/c++/v2

or similar to clearly differentiate the headers/module interfaces.

[tschuett]

There was objection against using /usr/modules on discourse. I assumed that libc++ owns /usr/include/c++ and hides everything under there.

[ruoso]

libcxx/docs/Modules.rst

136

$PREFIX/modules is a new path that doesn't exist in the Filesystem Hierarchy Standard.

The source files for the module units is indeed a arch-independent resource, therefore the correct directory would be something under $PREFIX/share

If we ever intend to ship BMI files, they would belong in $libdir.

Here's how it would look like if we go in that direction:

$PREFIX/
   $libdir/
       libc++.so
       libc++.so.module-info
       c++/
           modules/
                libc++/
                      std.gcm.deadbeef1234
   share/
       c++/
           modules/
                 libc++/
                       std.cppm

the libc++.so.module-info file would have the metadata necessary for someone to understand how to produce their own BMI as well as potentially reuse the shipped BMI if it just so happen that they can.

[ruoso]

libcxx/docs/Modules.rst

136

There is one important bit that worries about splitting off the source files, tho.

The module metadata shipped alongside the library itself needs to reference those source files, and I am concerned that requiring the use of ../../../../share/ in order to address the source location can lead to fragility in the deployment.

So, even though it's technically arch-independent, I would also consider the following option:

$PREFIX/
   $libdir/
       libc++.so
       libc++.so.module-info
       c++/
           modules/
                libc++/
                      std.gcm.deadbeef1234
                      std.cppm

Because at that point, the metadata could reference a relative path from the library location without the awkwardness that using ../ can cause when directories are symlinks.

[ChuanqiXu]

Add CI jobs to test modules with parts disabled.

So, is the CI going to be ready?

libcxx/modules/std.compat/cassert.cppm

11–17

What's the meaning for the file? It looks useless.

[Mordante]

In D144994#4208434, @ChuanqiXu wrote:

Add CI jobs to test modules with parts disabled.

So, is the CI going to be ready?

Not at the moment. There are some CI issues not related to modules which should be resolved first. However I am testing with the CI configuration locally. I'm still fixing bugs in the modules and investigating issue which might be Clang bugs.

I'm also still busy to remove symbols from the global namespace so I can start to test the std module, for now I only test with the std.compat module.

libcxx/docs/Modules.rst

26–27

I fully agree. For now we will also ship a CMake file to aid users. But once build systems catch up that CMake file will be removed. At the moment we're not even sure where our .cppm files will be installed, so asking buildsystems to support libc++ is a bit premature. Having this information makes it possible for early adaptors to get started.

43

I've removed the section.

136

This is indeed a typo.

163–165

I will consider attending in SG15 to discuss this.

libcxx/modules/std.compat/cassert.cppm

11–17

It kind of is, but it's easier to have tooling that makes sure every header is a module. This way there need to be no exceptions. Some of the "empty" modules may get symbols in the future.

[ChuanqiXu]

Not at the moment. There are some CI issues not related to modules which should be resolved first. However I am testing with the CI configuration locally. I'm still fixing bugs in the modules and investigating issue which might be Clang bugs.

Oh, got it. Never be hurry : )

libcxx/modules/std.compat/cassert.cppm

11–17

Got your point. I remember the paper said clearly that assert and errno is not exported in the std modules. But it doesn't matter really.

[Mordante]

libcxx/modules/std.compat/cassert.cppm

11–17

I can't find that in the paper nor in the WP. There is http://eel.is/c++draft/std.modules#note-2 which states

[Note 2: Like all named modules, the C++ library modules do not make macros visible ([module.import]), such as assert ([cassert.syn]), errno ([cerrno.syn]), offsetof ([cstddef.syn]), and va_arg ([cstdarg.syn]).
— end note]

[ChuanqiXu]

libcxx/modules/std.compat/cassert.cppm

11–17

Oh, my bad for confusing : )

[Mordante]

Several minor improvements.

• updates comments
• removes C++20 modules
• adds new module specific tests using AST matchers
• fixes several module bugs, mainly found by the new tests

[Mordante]

Rebased on main and resolved merge conflicts.

[ChuanqiXu]

libcxx/test/libcxx/module_std.sh.cpp

227 ↗

(On Diff #512886)

I can't search libcpp-header-exportable-declarations. Is there a patch that haven't been uploaded?

[Mordante]

libcxx/test/libcxx/module_std.sh.cpp

227 ↗

(On Diff #512886)

It's in the file libcxx/test/tools/clang_tidy_checks/header_exportable_declarations.cpp which is part of this patch.
(It still has some issues, but I wanted to post some progress again.)

[philnik]

libcxx/test/tools/clang_tidy_checks/header_exportable_declarations.cpp

92 ↗

(On Diff #512886)

102–106 ↗

(On Diff #512886)

I think that's the idiomatic way to do this.

141–156 ↗

(On Diff #512886)

We have something very similar in ugilfy_attributes.cpp. Maybe we should add a header for a few utilities?

165 ↗

(On Diff #512886)

Is this equivalent to decl->getName()?

172 ↗

(On Diff #512886)

What is this doing?

libcxx/test/tools/clang_tidy_checks/header_exportable_declarations.hpp

21 ↗

(On Diff #512886)

Would an unordered_set be better?

[Mordante]

Thanks for the review!

libcxx/test/tools/clang_tidy_checks/header_exportable_declarations.cpp

92 ↗

(On Diff #512886)

Thanks I already spotted this locally.

102–106 ↗

(On Diff #512886)

Interesting I wasn't aware llvm::isa multiple arguments. For now I keep it as is, but leave this comment open,

Once the code is working as intended I will see whether this change improves the code.

141–156 ↗

(On Diff #512886)

That might be useful. BTW if (str[0] == '_' && str[1] >= 'A' && str[1] <= 'Z' does not work properly in EBCDIC.

165 ↗

(On Diff #512886)

The documentation in not fully clear, but since getName() returns a StringRef I'm sure it's not the same.
getName() would return fill where get_qualified_name() returns std::fill or std::ranges::fill.

172 ↗

(On Diff #512886)

Dumping a line like using std::vector. This checker is not a real checker, but extracts information.
The output of a toplevel header is compared with the output of a module.
This is done in libcxx/test/libcxx/module_std.sh.cpp (which very much under review and I'm still looking at the failures.)

libcxx/test/tools/clang_tidy_checks/header_exportable_declarations.hpp

21 ↗

(On Diff #512886)

I haven't tested. Most headers don't have a lot of declarations. The module type_traits which is one of the larger modules has less than 300 entries. (In total there are less than 4000 entries in the Standard library.)

[ChuanqiXu]

libcxx/modules/CMakeLists.txt.in

49

I guess we need a better library name before landing this.

[Mordante]

libcxx/modules/CMakeLists.txt.in

49

What would you propose?
I'm not even sure we really need to, but this is something to determine during a review.

[ChuanqiXu]

libcxx/docs/Modules.rst

84–99

Will these problems be blockers actually? Specially for the "header-module" order problem, we can't fix it fundamentally. And I feel 'std module' is still workable in some degree with these defects. If these problems are not blockers actually, could we move the "limitations" section?

libcxx/modules/CMakeLists.txt.in

49

What would you propose?

I use libstdmodule.a in the downstream. But it looks not good enough for the upstream.

I'm not even sure we really need to, but this is something to determine during a review.

Ideally this should be handled by cmake (or other build systems). But we need it now to make progress. How about something like 'libc++_std_module.a'?

[Mordante]

libcxx/docs/Modules.rst

84–99

I think this one isn't I think we should downgrade this one to limitation.

[aaronmondal]

Any idea how to get this diff from phabricator in a way that doesn't include the changes to the modules directory? That part somehow messes up Bazel's patching.

libcxx/modules/CMakeLists.txt.in

49

Don't have a strong opinion on this, though this will probably be painful to change once users adopt any name.

libc++-std.a, lib++_std.a? Though I personally think just std would be fine.

The std.compat archive should follow a similar scheme though.

[ChuanqiXu]

libcxx/docs/Modules.rst

84–99

What do you mean for this one?

[aaronmondal]

Started testing the Bazel build. Seems to almost build. The __new is a slight inconvenience, but easily worked around and I don't think we can do too much about it.

Only std:memory doesn't build yet on my end.

I'm also noticing that this will place quite the significant restriction on the compiler building the modules. It's a bit unintuitive to build libc++ with C++20 and the interfaces/partitions with C++23. It's more intuitive to build the entire libc++ (sources) with C++23 (which works), but I'd assume that the only compiler capable of doing that at the moment upstream Clang itself 🤣

libcxx/modules/CMakeLists.txt.in

49

I think I'm misunderstanding this target. What are the contents of this archive?

libcxx/modules/std/memory.cppm

184–185

This seems to break the build for me with "no member atomic in namespace std". Where is this symbol coming from?

The <atomic> include is disabled for C++23. Maybe I'm just missing some config flag?

[Mordante]

In D144994#4282770, @aaronmondal wrote:

Started testing the Bazel build. Seems to almost build. The __new is a slight inconvenience, but easily worked around and I don't think we can do too much about it.

Yeah we can't use new since it's a keyword.

I'm also noticing that this will place quite the significant restriction on the compiler building the modules. It's a bit unintuitive to build libc++ with C++20 and the interfaces/partitions with C++23. It's more intuitive to build the entire libc++ (sources) with C++23 (which works), but I'd assume that the only compiler capable of doing that at the moment upstream Clang itself 🤣

We can't nicely build libc++ with C++23, this requires a newer CMake. (I have a patch for it, but I'm waiting for the last buildbots to be updated.)
It could be done with older CMake versions, but that is quite inconvenient.

Since we have a CI it will be trivial to test whether our supported compilers have sufficient C++23 support to build libc++

libcxx/docs/Modules.rst

84–99

This bullet point.

libcxx/modules/CMakeLists.txt.in

49

This is the library for the module std. So next to the .pcm files there is a library component.

libcxx/modules/std/memory.cppm

184–185

I'm not sure, but there are several errors in the modules. I copy-paste the synopis and manually cleaned them, so errors were always bound to occur.

There is a test module_std.sh.cpp which validates the declarations in the include files and in the modules.
This found quite some issues, some parts are not implemented in libc++, the synopsis only sometimes doesn't have all declarations (bitmask types for example), etc/
I'm not sure whether the test flags this one, but I have some patches to fix some of the issue found in libc++ itself.

[aaronmondal]

Yeah we can't use new since it's a keyword.

Actually, what about renaming the new.cppm to __new.cppm? The issue with new.cppm is that you can't grep/ls all files in the libcxx/modules directory and extract the partition names from the filenames that way. Since the partition is named std:__new, naming the file same seems more natural.

The downside of this is that __new doesn't 1:1 correspond to the <new> header name. Since there is no include/__new in the same way that there is e.g. include/__algorithm there is little room for confusion though, and users can't directly import the partitions anyways.

[ldionne]

libcxx/test/std/time/time.syn/formatter_tests.h

21

This doesn't seem necessary at all, it's included above.

[aaronmondal]

Yayyy we have a working hello world https://github.com/eomii/rules_ll/pull/98 🥳

[aaronmondal]

I've just opened https://github.com/llvm/llvm-project/issues/62269 to track progress on the irreproducibility of BMIs. After thinking about this for a while, believe that this could be more of an issue than I initially thought. IMO we should add a warning that Module precompilation currently leaks absolute paths into BMIs.

[ChuanqiXu]

libcxx/docs/Modules.rst

84–99

Oh, this bullet has 3 issues. I thought you referred to one of them.

[ldionne]

As discussed, let's split the cppm files into a separate review so we can get the bulk of the mechanical changes in.

libcxx/modules/std/format.cppm

11

As discussed, I think this makes it too hard to distinguish what is a comment and what is an actual declaration. Thanks so much for doing the experiment -- I think it was a good idea on paper but it turns out to be a bit too hard to read.

libcxx/modules/std/memory.cppm

32

This has been fixed now. Also some stuff in <mutex> and <utility>, see D145589.

[Mordante]

Various cleanups
Documentation updates
Removed magic header from modules, this requires Clang 17

[Mordante]

Rebased.

[Mordante]

Removes some no longer needed work-arounds.
Adds a work-around for as_rvalue, which will be put in a separate review too.

[aaronmondal]

Regarding compilation of the BMIs themselves the only issue left seems to be that <type_traits> doesn't export some symbols and <functional> needs to be included in its cppm at the moment. Other than that everything builds and std is importable.

Some std:: symbols still breaks in a few unsurprising places, e.g. format/ranges.

[Mordante]

In D144994#4325321, @aaronmondal wrote:

Regarding compilation of the BMIs themselves the only issue left seems to be that <type_traits> doesn't export some symbols and <functional> needs to be included in its cppm at the moment. Other than that everything builds and std is importable.

Some std:: symbols still breaks in a few unsurprising places, e.g. format/ranges.

The first part for functional is D149351 which moves these declarations in the proper primary header.
On my list there are some issues with invocable too.

Once these are done I can start to finalize the cppm files.

[Mordante]

Polish the standard modules.

[Mordante]

Rebased on main.

[Mordante]

Final review of the std module

• fixes some minor issues
• enables the declarations that have been recently implemented by various contributors

[Mordante]

I split of the .cppm files for the std module in D151030 once that lands I'll rebase this patch on top of that.

[ldionne]

libcxx/utils/use_modules_in_test.py

2

Let's extract this to its own patch.

160

Could we instead use this annotation in the test itself, with a relevant comment?

// UNSUPPORTED: use_module_std && !(c++11 || c++14 || c++17)

Or actually, we can use just

// UNSUPPORTED: use_module_std

since we never run with use_module_std in C++11/14/17.

170–177

The fact that we need to disable these tests is quite interesting. I think it surfaces a pretty big problem with modules (as a language feature). Today, we use macros and compiler flags to customize the behavior of the library on a per translation-unit basis. That is an extremely important property of some aspects of the library (*). If we want everything to transition to modules (and we do), we need a way to satisfy those use cases. I don't mind whether that's done by defining macros, via some compiler flags or some other way, but those use cases are valid and we need to figure out how we're going to support them. Otherwise, we'll be left with large parts of our user base that can't switch over to C++ modules because they don't support some required use cases.

(*) For example, we use _LIBCPP_ENABLE_ASSERTIONS to control whether assertions are enabled or not on a per-TU basis. This is extremely important: when converting code bases to assertions, users might want to prevent assertions in some performance critical parts of the code, while still enabling assertions everywhere else. This approach allows for an incremental adoption of the feature and that's an important aspect of it being deployable in the real world.

I would like us to discuss avenues we could use to satisfy these use cases. For example, could we ship multiple "versions" of the library, each configured differently, and then the compiler would use a different version based on the compiler flags it is passed? I think pretty much all vendors are going to have similar questions, and that's going to severely limit how useful C++ modules can be in the real world. @jwakely @CaseyCarter I assume that's also something that you folks have thought about?

CC @ChuanqiXu

[ChuanqiXu]

libcxx/utils/use_modules_in_test.py

170–177

(I am not 100% sure that I understand your question)

A background (I guess you already know this. But I'd like to repeat it again to avoid misunderstandings): we're going to ship (*.cppm) files. And the compilation of the std modules would happen in the users' machine. Also the compilation of the std modules may occur multiple times due to different configuration of the build. For example, the Release build and the Debug build will compile std modules twice with different options. And ideally the process would be controlled by the build systems (cmake).

The consensus in SG15 now is that we need to ship source files (*.cppm files) and a metadata file to describe the requirement/information of the library/module. Note that SG15 doesn't have a consensus (or even a feeling as far as I know) how the metadata should be.

So a temporary conclusion here is that possibly there is not an off-the-shelf practice that we can take directly. We would have to explore the method during the practice.

Also, I strongly suggest to send this question to SG15 and there are multiple experts who studied the problem for a relative long time. Maybe it will be more helpful than the small group discussion here.

CC: @ruoso @ben.boeckel

[ldionne]

libcxx/utils/use_modules_in_test.py

170–177

we're going to ship (*.cppm) files. And the compilation of the std modules would happen in the users' machine.

Yes, we're on the same page. I'm not sure why I mentioned shipping various versions of the library, I was thinking about the need to pre-build multiple versions of the library for testing purposes (which is not related). Let me try to clarify my concern, and you can let me know whether I'm getting agitated for no good reason :-). Let's take for example _LIBCPP_ENABLE_ASSERTIONS. Today, that's a macro you define as -D_LIBCPP_ENABLE_ASSERTIONS=1 on the command-line or #define _LIBCPP_ENABLE_ASSERTIONS 1 as the first thing in your file, and the result is that libc++ functions like operator[] will be compiled with some assertions inside. This can be controlled on a per-TU basis today using the #include model we all know.

How do we do that in modules world if you're using import std instead? You can still pass -D_LIBCPP_ENABLE_ASSERTIONS=1 on the command-line, however that won't do anything because the compiler is using the BMI files that have already been compiled and _LIBCPP_ENABLE_ASSERTIONS was set to 0 when those were compiled. Right?

You can also still use #define _LIBCPP_ENABLE_ASSERTIONS=1 as the first thing in your file, but that also won't do anything because import std; doesn't have any way (or desire) to somehow resolve to a different BMI depending on the current macro environment. Right?

Basically, my question is: "What's the WG21-blessed alternative for this use case"? Are we expected to lift this mechanism from -D_LIBCPP_ENABLE_ASSERTIONS=1 to some other compiler flag like -flibcxx-enable-assertions (with a better name)? Then users would tell their build-system to build specific TUs using that flag, and that would result in different BMIs being compiled and used for those TUs? I think that would work, but it would create some challenges for sure.

If that's the expectation, then it means that we either need to build multiple configurations of the library BMIs during CMake invocation for the test suite to reuse, or lit needs to be able to somehow rebuild BMIs (or ask CMake to do it) based on the requirement of various tests in the test suite. For example, you'd tell lit that you're using -fsized-deallocation in your test, so it would go and rebuild the BMIs for libc++ with that set of compiler flags, and then set the appropriate substitution for that test to use the right BMIs for -fsized-deallocation. Possible, but fun to implement :-)

[davidstone]

libcxx/utils/use_modules_in_test.py

170–177

The point that you would define _LIBCPP_ENABLE_ASSERTIONS=1 is when you compile the module in which you want to enable assertions. In other words, you can control it on a per-TU basis for the code that has the assertions, but not for the code using the code that has assertions. In general, you get ODR violations if the user's code is using multiple versions of library code.

So the user would not define the macro in their source file, nor would they (in CMake terms) associate the macro with their own target, they would either define the macro globally in their build system or associate it (somehow) with the standard library build target.

[ChuanqiXu]

libcxx/utils/use_modules_in_test.py

170–177

@ldionne Oh, I got your point. You're mainly talking about testing instead of distributing. (IIUC).

How do we do that in modules world if you're using import std instead? You can still pass -D_LIBCPP_ENABLE_ASSERTIONS=1 on the command-line, however that won't do anything because the compiler is using the BMI files that have already been compiled and _LIBCPP_ENABLE_ASSERTIONS was set to 0 when those were compiled. Right?

You can also still use #define _LIBCPP_ENABLE_ASSERTIONS=1 as the first thing in your file, but that also won't do anything because import std; doesn't have any way (or desire) to somehow resolve to a different BMI depending on the current macro environment. Right?

Yes. This is by design. We don't want the build of modules to be affected by its users.

Basically, my question is: "What's the WG21-blessed alternative for this use case"?

The expected solution may be add a metadata file (which haven't been defined yet) to the library and the metadata file will contain informations about the interested flags of the library.

And if there are two (multiple) users use the same library and all the flags they used in the interesting flag set are the same, they can reuse the same BMI file. But if there is any different flag in the interesting flag set, they have to use different BMI file.

Let's come back to the example of testing of libcxx. Here every lit test with a configuration is a user of the std module. But the same lit test with different configuration are considered to be different users of the std module. And in your example, both -D_LIBCPP_ENABLE_ASSERTIONS and -fsized-deallocation are the interesting flags.

BTW, the intention of the design is that, (I guess you already know this too. Just repeat again to be informative. Sorry if this is wordy), the build system will rebuild the BMIs if the input compilation flag contains -DINTERESTING_MACRO=NEW_VALUE but the build system are capable to reuse the BMIs if the input compilation flag contains -DABCDEFG. This is important because almost every library has local macro definitions.

Given the lit tests are internal users, maybe we can assume all the flags to be interesting flags.

If that's the expectation, then it means that we either need to build multiple configurations of the library BMIs during CMake invocation for the test suite to reuse, or lit needs to be able to somehow rebuild BMIs (or ask CMake to do it) based on the requirement of various tests in the test suite.

If I read correctly, yes.

My mental model for the general case would be:

1. the user (a lit test with a configuration in this example) would ask the build system about the location of the BMI file with a certain module name and a list of flags.
2. The build systems will lookup if the appropriate BMI exists. If yes, return the location. If not, build it and return the location.

And in the testing case, maybe we need to implement a mechanism for lit and cmake to communicate with each other.

[ChuanqiXu]

libcxx/utils/use_modules_in_test.py

170–177

We don't want the build of modules to be affected by its users.

We don't want the build of modules to be affected by its users surprisingly. That said, the build of the modules can be affected by its users if and only if in the way designed by the modules.

[ben.boeckel]

libcxx/utils/use_modules_in_test.py

170–177

We don't want the build of modules to be affected by its users surprisingly.

Alas, consumers do need to agree on a lot of flags. We'll need at least a BMI per consuming standard. Probably per flag like -D_LIBCPP_* and the like, whatever -f and -m flags affect ABI, etc. I'd love for "I build module X one way and everyone agrees", but implementors have told me that it doesn't work that way. The ODR probably pops in at the other extreme as well.

[Mordante]

libcxx/utils/use_modules_in_test.py

170–177

Is there a way to indicate BMIs are incompatible due to ODR violations? For example when the size of a struct changes depending on compiler flags used?

[ben.boeckel]

libcxx/utils/use_modules_in_test.py

170–177

My understanding is that Clang stores the flags used to make the BMI in the BMI and if they mismatch "enough", it is incompatible. Given that…just about every flag does this (e.g., anything that affects __has_attribute, __has_builtin, or other preprocessor state), the BMI compatibility contract is very narrow. Named modules *might* be able to be a bit looser given how preprocessor state is far more isolated, but header units are going to leak these state differences far more easily.

[ChuanqiXu]

libcxx/utils/use_modules_in_test.py

170–177

Currently clang will try to perform a strict check when loading BMIs. For example if a TU imports module A and B, and the same declaration in module A and B differ, clang will emit an error.

For example when the size of a struct changes depending on compiler flags used?

But this may not be possible IIUC.

[DanielaE]

@Mordante As your direction is 'lifting' exported names from the GMF into the module purview I've initiated core issue CWG2783 https://cplusplus.github.io/CWG/issues/2783.html to strengthen the foundations.

[Mordante]

In D144994#4607621, @DanielaE wrote:

@Mordante As your direction is 'lifting' exported names from the GMF into the module purview I've initiated core issue CWG2783 https://cplusplus.github.io/CWG/issues/2783.html to strengthen the foundations.

Thanks @DanielaE! After our last discussion I had looking at this at my todo list.

[Mordante]

Since we move to GitHub PRs we're cleaning up our review queue. I abandon this patch and provide GitHub PRs for the not yet landed parts.

libcxx/CMakeLists.txt

 option(LIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS
   "Whether to turn on vendor availability annotations on declarations that depend
    on definitions in a shared library. By default, we assume that we're not building
    libc++ for any specific vendor, and we disable those annotations. Vendors wishing
    to provide compile-time errors when using features unavailable on some version of
    the shared library they shipped should turn this on and see `include/__availability`
    for more details." OFF)
 option(LIBCXX_ENABLE_CLANG_TIDY "Whether to compile and run clang-tidy checks" OFF)
+option(LIBCXX_ENABLE_STD_MODULE
+   "Whether to enable the building the C++23 std module. This feature is experimental
+    and far from usable. Only enable this when interested in testing and developing
+  this module." OFF)
 
 if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
   set(LIBCXX_DEFAULT_TEST_CONFIG "llvm-libc++-shared-gcc.cfg.in")
 elseif(MINGW)
   set(LIBCXX_DEFAULT_TEST_CONFIG "llvm-libc++-mingw.cfg.in")
 elseif(WIN32) # clang-cl
   if (LIBCXX_ENABLE_SHARED)
     set(LIBCXX_DEFAULT_TEST_CONFIG "llvm-libc++-shared-clangcl.cfg.in")
message(FATAL_ERROR "Invalid value for LIBCXX_BENCHMARK_NATIVE_STDLIB: "
             "'${LIBCXX_BENCHMARK_NATIVE_STDLIB}'")
   endif()
 endif()
 
 option(LIBCXX_INCLUDE_DOCS "Build the libc++ documentation." ${LLVM_INCLUDE_DOCS})
 set(LIBCXX_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}" CACHE STRING
     "Define suffix of library directory name (32/64)")
 option(LIBCXX_INSTALL_HEADERS "Install the libc++ headers." ON)
+option(LIBCXX_INSTALL_MODULES "Install the libc++ modules." ON)
 option(LIBCXX_INSTALL_LIBRARY "Install the libc++ library." ON)
 cmake_dependent_option(LIBCXX_INSTALL_STATIC_LIBRARY
   "Install the static libc++ library." ON
   "LIBCXX_ENABLE_STATIC;LIBCXX_INSTALL_LIBRARY" OFF)
 cmake_dependent_option(LIBCXX_INSTALL_SHARED_LIBRARY
   "Install the shared libc++ library." ON
   "LIBCXX_ENABLE_SHARED;LIBCXX_INSTALL_LIBRARY" OFF)
 

 
 #===============================================================================
 # Configure System
 #===============================================================================
 
 # TODO: Projects that depend on libc++ should use LIBCXX_GENERATED_INCLUDE_DIR
 # instead of hard-coding include/c++/v1.
 
+# TODO MODULES: CMAKE_INSTALL_MODULEDIR does not exist therefore generate one
+# based on the include dir name.
+string(REPLACE "include" "modules" CMAKE_INSTALL_MODULEDIR ${CMAKE_INSTALL_INCLUDEDIR})
+
 set(LIBCXX_INSTALL_INCLUDE_DIR "${CMAKE_INSTALL_INCLUDEDIR}/c++/v1" CACHE PATH
     "Path where target-agnostic libc++ headers should be installed.")
+set(LIBCXX_INSTALL_MODULE_DIR "${CMAKE_INSTALL_MODULEDIR}/c++/v1" CACHE PATH
+    "Path where target-agnostic libc++ modules should be installed.")
 set(LIBCXX_INSTALL_RUNTIME_DIR "${CMAKE_INSTALL_BINDIR}" CACHE PATH
     "Path where built libc++ runtime libraries should be installed.")
 
 set(LIBCXX_SHARED_OUTPUT_NAME "c++" CACHE STRING "Output name for the shared libc++ runtime library.")
 set(LIBCXX_STATIC_OUTPUT_NAME "c++" CACHE STRING "Output name for the static libc++ runtime library.")
 
 if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
   set(LIBCXX_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${LLVM_DEFAULT_TARGET_TRIPLE})
   set(LIBCXX_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
+  set(LIBCXX_GENERATED_MODULE_DIR "${LLVM_BINARY_DIR}/modules/c++/v1")
   set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR "${LLVM_BINARY_DIR}/include/${LLVM_DEFAULT_TARGET_TRIPLE}/c++/v1")
   set(LIBCXX_INSTALL_LIBRARY_DIR lib${LLVM_LIBDIR_SUFFIX}/${LLVM_DEFAULT_TARGET_TRIPLE} CACHE PATH
       "Path where built libc++ libraries should be installed.")
   set(LIBCXX_INSTALL_INCLUDE_TARGET_DIR "${CMAKE_INSTALL_INCLUDEDIR}/${LLVM_DEFAULT_TARGET_TRIPLE}/c++/v1" CACHE PATH
       "Path where target-specific libc++ headers should be installed.")
   if(LIBCXX_LIBDIR_SUBDIR)
     string(APPEND LIBCXX_LIBRARY_DIR /${LIBCXX_LIBDIR_SUBDIR})
     string(APPEND LIBCXX_INSTALL_LIBRARY_DIR /${LIBCXX_LIBDIR_SUBDIR})
   endif()
 else()
   if(LLVM_LIBRARY_OUTPUT_INTDIR)
     set(LIBCXX_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR})
     set(LIBCXX_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
+  set(LIBCXX_GENERATED_MODULE_DIR "${LLVM_BINARY_DIR}/modules/c++/v1")
   else()
     set(LIBCXX_LIBRARY_DIR ${CMAKE_BINARY_DIR}/lib${LIBCXX_LIBDIR_SUFFIX})
     set(LIBCXX_GENERATED_INCLUDE_DIR "${CMAKE_BINARY_DIR}/include/c++/v1")
+  set(LIBCXX_GENERATED_MODULE_DIR "${CMAKE_BINARY_DIR}/modules/c++/v1")
   endif()
   set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR "${LIBCXX_GENERATED_INCLUDE_DIR}")
   set(LIBCXX_INSTALL_LIBRARY_DIR lib${LIBCXX_LIBDIR_SUFFIX} CACHE PATH
       "Path where built libc++ libraries should be installed.")
   set(LIBCXX_INSTALL_INCLUDE_TARGET_DIR "${LIBCXX_INSTALL_INCLUDE_DIR}" CACHE PATH
       "Path where target-specific libc++ headers should be installed.")
 endif()
 

 endfunction()
 
 #===============================================================================
 # Setup Source Code And Tests
 #===============================================================================
 add_subdirectory(include)
 add_subdirectory(src)
 add_subdirectory(utils)
+if (LIBCXX_ENABLE_STD_MODULE)
+  add_subdirectory(modules)
+endif()
 
 set(LIBCXX_TEST_DEPS "cxx_experimental")
 
 if (LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY)
   list(APPEND LIBCXX_TEST_DEPS cxx_external_threads)
 endif()
 
 if (LIBCXX_ENABLE_CLANG_TIDY)
   list(APPEND LIBCXX_TEST_DEPS cxx-tidy)
 endif()
 
+if (LIBCXX_ENABLE_STD_MODULE)
+  list(APPEND LIBCXX_TEST_DEPS generate-cxx-modules)
+endif()
+
 if (LIBCXX_INCLUDE_BENCHMARKS)
   add_subdirectory(benchmarks)
 endif()
 
 if (LIBCXX_INCLUDE_TESTS)
   add_subdirectory(test)
   add_subdirectory(lib/abi)
 endif()
 
 if (LIBCXX_INCLUDE_DOCS)
   add_subdirectory(docs)
 endif()

libcxx/docs/Modules.rst

+.. _ModulesInLibcxx:
+
+=================
+Modules in libc++
+=================
+
+This page contains information regarding C++23 module support in libc++.
+There are two kinds of modules available in Clang
+
+ * `Clang specific modules <https://clang.llvm.org/docs/Modules.html>`_
+ * `C++ modules <https://clang.llvm.org/docs/StandardCPlusPlusModules.html>`_
+
+This page mainly discusses the C++ modules. In C++ there are also header units,
+these are not in this patch.
+
+This information is mainly to describe some of the features of this work in
+progress patch. It is not intended to be committed in this form.
+
+Overview
+========
+
+The module sources are stored in ``.cppm`` files. These need to be available as
+BMIs, which are ``.pcm`` files for Clang. These files are not portable, they
+depend on the compiler used and its compilation flags. Therefore there needs to
+be a way to distribute the ``.cppm`` files to the user and offer a way for them
+to build and use the ``.pcm`` files.
+
+What works
+~~~~~~~~~~
+
+ * Building BMIs
+ * Running tests using modules, not all tests pass yet.
+ * Using the ``std`` module in external projects
+ * Using the ``std.compat`` module in external projects
+
+Some of the current limitations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ * For now everything requires CMake.
+ * The files are not installed, but available in the build tree.
+ * The ``pcm`` files are regenerated when running a ``lit`` invocation.
+ * There is no Buildkite CI job yet. Work on this has started, but the CI Docker
+   image is not updated yet. (There are issues with the official CI image which
+   need to be resolved before adding new features.)
+ * The ``std`` module is almost complete.
+ * The ``std.compat`` module is almost complete.
+ * The modules are not tested.
+ * The modules are not reviewed for correctness.
+ * Requires CMake 3.26
+ * Requires Ninja 1.11
+ * Requires Clang 17 (Clang 16 should work, but is not tested)
+ * The path to the compiler may not be a symlink, ``clang-scan-deps`` does
+   not handle that case properly.
+ * Configurations with parts disable do not work properly. The ``#ifdef``
+   are not in the ``.cppm`` files yet.
+
+Blockers
+~~~~~~~~
+
+  * libc++
+
+    * Tests depend on ``uint32_t``, ``size_t`` in the global namespace.
+      Fixing this is WIP.
+    * There are a lot of failing tests, this needs to be investigated after
+      the global namespace issues have been fixed.
+      Currently 222 of the 7243 test in the directory ``libcxx/test/std`` fail
+      when using the ``std.compat`` module.
+    * CMake 3.26 doesn't work with ``libunwind``. For ``libc++`` and
+      ``libc++abi`` it ignores a lot of compilation flags.
+      `Patch <https://llvm.org/D145596>`__
+    * The ``-pthread`` flag is not used a compile flag. This flag affects
+      the preprocessor so it should be a compile and linker flag.
+      There is a WIP patch.
+    * There are symbols with internal linkage in the header.
+
+      * Due to older language versions don't support ``inline constexpr``.
+        `Patch <https://reviews.llvm.org/D143797>`__
+      * The code contains ``_LIBCPP_HIDE_FROM_ABI static constexpr``. There
+        might be a patch.
+
+  * Clang
+
+    * ``__synth_three_way_result`` does not work. There is a work-around in libc++.
+
+      * `bug report <https://github.com/llvm/llvm-project/issues/57222>`__
+      * `patch <https://reviews.llvm.org/D140002>`__
+
+    * The ranges Niebloids doen't work properly. There is no bug report, this
+      might be related to ``__synth_three_way_result``. Changing
+      ``inline constexpr auto foo = foo_t{}`` to
+      ``inline constexpr foo_t foo{}`` seems to fix it in libc++.
+
+    * Including headers after importing the ``std`` module may fail. This is
+      hard to solve and there is a work-around by first including all headers.
+      `bug report <https://github.com/llvm/llvm-project/issues/61329>`__
+
+Discussion points
+~~~~~~~~~~~~~~~~~
+
+ * The ``std`` module is a C++23 feature, currently it's available in both
+   ``C++20`` and ``C++23``. The simple reason is that this allows testing with
+   different language versions. (This will be needed once the first ``C++26``
+   features become available.) Does libc++ want to retroactively supply the
+   module in ``C++23`` or restrict it to ``C++23`` and later?
+ * Do we want the feature behind a configuration flag or not? Louis already
+   mentioned he prefers it generally available. Then we need to restrict it on
+   the CMake version used.
+ * I'm not too unhappy with the generic approach for user project. I am quite
+   unhappy with how we need to do tests. I have some ideas how we can improve
+   this, basically by caching multiple configurations. However it would be good
+   to discuss that approach before spending effort in it.
+ * Currently the ``.cppm`` file and the generated ``CMakeLists.txt`` are not
+   installed. Before doing that it would be good to determine what the best
+   location for these files is.
+ * The current approach to make the tests work with modules add a ``#ifdef``
+   to select between including headers or importing the module ``std``.
+   This works great for testing during development, however the libc++
+   maintainers need to decide to keep using this approach in production or
+   that a different solution needs to be used.
+
+
+Design choices
+==============
+
+Shipping
+--------
+
+Since BMIs are not portable libc++ will ship its ``cppm`` files. Users need to
+compile them to BMIs. Since the feature is under heavy development there is no
+support for build tools. For that reason a CMake file will be shipped. Once
+build tool vendors have support for libc++'s modules this support file will be
+removed. (This file is used for the libc++ tests too, so maybe it remains build
+it will not longer be shipped.)
+
+The modules will shipped in a directory structure similar to the include.
+Includes are stored in ``<PREFIX>/modules/c++/v1`` modules will be stored in
+``<PREFIX>/modules/c++/v1/``.
+
+To make it easy for build tool vendors the directory
+``<PREFIX>/modules/c++/v1/`` will have the following contents
+
+  * ``std.cppm`` the main ``std`` module source.
+  * ``std/`` all other sources for the ``std`` module. Using this directory
+    makes it easy for vendors to glob all files belonging the the ``std``
+    module.
+  * ``std.compat.cppm`` the main ``std.compat`` module source.
+  * ``std.compat/`` like ``std/`` but for the ``std.compat`` module.
+
+If in the future the C++ Standard defines more modules they will get a similar
+treatment. (For example modules for experimental library features.)
+
+.. note:: This matches the current proposal on `discourse
+   <https://discourse.llvm.org/t/rfc-about-the-default-location-for-std-modules/69191/29>`__
+   so it may still change.
+
+Testing
+-------
+
+To properly test all tests with modules all tests need to be converted. The
+script ``libcxx/utils/use_modules_in_test.py`` can do this conversion. Since not
+all developers are happy with the output this script will be executed in the CI
+and then the CI will run on the modified sources.
+
+Running tests
+=============
+
+In order to run the tests with C++23 modules the libc++ needs to be build with
+the following configuration option in CMake ``LIBCXX_ENABLE_STD_MODULE``.
+
+The tests are executed like
+
+.. code-block:: bash
+
+  $ <build>/bin/llvm-lit -sv libcxx/test/std/containers # Run the tests without modules
+  $ <build>/bin/llvm-lit -sv -Denable_modules=clang libcxx/test/std/containers # Run the tests with Clang modules
+  $ <build>/bin/llvm-lit -sv -Denable_modules=std libcxx/test/std/containers # Run the tests with Standard std module
+  $ <build>/bin/llvm-lit -sv -Denable_modules=std.compat libcxx/test/std/containers # Run the tests with Standard std.compat module
+
+The Clang modules are the modules that have been available for many libc++ releases.
+The Standard modules are the new feature.
+
+Using in external projects
+==========================
+
+Users need to be able to build their own BMI files. Currently this requires a
+local build of libc++ with modules enabled. "Importing" libc++ is a project can
+be done with the following CMake code.
+
+.. code-block:: cmake
+
+  include(FetchContent)
+  FetchContent_Declare(
+    std
+    URL file://<build>/include/c++/modules/
+    DOWNLOAD_EXTRACT_TIMESTAMP TRUE
+  )
+  FetchContent_GetProperties(std)
+  if(NOT std_POPULATED)
+    # The C++ version used in your project must match the version used here.
+    set(CMAKE_CXX_STANDARD 23)
+    # These compiler flags must match the flags used in your project.
+    # When they don't match the generated BMIs can't be used in your project.
+    set(CMAKE_CXX_FLAGS "-fexperimental-library")
+    FetchContent_Populate(std)
+    add_subdirectory(${std_SOURCE_DIR} ${std_BINARY_DIR} EXCLUDE_FROM_ALL)
+  endif()
+
+The libraries and/or executables that use the ``std`` module need to link
+against the ``std`` library. This is needed for CMake to get the proper module
+dependencies. Similar for the ``std.compat`` module.
+
+.. warning:: There is a bug in Clang where including headers after an import
+   may fail. Instead include all headers first and then include the module.
+
+
+.. code-block:: cmake
+
+   #include <vector>
+
+   #include "A header that may include other headers.h"
+
+   import std;
+
+   ...

libcxx/include/__compare/synth_three_way.h

 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
 #if _LIBCPP_STD_VER >= 20
 
 // [expos.only.func]
 
+// Fails with C++20 modules.
+// https://github.com/llvm/llvm-project/issues/57222#issuecomment-1261618636
+// Possible fix https://reviews.llvm.org/D140002
+#if 0
 _LIBCPP_HIDE_FROM_ABI inline constexpr auto __synth_three_way =
   []<class _Tp, class _Up>(const _Tp& __t, const _Up& __u)
     requires requires {
       { __t < __u } -> __boolean_testable;
       { __u < __t } -> __boolean_testable;
     }
   {
     if constexpr (three_way_comparable_with<_Tp, _Up>) {
       return __t <=> __u;
     } else {
       if (__t < __u) return weak_ordering::less;
       if (__u < __t) return weak_ordering::greater;
       return weak_ordering::equivalent;
     }
   };
+#else
+template <class _Tp, class _Up>
+_LIBCPP_HIDE_FROM_ABI constexpr auto __synth_three_way(const _Tp& __t, const _Up& __u)
+    requires requires {
+      { __t < __u } -> __boolean_testable;
+      { __u < __t } -> __boolean_testable;
+    }
+  {
+    if constexpr (three_way_comparable_with<_Tp, _Up>) {
+      return __t <=> __u;
+    } else {
+      if (__t < __u) return weak_ordering::less;
+      if (__u < __t) return weak_ordering::greater;
+      return weak_ordering::equivalent;
+    }
+  }
+#endif
 
 template <class _Tp, class _Up = _Tp>
 using __synth_three_way_result = decltype(std::__synth_three_way(std::declval<_Tp&>(), std::declval<_Up&>()));
 
 #endif // _LIBCPP_STD_VER >= 20
 
 _LIBCPP_END_NAMESPACE_STD
 
 #endif // _LIBCPP___COMPARE_SYNTH_THREE_WAY_H

libcxx/modules/CMakeLists.txt.in

+# CMake 3.25 has modules support, but that does not work properly.
+cmake_minimum_required(VERSION 3.26)
+
+project(libc++-std LANGUAGES CXX)
+
+# Enable CMake's module support
+set(CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API "2182bf5c-ef0d-489a-91da-49dbc3090d2a")
+set(CMAKE_EXPERIMENTAL_CXX_MODULE_DYNDEP 1)
+
+# Default to C++ extensions being off. Clang's modules support have trouble
+# with extensions right now.
+set(CMAKE_CXX_EXTENSIONS OFF)
+
+# Propagates the CMake options to the modules.
+#
+# This uses the std module hard-coded since the std.compat module does not
+# depend on these flags.
+macro(compile_define_if_not condition def)
+  if (NOT ${condition})
+    target_compile_definitions(std PRIVATE ${def})
+  endif()
+endmacro()
+macro(compile_define_if condition def)
+  if (${condition})
+    target_compile_definitions(std PRIVATE ${def})
+  endif()
+endmacro()
+
+if(NOT @LIBCXX_ENABLE_THREADS@ OR NOT @LIBCXXABI_ENABLE_THREADS@ OR NOT @LIBCXX_ENABLE_MONOTONIC_CLOCK@)
+  message(FATAL_ERROR "Modules without thread support is not yet implemented.")
+endif()
+if(NOT @LIBCXX_ENABLE_FILESYSTEM@)
+  message(FATAL_ERROR "Modules without filesystem support is not yet implemented.")
+endif()
+if(NOT @LIBCXX_ENABLE_RANDOM_DEVICE@)
+  message(FATAL_ERROR "Modules without randome device support is not yet implemented.")
+endif()
+if(NOT @LIBCXX_ENABLE_FSTREAM@)
+  message(FATAL_ERROR "Modules without fstream support is not yet implemented.")
+endif()
+if(NOT @LIBCXX_ENABLE_UNICODE@)
+  message(FATAL_ERROR "Modules without Unicode support is not yet implemented.")
+endif()
+if(NOT @LIBCXX_ENABLE_EXCEPTIONS@ OR NOT @LIBCXXABI_ENABLE_EXCEPTIONS@)
+  message(FATAL_ERROR "Modules without exception support is not yet implemented.")
+endif()
+
+add_library(std)
+target_sources(std
+  PUBLIC FILE_SET cxx_modules TYPE CXX_MODULES FILES
+    @LIBCXX_SOURCES_MODULE_STD@
+)
+
+target_compile_definitions(std PRIVATE _LIBCPP_ENABLE_EXPERIMENTAL)
+target_include_directories(std SYSTEM PRIVATE @LIBCXX_CONFIGURED_INCLUDE_DIR@)
+
+target_compile_options(std
+  PUBLIC
+    -nostdinc++
+    @LIBCXX_COMPILE_FLAGS@
+)
+
+add_library(std.compat)
+target_sources(std.compat
+  PUBLIC FILE_SET cxx_modules TYPE CXX_MODULES FILES
+    @LIBCXX_SOURCES_MODULE_STD_COMPAT@
+)
+target_include_directories(std.compat SYSTEM PRIVATE @LIBCXX_CONFIGURED_INCLUDE_DIR@)
+target_compile_options(std.compat
+  PUBLIC
+    -nostdinc++
+    # HACK to find the std module
+    -fmodule-file=std=CMakeFiles/std.dir/std.pcm
+    @LIBCXX_COMPILE_FLAGS@
+)
+target_link_libraries(std.compat PRIVATE std)

libcxx/modules/std.compat/cassert.cppm

+# 1 __FILE__ 1 3
+// -*- C++ -*-
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+module;
+#include <cassert>
+
+export module std.compat:cassert;
+export {
+  // This module exports nothing.
+} // export

libcxx/modules/std/format.cppm

+# 1 __FILE__ 1 3
+// -*- C++ -*-
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+// TODO This file is two-fold
+// - look at how we want to integrate a synopsis
+// - test whether the experimental library works properly
+
+module;
+#include <format> // Since C++20
+
+export module std:format;
+#if !defined(_LIBCPP_HAS_NO_INCOMPLETE_FORMAT)
+export namespace std {
+
+  // [format.context], class template basic_format_context
+  // template <class Out, class charT>
+  // class basic_format_context;
+  using std::basic_format_context;
+  /*
+    template<class Out, class charT>
+    class basic_format_context {
+      basic_format_args<basic_format_context> args_;      // exposition only
+      Out out_;                                           // exposition only
+
+    public:
+      using iterator = Out;
+      using char_type = charT;
+      template<class T> using formatter_type = formatter<T, charT>;
+
+      basic_format_arg<basic_format_context> arg(size_t id) const noexcept;
+      std::locale locale();
+
+      iterator out();
+      void advance_to(iterator it);
+    };
+  */
+  // using format_context  = basic_format_context<unspecified, char>;
+  // using wformat_context = basic_format_context<unspecified, wchar_t>;
+  using std::format_context;
+#  ifndef _LIBCPP_HAS_NO_WIDE_CHARACTERS
+  using std::wformat_context;
+#  endif
+
+  // [format.args], class template basic_format_args
+  // template <class Context>
+  // class basic_format_args;
+  using std::basic_format_args;
+  /*
+    template<class Context>
+    class basic_format_args {
+      size_t size_;                               // exposition only
+      const basic_format_arg<Context>* data_;     // exposition only
+
+    public:
+      basic_format_args() noexcept;
+
+      template<class... Args>
+        basic_format_args(const format-arg-store<Context, Args...>& store) noexcept;
+
+      basic_format_arg<Context> get(size_t i) const noexcept;
+    };
+  */
+  // using format_args  = basic_format_args<format_context>;
+  // using wformat_args = basic_format_args<wformat_context>;
+  using std::format_args;
+#  ifndef _LIBCPP_HAS_NO_WIDE_CHARACTERS
+  using std::wformat_args;
+#  endif
+
+  // [format.fmt.string], class template basic_format_string
+  // template <class charT, class... Args>
+  // struct basic_format_string;
+  using std::basic_format_string;
+
+  // template <class... Args>
+  // using format_string = basic_format_string<char, type_identity_t<Args>...>;
+  // template <class... Args>
+  // using wformat_string = basic_format_string<wchar_t, type_identity_t<Args>...>;
+  using std::format_string;
+#  ifndef _LIBCPP_HAS_NO_WIDE_CHARACTERS
+  using std::wformat_string;
+#  endif
+
+  // [format.functions], formatting functions
+  // template <class... Args>
+  // string format(format_string<Args...> fmt, Args&&... args);
+  // template <class... Args>
+  // wstring format(wformat_string<Args...> fmt, Args&&... args);
+  // template <class... Args>
+  // string format(const locale& loc, format_string<Args...> fmt, Args&&... args);
+  // template <class... Args>
+  // wstring format(const locale& loc, wformat_string<Args...> fmt, Args&&... args);
+  using std::format;
+
+  // string vformat(string_view fmt, format_args args);
+  // wstring vformat(wstring_view fmt, wformat_args args);
+  // string vformat(const locale& loc, string_view fmt, format_args args);
+  // wstring vformat(const locale& loc, wstring_view fmt, wformat_args args);
+  using std::vformat;
+
+  // template <class Out, class... Args>
+  // Out format_to(Out out, format_string<Args...> fmt, Args&&... args);
+  // template <class Out, class... Args>
+  // Out format_to(Out out, wformat_string<Args...> fmt, Args&&... args);
+  // template <class Out, class... Args>
+  // Out format_to(Out out, const locale& loc, format_string<Args...> fmt, Args&&... args);
+  // template <class Out, class... Args>
+  // Out format_to(Out out, const locale& loc, wformat_string<Args...> fmt, Args&&... args);
+  using std::format_to;
+
+  // template <class Out>
+  // Out vformat_to(Out out, string_view fmt, format_args args);
+  // template <class Out>
+  // Out vformat_to(Out out, wstring_view fmt, wformat_args args);
+  // template <class Out>
+  // Out vformat_to(Out out, const locale& loc, string_view fmt, format_args args);
+  // template <class Out>
+  // Out vformat_to(Out out, const locale& loc, wstring_view fmt, wformat_args args);
+  using std::vformat_to;
+
+  // template <class Out>
+  // struct format_to_n_result {
+  //   Out out;
+  //   iter_difference_t<Out> size;
+  // };
+  using std::format_to_n_result;
+  // template <class Out, class... Args>
+  // format_to_n_result<Out> format_to_n(Out out, iter_difference_t<Out> n, format_string<Args...> fmt, Args&&... args);
+  // template <class Out, class... Args>
+  // format_to_n_result<Out> format_to_n(Out out, iter_difference_t<Out> n, wformat_string<Args...> fmt, Args&&...
+  // args); template <class Out, class... Args> format_to_n_result<Out> format_to_n(Out out, iter_difference_t<Out> n,
+  // const locale& loc, format_string<Args...> fmt, Args&&... args); template <class Out, class... Args>
+  // format_to_n_result<Out>
+  // format_to_n(Out out, iter_difference_t<Out> n, const locale& loc, wformat_string<Args...> fmt, Args&&... args);
+  using std::format_to_n;
+
+  // template <class... Args>
+  // size_t formatted_size(format_string<Args...> fmt, Args&&... args);
+  // template <class... Args>
+  // size_t formatted_size(wformat_string<Args...> fmt, Args&&... args);
+  // template <class... Args>
+  // size_t formatted_size(const locale& loc, format_string<Args...> fmt, Args&&... args);
+  // template <class... Args>
+  // size_t formatted_size(const locale& loc, wformat_string<Args...> fmt, Args&&... args);
+  using std::formatted_size;
+
+  // [format.formatter], formatter
+  // template <class T, class charT = char>
+  // struct formatter;
+  using std::formatter;
+
+  // [format.formattable], concept formattable
+  // template <class T, class charT>
+  // concept formattable = see below; // Since C++23
+  using std::formattable;
+
+  // template <class R, class charT>
+  //     concept const-formattable-range = // exposition only
+  //     ranges::input_range<const R> && formattable<ranges::range_reference_t<const R>, charT>;
+
+  // template <class R, class charT>
+  //     using fmt-maybe-const = // exposition only
+  //     conditional_t<const-formattable-range<R, charT>, const R, R>;
+
+  // [format.parse.ctx], class template basic_format_parse_context
+  // template <class charT>a
+  // class basic_format_parse_context;
+  using std::basic_format_parse_context;
+
+  /*
+    template<class charT>
+    class basic_format_parse_context {
+    public:
+      using char_type = charT;
+      using const_iterator = typename basic_string_view<charT>::const_iterator;
+      using iterator = const_iterator;
+
+    private:
+      iterator begin_;                                    // exposition only
+      iterator end_;                                      // exposition only
+      enum indexing { unknown, manual, automatic };       // exposition only
+      indexing indexing_;                                 // exposition only
+      size_t next_arg_id_;                                // exposition only
+      size_t num_args_;                                   // exposition only
+
+    public:
+      constexpr explicit basic_format_parse_context(basic_string_view<charT> fmt,
+                                                    size_t num_args = 0) noexcept;
+      basic_format_parse_context(const basic_format_parse_context&) = delete;
+      basic_format_parse_context& operator=(const basic_format_parse_context&) = delete;
+
+      constexpr const_iterator begin() const noexcept;
+      constexpr const_iterator end() const noexcept;
+      constexpr void advance_to(const_iterator it);
+
+      constexpr size_t next_arg_id();
+      constexpr void check_arg_id(size_t id);
+    };
+  */
+
+  // using format_parse_context  = basic_format_parse_context<char>;
+  // using wformat_parse_context = basic_format_parse_context<wchar_t>;
+  using std::format_parse_context;
+#  ifndef _LIBCPP_HAS_NO_WIDE_CHARACTERS
+  using std::wformat_parse_context;
+#  endif
+
+  // [format.range], formatting of ranges
+  // [format.range.fmtkind], variable template format_kind
+  // enum class range_format { disabled, map, set, sequence, string, debug_string }; // Since C++23
+  using std::range_format;
+
+  // template <class R>
+  // constexpr unspecified format_kind = unspecified;
+  using std::format_kind;
+
+  // template <ranges::input_range R>
+  //   requires same_as<R, remove_cvref_t<R>>
+  // constexpr range_format format_kind<R> = see below;
+  using std::format_kind;
+
+  // [format.range.formatter], class template range_formatter
+  // template <class T, class charT = char>
+  //  requires same_as<remove_cvref_t<T>, T> && formattable<T, charT>
+  // class range_formatter;
+  using std::range_formatter;
+
+  /*
+    template<class T, class charT = char>
+      requires same_as<remove_cvref_t<T>, T> && formattable<T, charT>
+    class range_formatter {
+      formatter<T, charT> underlying_;                                          // exposition only
+      basic_string_view<charT> separator_ = STATICALLY-WIDEN<charT>(", ");      // exposition only
+      basic_string_view<charT> opening-bracket_ = STATICALLY-WIDEN<charT>("["); // exposition only
+      basic_string_view<charT> closing-bracket_ = STATICALLY-WIDEN<charT>("]"); // exposition only
+
+    public:
+      constexpr void set_separator(basic_string_view<charT> sep);
+      constexpr void set_brackets(basic_string_view<charT> opening,
+                                  basic_string_view<charT> closing);
+      constexpr formatter<T, charT>& underlying() { return underlying_; }
+      constexpr const formatter<T, charT>& underlying() const { return underlying_; }
+
+      template<class ParseContext>
+        constexpr typename ParseContext::iterator
+          parse(ParseContext& ctx);
+
+      template<ranges::input_range R, class FormatContext>
+          requires formattable<ranges::range_reference_t<R>, charT> &&
+                   same_as<remove_cvref_t<ranges::range_reference_t<R>>, T>
+        typename FormatContext::iterator
+          format(R&& r, FormatContext& ctx) const;
+    };
+  */
+
+  // [format.range.fmtdef], class template range-default-formatter
+  // template <range_format K, ranges::input_range R, class charT>
+  //    struct range-default-formatter; // exposition only
+  /*
+    template<ranges::input_range R, class charT>
+    struct range-default-formatter<range_format::sequence, R, charT> {    // exposition only
+    private:
+      using maybe-const-r = fmt-maybe-const<R, charT>;                    // exposition only
+      range_formatter<remove_cvref_t<ranges::range_reference_t<maybe-const-r>>,
+                      charT> underlying_;                                 // exposition only
+
+    public:
+      constexpr void set_separator(basic_string_view<charT> sep);
+      constexpr void set_brackets(basic_string_view<charT> opening,
+                                  basic_string_view<charT> closing);
+
+      template<class ParseContext>
+        constexpr typename ParseContext::iterator
+          parse(ParseContext& ctx);
+
+      template<class FormatContext>
+        typename FormatContext::iterator
+          format(maybe-const-r& elems, FormatContext& ctx) const;
+    };
+  */
+
+  // [format.range.fmtmap], [format.range.fmtset], [format.range.fmtstr], specializations for maps, sets, and strings
+  /*
+    template<ranges::input_range R, class charT>                         // Since C++23
+    struct range-default-formatter<range_format::map, R, charT> {
+    private:
+      using maybe-const-map = fmt-maybe-const<R, charT>;                  // exposition only
+      using element-type =                                                // exposition only
+        remove_cvref_t<ranges::range_reference_t<maybe-const-map>>;
+      range_formatter<element-type, charT> underlying_;                   // exposition only
+
+    public:
+      constexpr range-default-formatter();
+
+      template<class ParseContext>
+        constexpr typename ParseContext::iterator
+          parse(ParseContext& ctx);
+
+      template<class FormatContext>
+        typename FormatContext::iterator
+          format(maybe-const-map& r, FormatContext& ctx) const;
+    };
+
+    template<ranges::input_range R, class charT>
+    struct range-default-formatter<range_format::set, R, charT> {         // Since C++23
+    private:
+      using maybe-const-set = fmt-maybe-const<R, charT>;                  // exposition only
+      range_formatter<remove_cvref_t<ranges::range_reference_t<maybe-const-set>>,
+                      charT> underlying_;                                 // exposition only
+
+    public:
+      constexpr range-default-formatter();
+
+      template<class ParseContext>
+        constexpr typename ParseContext::iterator
+          parse(ParseContext& ctx);
+
+      template<class FormatContext>
+        typename FormatContext::iterator
+          format(maybe-const-set& r, FormatContext& ctx) const;
+    };
+
+    template<range_format K, ranges::input_range R, class charT>
+      requires (K == range_format::string || K == range_format::debug_string)
+    struct range-default-formatter<K, R, charT> {                         // Since C++23
+    private:
+      formatter<basic_string<charT>, charT> underlying_;                  // exposition only
+
+    public:
+      template<class ParseContext>
+        constexpr typename ParseContext::iterator
+          parse(ParseContext& ctx);
+
+      template<class FormatContext>
+        typename FormatContext::iterator
+          format(see below& str, FormatContext& ctx) const;
+    };
+  */
+  // template <ranges::input_range R, class charT>
+  //   requires(format_kind<R> != range_format::disabled) &&
+  //           formattable<ranges::range_reference_t<R>, charT>
+  //           struct formatter<R, charT> : range-default-formatter<format_kind<R>, R, charT> {};
+
+  // [format.arguments], arguments
+  // [format.arg], class template basic_format_arg
+  // template <class Context>
+  // class basic_format_arg;
+  using std::basic_format_arg;
+
+  /*
+    template<class Context>
+    class basic_format_arg {
+    public:
+      class handle;
+
+    private:
+      using char_type = typename Context::char_type;                              // exposition only
+
+      variant<monostate, bool, char_type,
+              int, unsigned int, long long int, unsigned long long int,
+              float, double, long double,
+              const char_type*, basic_string_view<char_type>,
+              const void*, handle> value;                                         // exposition only
+
+      template<class T> explicit basic_format_arg(T&& v) noexcept;                // exposition only
+      explicit basic_format_arg(float n) noexcept;                                // exposition only
+      explicit basic_format_arg(double n) noexcept;                               // exposition only
+      explicit basic_format_arg(long double n) noexcept;                          // exposition only
+      explicit basic_format_arg(const char_type* s);                              // exposition only
+
+      template<class traits>
+        explicit basic_format_arg(
+          basic_string_view<char_type, traits> s) noexcept;                       // exposition only
+
+      template<class traits, class Allocator>
+        explicit basic_format_arg(
+          const basic_string<char_type, traits, Allocator>& s) noexcept;          // exposition only
+
+      explicit basic_format_arg(nullptr_t) noexcept;                              // exposition only
+
+      template<class T>
+        explicit basic_format_arg(T* p) noexcept;                                 // exposition only
+
+    public:
+      basic_format_arg() noexcept;
+
+      explicit operator bool() const noexcept;
+    };
+
+    template<class Context>
+    class basic_format_arg<Context>::handle {
+      const void* ptr_;                                           // exposition only
+      void (*format_)(basic_format_parse_context<char_type>&,
+                      Context&, const void*);                     // exposition only
+
+      template<class T> explicit handle(T&& val) noexcept;        // exposition only
+
+      friend class basic_format_arg<Context>;                     // exposition only
+
+    public:
+      void format(basic_format_parse_context<char_type>&, Context& ctx) const;
+    };
+  */
+
+  // template <class Visitor, class Context>
+  // decltype(auto) visit_format_arg(Visitor&& vis, basic_format_arg<Context> arg);
+  using std::visit_format_arg;
+
+  // [format.arg.store], class template format-arg-store
+  // template <class Context, class... Args>
+  //    class format-arg-store; // exposition only
+  /*
+    template<class Context, class... Args>
+    class format-arg-store {                                      // exposition only
+      array<basic_format_arg<Context>, sizeof...(Args)> args;     // exposition only
+    };
+  */
+
+  // template <class Context = format_context, class... Args>
+  //     format-arg-store<Context, Args...> make_format_args(Args&&... fmt_args);
+  // template <class... Args>
+  //     format-arg-store<wformat_context, Args...> make_wformat_args(Args&&... args);
+  using std::make_format_args;
+#  ifndef _LIBCPP_HAS_NO_WIDE_CHARACTERS
+  using std::make_wformat_args;
+#  endif
+
+  // [format.error], class format_error
+  // class format_error;
+  using std::format_error;
+  /*
+    class format_error : public runtime_error {
+    public:
+      explicit format_error(const string& what_arg);
+      explicit format_error(const char* what_arg);
+    };
+  */
+
+  /*
+    template<class charT, formattable<charT>... Ts>
+    struct formatter<pair-or-tuple<Ts...>, charT> {                             // Since C++23
+    private:
+      tuple<formatter<remove_cvref_t<Ts>, charT>...> underlying_;               // exposition only
+      basic_string_view<charT> separator_ = STATICALLY-WIDEN<charT>(", ");      // exposition only
+      basic_string_view<charT> opening-bracket_ = STATICALLY-WIDEN<charT>("("); // exposition only
+      basic_string_view<charT> closing-bracket_ = STATICALLY-WIDEN<charT>(")"); // exposition only
+
+    public:
+      constexpr void set_separator(basic_string_view<charT> sep);
+      constexpr void set_brackets(basic_string_view<charT> opening,
+                                  basic_string_view<charT> closing);
+
+      template<class ParseContext>
+        constexpr typename ParseContext::iterator
+          parse(ParseContext& ctx);
+
+      template<class FormatContext>
+        typename FormatContext::iterator
+          format(see below& elems, FormatContext& ctx) const;
+    };
+  */
+} // namespace std
+#endif // !defined(_LIBCPP_HAS_NO_INCOMPLETE_FORMAT)

libcxx/modules/std/memory.cppm

+# 1 __FILE__ 1 3
+// -*- C++ -*-
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+module;
+#include <memory>
+
+export module std:memory;
+export namespace std {
+  // [pointer.traits], pointer traits
+  using std::pointer_traits;
+
+  // [pointer.conversion], pointer conversion
+  using std::to_address;
+
+  // [ptr.align], pointer alignment
+  using std::align;
+  using std::assume_aligned;
+
+  // [obj.lifetime], explicit lifetime management
+  //  using std::start_lifetime_as; NOT IMPLEMENTED
+  //  using std::start_lifetime_as_array NOT IMPLEMENTED;
+
+  // [allocator.tag], allocator argument tag
+  //  using std::allocator_arg; TODO INTERNAL LINKAGE
+  //  using std::allocator_arg_t TODO INTERNAL LINKAGE;
+
+  // [allocator.uses], uses_allocator
+  using std::uses_allocator;
+
+  // [allocator.uses.trait], uses_allocator
+  using std::uses_allocator_v;
+
+  // [allocator.uses.construction], uses-allocator construction
+  using std::uses_allocator_construction_args;
+
+  using std::make_obj_using_allocator;
+  using std::uninitialized_construct_using_allocator;
+
+  // [allocator.traits], allocator traits
+  using std::allocator_traits; // freestanding
+
+  using std::allocation_result;
+
+  using std::allocate_at_least;
+
+  // [default.allocator], the default allocator
+  using std::allocator;
+  using std::operator==;
+
+  // [specialized.addressof], addressof
+  using std::addressof;
+
+  // [specialized.algorithms], specialized algorithms
+  // [special.mem.concepts], special memory concepts
+
+  using std::uninitialized_default_construct;
+  using std::uninitialized_default_construct_n;
+
+  namespace ranges {
+    using std::ranges::uninitialized_default_construct;
+    using std::ranges::uninitialized_default_construct_n;
+  } // namespace ranges
+
+  using std::uninitialized_value_construct;
+  using std::uninitialized_value_construct_n;
+
+  namespace ranges {
+    using std::ranges::uninitialized_value_construct;
+    using std::ranges::uninitialized_value_construct_n;
+  } // namespace ranges
+
+  using std::uninitialized_copy;
+  using std::uninitialized_copy_n;
+
+  namespace ranges {
+    using std::ranges::uninitialized_copy;
+    using std::ranges::uninitialized_copy_result;
+
+    using std::ranges::uninitialized_copy_n;
+    using std::ranges::uninitialized_copy_n_result;
+
+  } // namespace ranges
+  using std::uninitialized_move;
+  using std::uninitialized_move_n;
+
+  namespace ranges {
+    using std::ranges::uninitialized_move;
+    using std::ranges::uninitialized_move_result;
+
+    using std::ranges::uninitialized_move_n;
+    using std::ranges::uninitialized_move_n_result;
+
+  } // namespace ranges
+
+  using std::uninitialized_fill;
+  using std::uninitialized_fill_n;
+
+  namespace ranges {
+    using std::ranges::uninitialized_fill;
+    using std::ranges::uninitialized_fill_n;
+  } // namespace ranges
+
+  // [specialized.construct], construct_at
+  using std::construct_at;
+
+  namespace ranges {
+    using std::ranges::construct_at;
+  }
+  // [specialized.destroy], destroy
+  using std::destroy;
+  using std::destroy_at;
+  using std::destroy_n;
+
+  namespace ranges {
+    using std::ranges::destroy;
+    using std::ranges::destroy_at;
+    using std::ranges::destroy_n;
+  } // namespace ranges
+    // [unique.ptr], class template unique_ptr
+  using std::default_delete;
+  using std::unique_ptr;
+
+  using std::make_unique;
+  using std::make_unique_for_overwrite;
+
+  using std::swap;
+
+  using std::operator!=;
+  using std::operator<;
+  using std::operator>;
+  using std::operator<=;
+  using std::operator>=;
+  using std::operator<=>;
+
+  using std::operator<<;
+
+  // [util.smartptr.weak.bad], class bad_weak_ptr
+  using std::bad_weak_ptr;
+
+  // [util.smartptr.shared], class template shared_ptr
+  using std::shared_ptr;
+
+  // [util.smartptr.shared.create], shared_ptr creation
+  using std::allocate_shared;
+  using std::make_shared;
+
+  using std::make_shared_for_overwrite;
+
+  // [util.smartptr.shared.spec], shared_ptr specialized algorithms
+  using std::swap;
+
+  // [util.smartptr.shared.cast], shared_ptr casts
+  using std::const_pointer_cast;
+  using std::dynamic_pointer_cast;
+  using std::reinterpret_pointer_cast;
+  using std::static_pointer_cast;
+
+  using std::get_deleter;
+
+  // [util.smartptr.shared.io], shared_ptr I/O
+
+  // [util.smartptr.weak], class template weak_ptr
+  using std::weak_ptr;
+
+  // [util.smartptr.weak.spec], weak_ptr specialized algorithms
+
+  // [util.smartptr.ownerless], class template owner_less
+  using std::owner_less;
+
+  // [util.smartptr.enab], class template enable_shared_from_this
+  using std::enable_shared_from_this;
+
+  // [util.smartptr.hash], hash support
+  using std::hash;
+
+  // [util.smartptr.atomic], atomic smart pointers
+  using std::atomic;
+
+  // [out.ptr.t], class template out_ptr_t
+  //  using std::out_ptr_t NOT IMPLEMENTED;
+
+  // [out.ptr], function template out_ptr
+  //  using std::out_ptr NOT IMPLEMENTED;
+
+  // [inout.ptr.t], class template inout_ptr_t
+  //  using std::inout_ptr_t NOT IMPLEMENTED;
+
+  // [inout.ptr], function template inout_ptr
+  //  using std::inout_ptr NOT IMPLEMENTED;
+
+} // namespace std

libcxx/test/libcxx/language.support/support.types/cstddef.compile.pass.cpp

 //===----------------------------------------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 // Make sure libc++'s <cstddef> defines types like ::nullptr_t in the global namespace.
 // This is a conforming extension to be consistent with other implementations, which all
 // appear to provide that behavior too.
 
-#include <cstddef>
+// XFAIL: use_module_std
+
+#if defined(TEST_USE_MODULE_STD)
+import std;
+#elif defined(TEST_USE_MODULE_STD_COMPAT)
+import std.compat;
+#else
+#  include <cstddef>
+#endif
 #include "test_macros.h"
 
 using PtrdiffT = ::ptrdiff_t;
 using SizeT = ::size_t;
 #if TEST_STD_VER >= 11
 using MaxAlignT = ::max_align_t;
 #endif
 
+#ifndef TEST_USE_MODULE
 // Supported in C++03 mode too for backwards compatibility with previous versions of libc++
 using NullptrT = ::nullptr_t;
+#endif
 
 // Also ensure that we provide std::nullptr_t in C++03 mode, which is an extension too.
 using StdNullptrT = std::nullptr_t;

libcxx/test/std/time/time.syn/formatter_tests.h

 #include "test_format_string.h"
 #include "test_macros.h"
 
 #include <algorithm>
 #include <cassert>
 #include <set>
 #include <string>
 #include <string_view>
+#include <iostream>
 
 #define STR(S) MAKE_STRING(CharT, S)
 #define SV(S) MAKE_STRING_VIEW(CharT, S)
 
 #ifndef TEST_HAS_NO_WIDE_CHARACTERS
 template <class CharT>
 using format_context = std::conditional_t<std::same_as<CharT, char>, std::format_context, std::wformat_context>;
 #else

libcxx/utils/libcxx/test/params.py

fallbacks = {
     'c++20': 'c++2a',
   }
   if hasCompileFlag(cfg, '-std='+std):
     return '-std='+std
   if std in fallbacks and hasCompileFlag(cfg, '-std='+fallbacks[std]):
     return '-std='+fallbacks[std]
   return None
 
+_allModules = ['none', 'clang', 'std', 'std.compat']
+def getModuleFlag(cfg, enable_modules):
+  # Originaly the flag was a Boolean, this maps the original Boolean values
+  # to the new enumerate values.
+  fallbacks = {
+    'none': 'False',
+    'clang': 'True',
+  }
+  if enable_modules in _allModules:
+    return enable_modules
+  if enable_modules in fallbacks:
+    return fallbacks[enable_modules]
+  return None
+
+
 DEFAULT_PARAMETERS = [
   Parameter(name='target_triple', type=str,
             help="The target triple to compile the test suite for. This must be "
                  "compatible with the target that the tests will be run on.",
             actions=lambda triple: filter(None, [
               AddFeature('target={}'.format(triple)),
               AddFlagIfSupported('--target={}'.format(triple)),
               AddSubstitution('%{triple}', triple)
             ])),
 
   Parameter(name='std', choices=_allStandards, type=str,
             help="The version of the standard to compile the test suite with.",
             default=lambda cfg: next(s for s in reversed(_allStandards) if getStdFlag(cfg, s)),
             actions=lambda std: [
               AddFeature(std),
               AddSubstitution('%{cxx_std}', re.sub('\+','x', std)),
               AddCompileFlag(lambda cfg: getStdFlag(cfg, std)),
             ]),
 
-  Parameter(name='enable_modules', choices=[True, False], type=bool, default=False,
-            help="Whether to build the test suite with Clang modules enabled.",
-            actions=lambda modules: [
+  Parameter(name='enable_modules', choices=_allModules + ['True', 'False'], type=str,
+            help="Whether to build the test suite with modules enabled. Select "
+                 "Clang for Clang modules and c++ for C++ Standard modules",
+            default=lambda cfg: next(s for s in _allModules if getModuleFlag(cfg, s)),
+            actions=lambda enable_modules: [
               AddFeature('modules-build'),
               AddCompileFlag('-fmodules'),
               AddCompileFlag('-fcxx-modules'), # AppleClang disregards -fmodules entirely when compiling C++. This enables modules for C++.
-            ] if modules else []),
+            ] if enable_modules == "clang" or enable_modules == "True" else [
+              AddFeature('use_module_std'),
+              AddCompileFlag('-DTEST_USE_MODULE'),
+              AddCompileFlag('-DTEST_USE_MODULE_STD'),
+              AddCompileFlag(lambda cfg: '-fprebuilt-module-path=' + os.path.join(cfg.test_exec_root, '__config_module__/CMakeFiles/std.dir')),
+              AddLinkFlag(lambda cfg: os.path.join(cfg.test_exec_root, '__config_module__/libstd.a')),
+              AddModule(),
+            ] if enable_modules == "std" else [
+              AddFeature('use_module_std.compat'),
+              AddCompileFlag('-DTEST_USE_MODULE'),
+              AddCompileFlag("-DTEST_USE_MODULE_STD_COMPAT"),
+              AddCompileFlag(lambda cfg: '-fprebuilt-module-path=' + os.path.join(cfg.test_exec_root, '__config_module__/CMakeFiles/std.compat.dir')),
+              AddLinkFlag(lambda cfg: os.path.join(cfg.test_exec_root, '__config_module__/libstd.compat.a')),
+              AddLinkFlag(lambda cfg: os.path.join(cfg.test_exec_root, '__config_module__/libstd.a')),
+              AddModule(),
+            ] if enable_modules == "std.compat" else []),
 
   Parameter(name='enable_modules_lsv', choices=[True, False], type=bool, default=False,
           help="Whether to enable Local Submodule Visibility in the Modules build.",
           actions=lambda lsv: [
             AddCompileFlag('-Xclang -fmodules-local-submodule-visibility'),
           ] if lsv else []),
 
   Parameter(name='enable_exceptions', choices=[True, False], type=bool, default=True,

libcxx/utils/use_modules_in_test.py

+#!/usr/bin/env python
+# ===------------------------------------------------------------------------------===##
+#
+# Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+# See https://llvm.org/LICENSE.txt for license information.
+# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+#
+# ===------------------------------------------------------------------------------===##
+
+# This script converts a regular test to a test using modules.
+#
+# Note this script is mainly used to test the patch https://reviews.llvm.org/D144994
+# It has not been decided that libc++ will use this approach for modules. Therefore
+# the transformation uses a simple algorithm and generates not the prettiest output.
+#
+# The main goal is to quickly convert a batch of tests to the use modules to test
+# whether the std module works for the headers that have been converted. The
+# script can't be executed twice on the same header, so it's intended this
+# script is executed on a not-yet converted code base.
+#
+# Usage
+#   use_modules_in_test.py <file>
+#
+# If the file contains at least one of the headers that is available in the std module
+# it will add a guarded import statement. All headers that are in the module std will
+# be included conditionally.
+
+import re
+import sys
+from dataclasses import dataclass, field
+
+
+HEADERS_MODULE_STD = [
+    "algorithm",
+    "any",
+    "array",
+    "atomic",
+    "barrier",
+    "bit",
+    "bitset",
+    "cctype",
+    "cfenv",
+    "charconv",
+    "chrono",
+    "cinttypes",
+    "climits",
+    "clocale",
+    "cmath",
+    "codecvt",
+    "compare",
+    "complex",
+    "concepts",
+    "coroutines",
+    "csetjmp",
+    "csignal",
+    "cstdarg",
+    "cstddef",
+    "cstdio",
+    "cstdlib",
+    "cstlib",
+    "cstring",
+    "ctime",
+    "ctype.h",
+    "cuchar",
+    "cwchar",
+    "cwctype",
+    "deque",
+    "exception",
+    "execution",
+    "expected",
+    "fenv.h",
+    "filesystem",
+    "flat_map",
+    "flat_set",
+    "float.h",
+    "format",
+    "forward_list",
+    "fstream",
+    "functional",
+    "generator",
+    "initializer_list",
+    "inttypes.h",
+    "iomanip",
+    "ios",
+    "iostream",
+    "istream",
+    "iterator",
+    "latch",
+    "limits",
+    "list",
+    "locale",
+    "locale.h",
+    "map",
+    "math.h",
+    "mdspan",
+    "memory",
+    "memory_resource",
+    "mutex",
+    "new",
+    "numbers",
+    "numeric",
+    "optional",
+    "ostream",
+    "print",
+    "queue",
+    "random",
+    "ranges",
+    "ratio",
+    "regex",
+    "scoped_allocator",
+    "semaphore",
+    "set",
+    "setjmp.h",
+    "shared_mutex",
+    "signal.h",
+    "source_location",
+    "span",
+    "spanstream",
+    "sstream",
+    "stack",
+    "stacktrace",
+    "stdarg.h",
+    "stddef.h",
+    "stdexcept",
+    "stdfloat",
+    "stdint.h",
+    "stdio.h",
+    "stdlib.h",
+    "stop_token",
+    "streambuf",
+    "string",
+    "string.h",
+    "string_view",
+    "strstream",
+    "syncstream",
+    "system_error",
+    "thread",
+    "time.h",
+    "tuple",
+    "type_traits",
+    "typeindex",
+    "typeinfo",
+    "uchar.h",
+    "unordered_map",
+    "unordered_set",
+    "utility",
+    "valarray",
+    "variant",
+    "vector",
+    "wchar.h",
+    "wctype.h",
+]
+
+# Tests that need to be marked as XFAIL for various reasons
+#
+# For example is_literal type has been removed from C++20, the tests reenables it using
+# test specific compile flags. This is not supported by modules.
+UNSUPPORTED_TESTS = [
+    "libcxx/test/std/utilities/meta/meta.unary/meta.unary.prop/is_literal_type.pass.cpp",
+]
+# Due to a Clang limitation the import needs to be after all includes.
+# Therefore non-system includes are parsed too.
+INCLUDE_REGEX = re.compile(r"^\s*#\s*include\s*[\"<](?P<include>[^\">]+)[\">]")
+
+# Ignore tests that issue deprecation warnings.
+#
+# An alternative would be just to remove this option, this would be possible
+# when the script is only used to convert in the CI.
+DISABLE_DEPRECATION_WARNINGS_REGEX = re.compile(
+    r"//\s*ADDITIONAL_COMPILE_FLAGS:.*-D_LIBCPP_DISABLE_DEPRECATION_WARNINGS"
+)
+
+
+# Marks a test as unsupported.
+#
+# Since the script runs on a not yet converted set of tests the script does not
+# test existing markers. In the future it should look at:
+# - tests with (XFAIL|UNSUPPORTED) use_module_std(|.compat)
+# - tests with an import statement
+def is_unsupported(filename: str) -> bool:
+    file = open(filename)
+    lines = file.readlines()
+    file.close()
+
+    for index, line in enumerate(lines):
+        if DISABLE_DEPRECATION_WARNINGS_REGEX.search(line):
+            lines.insert(
+                index + 1, "// UNSUPPORTED: use_module_std, use_module_std.compat\n"
+            )
+
+            file = open(filename, "w")
+            for line in lines:
+                file.write(line)
+
+            return True
+    return False
+
+
+@dataclass
+class Include:
+    line: int = -1
+    is_system_header: bool = False
+
+
+def gather_includes(lines: list[str]) -> list[Include]:
+    result = list()
+    for index, line in enumerate(lines):
+        if m := INCLUDE_REGEX.match(line):
+            result.append(Include(index, m.group("include") in HEADERS_MODULE_STD))
+    return result
+
+
+def insert_imports(lines: list[str], includes: list[Include]) -> None:
+    assert len(lines)
+    assert len(includes)
+
+    # The imports are always added after the last header
+    # Note this fails when a test has an #include in the middle of the file
+
+    line = includes[-1].line + 1
+
+    imports = list()
+    lines.insert(
+        line,
+        """
+#if defined(TEST_USE_MODULE_STD)
+import std;
+#elif defined(TEST_USE_MODULE_STD_COMPAT)
+import std.compat;
+#endif
+""",
+    )
+
+
+def make_modularized_headers_conditionally(
+    lines: list[str], includes: list[Include]
+) -> None:
+    assert len(lines)
+    assert len(includes)
+
+    inside = False
+    # Iterate backwards so the line numbers of the includes remain stable.
+    for include in reversed(includes):
+        if include.is_system_header:
+            if not inside:
+                lines.insert(include.line + 1, "#endif // TEST_USE_MODULE\n")
+                inside = True
+        else:
+            if inside:
+                lines.insert(include.line + 1, "#ifdef TEST_USE_MODULE\n")
+                inside = False
+
+    # Add the ifdef for the first entry if needed.
+    if inside:
+        for include in includes:
+            if include.is_system_header:
+                lines.insert(include.line, "#ifdef TEST_USE_MODULE\n")
+                return
+        assert False
+
+
+def process_supported(filename: str) -> None:
+    import_written = False
+
+    file = open(filename)
+    lines = file.readlines()
+    file.close()
+    includes = gather_includes(lines)
+    # for include in includes:
+    #    print(f"{include.is_system_header} {include.line:4}: {lines[include.line]}")
+    if len(includes) == 0:
+        return
+
+    # TODO Once Clang works properly with includes after imports this import can be
+    # at the top of the file.
+    insert_imports(lines, includes)
+    # for line in lines:
+    #    print(line)
+
+    make_modularized_headers_conditionally(lines, includes)
+    # for line in lines:
+    #    print(line)
+
+    file = open(filename, "w")
+    for line in lines:
+        file.write(line)
+
+
+def process(filename: str) -> None:
+    if not is_unsupported(filename):
+        process_supported(filename)
+
+
+if __name__ == "__main__":
+    if len(sys.argv) == 2:
+        process(sys.argv[1])