Skip to content
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

Open
llvmbot opened this issue Feb 8, 2017 · 8 comments
Labels
bugzilla Issues migrated from bugzilla clang:modules C++20 modules and Clang Header Modules

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Feb 8, 2017

Bugzilla Link 31905
Version trunk
OS Windows NT
Attachments full reproducer.
Reporter LLVM Bugzilla Contributor
CC @adrian-prantl,@bcardosolopes,@dexonsmith,@DougGregor,@zygoloid,@silvasean,@vgvassilev

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:

  1. A project "my_project" which provides a module map for its headers.

  2. The system has an installation of "my_project" in "/usr/local/include/my_project".

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

@silvasean
Copy link
Contributor

This may be due to the special case logic in ModuleMap::findKnownHeader w.r.t. builtin includes?

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 8, 2017

@​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 :-)

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 8, 2017

drop-in clang test case.
I've attached a test-case written for Clang's test suite. So anybody who wants to try and fix this doesn't need to write the test themselves.

@bcardosolopes
Copy link
Member

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?

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 11, 2017

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

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 13, 2017

drop-in clang test case v2
Add an improved drop in clang test case.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Oct 22, 2018

As others have pointed out, this has nothing to do with stddef.h specifically.
It's a general problem.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Oct 22, 2018

reproducer without stddef.h
Here is a new reproducer that doesn't depend on any system headers.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla clang:modules C++20 modules and Clang Header Modules
Projects
None yet
Development

No branches or pull requests

3 participants