sam-mccall wrote: > I updated the description of this PR, hopefully it makes more sense now. I > still need to investigate what goes wrong in > "Modules/preprocess-decluse.cpp". It seems that it assumes `%t/b.pcm` embeds > the information from "a.modulemap".
I think it should embed that information. The high-level idea here is: the PCM should describe the source of the modulemaps that are relevant to build it. In this test, that means that b.pcm should have a slocentry for a.modulemap, because that map was relevant in allowing b.h to include a.h. (If a.pcm existed, then it would encode a's module map and we'd use that instead. But as it only has textual headers, we don't build a PCM). The problem is `HFI->isTextualModuleHeader && !HFI->isCompilingModuleHeader` is true for `a.h` when building B: it's from a different module, but being built as part of this one. We don't have a way to represent this I think: it used to be effectively "HFI exists, it's not a modular header, assume we're parsing it" but now we're creating the HFI in non-parsing cases. I can imagine we could change the semantics of `isCompilingModuleHeader` for textual headers to be true if the header is being included within a TU for the compiling module, rather than included in the modulemap. https://github.com/llvm/llvm-project/pull/89441 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
