New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[modules] Duplicate modulemaps found when the compiler looks for unrelated headers. #31253
Comments
This may be due to the special case logic in ModuleMap::findKnownHeader w.r.t. builtin includes? |
@Sean Almost certainly. I believe the re-definition error is emitted when trying to find a module map for the module _Builtin_stddef_max_align_t. Is anybody interested in working on this? I've tried with no luck (because I don't know enough about clang). I would love to start installing the LLVM modulemaps soon :-) |
drop-in clang test case. |
Eric, given your description it seems that this would also happen with other system headers as well; as long as some project has a header with the same name. Did you happen to verify that too? |
No it seems to be specific to stddef and likely _Builtin_stddef_max_align_t (Which is given special behavion in Module::directlyUses). It doesn't reproduce with stdint.h, stdarg.h, float.h. (And many other examples enumerated under ModuleMap::isBuiltinHeader). |
drop-in clang test case v2 |
As others have pointed out, this has nothing to do with |
reproducer without stddef.h |
Extended Description
Currently including "stddef.h" or other builtin headers when modules is enabled causes Clang to find
module.modulemap
files along the wrong search paths. For example, given the following configuration:A project "my_project" which provides a module map for its headers.
The system has an installation of "my_project" in "/usr/local/include/my_project".
A user has a local development copy of "my_project" that they are trying to compile.
While compiling the local copy both the in-tree and system installed module.modulemap are along the header include paths, however the local copy has precedence and that's the module.modulemap Clang initially selects.
However after Clang processes a
#include "stddef.h"
it will end up processing/usr/local/include/my_project/module.modulemap
. This causes module re-definition compile errors.This bug is currently preventing LLVM from installing it's module maps, because this bug will be hit when re-compiling LLVM.
The text was updated successfully, but these errors were encountered: