[libcxx-commits] [libcxx] [libc++] First attempt to regroup a few modules in the modulemap (PR #98214)

[Richard Smith via libcxx-commits]

zygoloid wrote:

> There's just no good way to deal with `#include_next` in modules other than every such header has to be its own module.

For what it's worth, what we do in Google's modules deployment is to have a layer of wrapper headers that sits between the application code and the base system (libc, libc++, etc), and we build a module for that layer of wrapper headers (and *nothing* below it). That works great for us. So there are other options here :)

> Modules aren't a good solution to a size deficiency in PCH, it sounds like that just needs to be fixed.

This isn't just a size issue. Various things in Clang scale linearly in the number of PCM files loaded. The C++ standard library currently has over 120 public headers (including both `<cFOO>` and `<FOO.h>` headers) so having separate top-level modules (and therefore separate PCM files) for each is likely to have a significant impact on performance.

Perhaps something that would be interesting to explore would be putting multiple top-level modules in the same PCM file. While splitting a single top-level module across PCM files has some issues, I don't think there's any real problems (other than some hardcoded assumptions and the default behavior of various PCM search mechanisms) with putting multiple modules in the same PCM file.

If the base system's module map could declare that the `std` module should be built as part of building the base system, and included in the same PCM file, then that could address the issues here, and we could simply allow cycles in that case. (Though for that to really work well you also want to turn on local submodule visibility, which IIRC the Apple base system hasn't done yet.)

https://github.com/llvm/llvm-project/pull/98214