[libcxx-commits] [libcxx] [libcxx] Fix libcxx config to be non-textual. (PR #130723)

via libcxx-commits libcxx-commits at lists.llvm.org
Mon Mar 10 23:05:56 PDT 2025


https://github.com/matts1 updated https://github.com/llvm/llvm-project/pull/130723

>From 7be95240ba34b050e3182b2d5a2cea25e008117e Mon Sep 17 00:00:00 2001
From: Matt Stark <msta at google.com>
Date: Tue, 11 Mar 2025 16:18:19 +1100
Subject: [PATCH] [libcxx] Fix libcxx config to be non-textual.

When building libcxx as a module, it fails to build because it's missing various definitions.

Consider the following code for module A:
```
#include <module B that includes config_site>
#include <config>
#include <module C that includes config>
```

With the module map file:
```
module std {
   module A { header "a.h" }
   module B { header "b.h" }
   module C { header "c.h" }
}
```

Macro visibility rules state that "[macros] are visible if they are from the current submodule or translation unit, or if they were exported from a submodule that has been imported."
* Module A has visibility of all macros exported by modules B and C (because they were exported from an imported submodule)
* Module B and C have visibility over all macros exported by module A (because they are from the current submodule)

1) When we #include the first line, module B successfully includes config_site.

Module B exports: config_site contents, config_site header guard

2) Module A now `includes <config>` directly

Because it can see module B's exports, it stops at the header guard for config_site and does not include config_site. This is not an issue, however, because it has visibility onto everything exported from config_site thanks to module B.

Module A exports: config  contents, config header guard, config's includes' content and header guard (*except config_site*)

3) Module C now includes config. Based on the above visibility rules, it can see everything exported from module A.

Because of that, we see the header guard for config and do not import it at all. This is mostly OK, as we can see the config that module A exported. However, if we ever try and access config_site, it will fail, as A did not export config_site.
---
 libcxx/include/module.modulemap | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/libcxx/include/module.modulemap b/libcxx/include/module.modulemap
index b9964dac84acd..b719f6d69273d 100644
--- a/libcxx/include/module.modulemap
+++ b/libcxx/include/module.modulemap
@@ -1,13 +1,14 @@
 // This module contains headers related to the configuration of the library. These headers
 // are free of any dependency on the rest of libc++.
 module std_config [system] {
-  textual header "__config"
-  textual header "__configuration/abi.h"
-  textual header "__configuration/availability.h"
-  textual header "__configuration/compiler.h"
-  textual header "__configuration/language.h"
-  textual header "__configuration/platform.h"
-  textual header "version"
+  header "__config"
+  header "__configuration/abi.h"
+  header "__configuration/availability.h"
+  header "__configuration/compiler.h"
+  header "__configuration/language.h"
+  header "__configuration/platform.h"
+  header "version"
+  export *
 }
 
 module std_core [system] {



More information about the libcxx-commits mailing list