jansvoboda11 wrote:
I was looking at the affecting module map logic for a reason unrelated to
yours, but ended up needing something similar to what you're trying to achieve.
Here's an example:
```
//--- X1.modulemap
module X1 { header "X1.h" }
//--- X2.modulemap
module X2 { header "X2.h" }
//--- A.modulemap
module A { header "A.h" }
//--- B.modulemap
module B { header "B.h" }
//--- X1.h
#include "A.h"
#include "B.h"
//--- X2.h
#include "B.h"
#include "A.h"
//--- A.h
#include "B.h"
//--- B.h
```
Intuitively, I would expect the set of affecting files between modules X1 and
X2 to be the same (at least when it comes to files related to modules A and B).
Assuming implicit module maps, the problem is as follows:
* In module X1:
* The first include in X1.h reads A.modulemap and creates local SLocEntry.
* A.pcm is loaded and `Module::DefinitionLoc` is re-associated with the
loaded SLocEntry for A.modulemap.
* The second include in X2.h reads B.modulemap and creates local SLocEntry.
* B.pcm is loaded and `Module::DefinitionLoc` is re-associated with the
loaded SLocEntry for B.modulemap.
* When computing the set of affecting input files, we start out assuming all
files tied to local SLocEntries are affecting, so both A.modulemap and
B.modulemap are candidates at the start.
* Then we say only module map files that are not in the set derived from
`Module::DefinitionLoc` are non-affecting.
* Both A.modulemap and B.modulemap are in the set, so both end up being
affecting.
* In module X2:
* The first include in X2.h reads B.modulemap and creates local SLocEntry.
* B.pcm is loaded and `Module::DefinitionLoc` is re-associated with the
loaded SLocEntry for B.modulemap.
* A.pcm is transitively loaded and `ModuleDefinitionLoc` is associated with
the loaded SLocEntry for A.modulemap.
* The second include in X2.h doesn't read any module map file, since all
necessary information is known thanks to A.pcm.
* When computing the set of affecting input files, the initial set only
contains B.modulemap (because it's associated with the local SLocEntry), but
not A.modulemap (because it's only associated with the loaded SLocEntry).
* B.modulemap is in the set derived from `Module::DefinitionLoc` so it ends
up being affecting.
This is unexpected and I think it breaks the correctness of clang-scan-deps. I
think we might need to take your patch a bit further and make it so that
`ASTWriter::WriteInputFiles()` doesn't care whether the SLocEntry associated
with the file through `Module::DefinitionLoc` is loaded or local.
https://github.com/llvm/llvm-project/pull/112015
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
