LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 31905 - [modules] Duplicate modulemaps found when the compiler looks for unrelated headers.
Summary: [modules] Duplicate modulemaps found when the compiler looks for unrelated he...
Status: NEW
Alias: None
Product: clang
Classification: Unclassified
Component: Modules (show other bugs)
Version: trunk
Hardware: PC Windows NT
: P normal
Assignee: Unassigned Clang Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-08 15:46 PST by Eric Fiselier
Modified: 2018-10-22 09:33 PDT (History)
9 users (show)

See Also:
Fixed By Commit(s):


Attachments
full reproducer. (710 bytes, application/x-gzip)
2017-02-08 15:46 PST, Eric Fiselier
Details
drop-in clang test case. (1.82 KB, patch)
2017-03-08 15:29 PST, Eric Fiselier
Details
drop-in clang test case v2 (1.17 KB, patch)
2017-04-12 18:56 PDT, Eric Fiselier
Details
reproducer without stddef.h (2.52 KB, patch)
2018-10-22 09:33 PDT, Eric Fiselier
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Fiselier 2017-02-08 15:46:33 PST
Created attachment 17951 [details]
full reproducer.

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.
Comment 1 Sean Silva 2017-02-08 18:58:28 PST
This may be due to the special case logic in ModuleMap::findKnownHeader w.r.t. builtin includes?
Comment 2 Eric Fiselier 2017-03-08 14:55:33 PST
@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 :-)
Comment 3 Eric Fiselier 2017-03-08 15:29:17 PST
Created attachment 18067 [details]
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.
Comment 4 Bruno Cardoso Lopes 2017-03-09 10:04:49 PST
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?
Comment 5 Eric Fiselier 2017-03-11 04:26:13 PST
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).
Comment 6 Eric Fiselier 2017-04-12 18:56:03 PDT
Created attachment 18281 [details]
drop-in clang test case v2

Add an improved drop in clang test case.
Comment 7 Eric Fiselier 2018-10-22 09:32:01 PDT
As others have pointed out, this has nothing to do with `stddef.h` specifically.
It's a general problem.
Comment 8 Eric Fiselier 2018-10-22 09:33:00 PDT
Created attachment 21025 [details]
reproducer without stddef.h

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