You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
0 commit comments