matts1 wrote: > I'm not a modules or matcher expert, but this doesn't match my (perhaps > uninformed) understanding. I thought that when we import a module, it _is_ > part of our TU, similarly to when we include a header.
You are correct. I phrased it very poorly. I'll reclarify - if we have a header file we depend on, then if the header file came from a different module, it would have already been checked when we compiled that module, so there's no need to recheck it. > I thought what we wanted to do was avoid walking the parts of the AST that > come from a module but aren't used in the TU, and therefore haven't been > deserialized. Consider: ```c // module.cpp #include "module.h" ``` ```c // lib.cpp #include "lib.h" #include "module.h" ``` To compile `lib`, we perform something along the lines of: ```sh clang++ -emit-module -o module.pcm -add-plugin raw-ptr-plugin module.cpp clang++ -emit-module -o lib.pcm -add-plugin raw-ptr-plugin lib.cpp -fmodule-file module.pcm ``` The raw plugin will check `module.cpp` and `module.h` in the first action. Thus, there is no need to bother checking `module.h` when compiling `lib`, because it is in a different module. We could only check parts of `module.h` that we depend on, but that still seems to be redundant. https://github.com/llvm/llvm-project/pull/127423 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
