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

[Ian Anderson via libcxx-commits]

ian-twilightcoder 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.

Yes the current setup is pretty crummy. It's not only the public headers that have their own top level modules, but all of the implementation headers too. We've explored paring that down and can get it under 200 algorithmically, but Louis is looking at doing it by hand and fixing some unnecessary dependencies along the way.

> 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.)

That is an interesting idea. Yeah Apple doesn't have LSV on because it doesn't support Objective-C (it doesn't see ObjC categories or protocols so pretty much nothing compiles).

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