This is an archive of the discontinued LLVM Phabricator instance.

Fix "modular" import when we find the header in the current directory
AbandonedPublic

Authored by gribozavr on Dec 10 2013, 12:37 PM.

Details

Summary

When searching for a header, Clang will first try to look in the current directory. But if we find the header in this case, we don't set 'SuggestedModule', so the header is included in non-modular way, even if module.map has an entry for it. Fixing this issue fixes module tests for -fmodules-decluse, and test/Modules/submodules.cpp.

test/Modules/submodules.cpp already had a FIXME that this patch fixes.

-fmodules-decluse tests had dormant errors that this patch uncovers and fixes. Specifically, XC and XD #included "b.h", but did not specify the use dependency in module.map.

Please review.

Diff Detail

Event Timeline

@chapuni: This patch will probably also have the same effect as r196859, which was reverted. I don't have a Windows machine and I am not sure how to fix the failing test (Misc/remap-file.c) -- http://bb.pgr.jp/builders/cmake-clang-i686-mingw32/builds/6254/steps/test-clang/logs/Clang%20%3A%3A%20Misc__remap-file.c

Makes sense to me, thanks. Please go ahead once the Windows issue is
resolved.

@chapuni: As a different option, are you OK with XFAIL'ing this test on Windows for now? This test is for file remapping functionality, which is used in libclang. But in libclang it is used with memory buffers, not with real files, so I don't think the actual use case will break on Windows.

These aren't dormant errors in the module.map of the declare-use tests, it is intended design. We only want to display these warnings if the corresponding modules are actively built. This is quite important. As a user, you might otherwise get a lot of warnings that you can't fix (as they are in somebody else's module). However, you still want to be enable this check for your own module. We could also check indirect modules guarded on an additional -fmodules-indirect-check flag, but I personally think that this is unnecessary complexity.

Interestingly, I can't from the patch tell why it would now find these extra errors. verifyModuleInclude still tests that the RequestingModule is the current SourceModule. I'll take a close look tomorrow.

Ok. The "problem" is that the -fmodules-decluse creates an error on the transitive build steps when actually building XC and XD, which the modules under test depend on.

I have temporarily circumvented this in r197021 by letting the declare-use tests only checks modules without actively building them (and their transitive dependencies). So you should now be able to commit this without changing the test/Modules/Inputs/declare-use/module.map.

I think that we'll probably want to disable layering checks for the build steps of the transitively used modules. Any thoughts on this?

What's the state of this?

gribozavr abandoned this revision.Jul 28 2014, 4:35 AM