[PATCH] D120465: [clang][deps] Disable implicit module maps

Duncan P. N. Exon Smith via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Mar 10 16:07:47 PST 2022


dexonsmith added inline comments.


================
Comment at: clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp:269-273
+  // However, some module maps loaded implicitly during the dependency scan can
+  // describe anti-dependencies. That happens when the current module is marked
+  // as '[no_undeclared_includes]', doesn't 'use' module from such module map,
+  // but tries to import it anyway. We need to tell the explicit build about
+  // such module map for it to have the same semantics as the implicit build.
----------------
jansvoboda11 wrote:
> dexonsmith wrote:
> > Is there another long-term solution to this that could be pointed at with a FIXME? E.g., could the module map be encoded redundantly here? If so, what else would need to change to make that okay?
> I'm not sure I understand why this would warrant "long-term solution" or a FIXME. This code handles an existing feature that just happens to be a corner case from the dependency scanning point of view. (You can read up on the feature [[ https://clang.llvm.org/docs/Modules.html | here ]].)
> 
> What do you mean by encoding the module map redundantly?
Yes, I know the feature.

... but I was probably wrong about how it affects the logic here.

I also now have two guesses at the scenario being handled here (previously I assumed (1)):

1. A textual include from a module that is not marked as used. I wasn't sure what you meant by "tries to import", but I guess I thought it was just "loads the module map and finds the textual header listed there". IIUC, there's no actual attempt to import a module when the only thing referenced from it is a textual header, but I could see how parsing the module mapĀ could affect the state anyway.

2. A modular include from a module that is not marked as used. Something like a `__has_include`, or a `#include` that fails but there's another search path with the same header. In this case, there'd be an actual import attempt, which would fail. And that could also affect state.

Can you clarify which scenario you need to handle? Or is it a 3rd?

> I'm not sure I understand why this would warrant "long-term solution" or a FIXME.

This smells like a workaround to me. IIUC, sending in module maps that aren't actually "needed" except to reproduce side effects of failed queries.

My intuition is that the right long-term fix would involve isolate the failed queries from the compiler state in the scanning phase so that they don't have side effects. Then there would be no side effects to reproduce in the explicit build.

> What do you mean by encoding the module map redundantly?

I think I was confused about scanning vs building, thinking that a module using a textual include (1) could be copied into each module PCM that directly imports it. (I know that this wouldn't scale right now for various reasons, but I wondered if there was some way to get there... but regardless, seems like it's totally unrelated)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120465/new/

https://reviews.llvm.org/D120465



More information about the cfe-commits mailing list