| Issue |
144609
|
| Summary |
Clang Module Cache performs no include path check
|
| Labels |
clang
|
| Assignees |
|
| Reporter |
Steelskin
|
In the attached reproducer case, I have 2 small libraries, called `libv1` and `libv2`. Each of them contain a single header called `header.h` containing a single define `LIB_VALUE`, which expands to either 1 or 2 depending on the library.
There is another library, `includer`, which is made of a single header, `includer.h`. All it does is include `header.h`.
These use module maps defined in `lib.modulemap` and `includer.modulemap` respectively. 2 Overlay files are used to use either the `libv1` or `libv2` library. Finally `main.cc` does nothing but output the content of the `LIB_VALUE` macro it get from `includer.h`.
In the build script, we build `main.cc` with modules enabled, first with `libv1`, then `libv2`, using the same module cache. This results in 2 binaries that both output `1`.
We then build using a new module cache, this time first building `main.cc` with `libv2`, then `libv1`. This results in 2 binaries that both output `2`.
The problem seems to come from the fact that Clang does not perform any path check when loading a module from the cache. This is particularly problematic for Swift on Windows, which relies on module maps to parse the Windows SDK headers. These are versioned in different sub-directories but use the same module map file, resulting in compilation failures when parts of the SDK are already present in the module cache but for another Windows SDK version.
[repro.tar.gz](https://github.com/user-attachments/files/20784554/repro.tar.gz)
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
