[clang] [C++20] [Modules] Introduce a tool 'clang-named-modules-querier' and two plugins 'ClangGetUsedFilesFromModulesPlugin' and 'ClangGetDeclsInModulesPlugin' (PR #72956)

Chuanqi Xu via cfe-commits cfe-commits at lists.llvm.org
Mon Mar 11 18:54:13 PDT 2024


ChuanqiXu9 wrote:

> > ClangGetUsedFilesFromModulesPlugin
> 
> This has a hole where if a currently-unused file is not listed, but it is changed in such a way that it now matters (e.g., it changes include order, adds/removes includes, etc.), we need to recompile consumers.
> 
> > what happens if someone adds an overload, or other interesting name resolution to the module?
> 
> We would need to do (at least) one of:
> 
> * track considered-but-discarded decls (e.g., if something SFINAE'd away now matters because of a new decl);
> * track "new" decls since the last compile (not sure how the state tracking works here though) and recompile if any show up
> 
> > ```
> >      "col": 12,
> >      "kind": "Function",
> >      "line": 3,
> > ```
> 
> So we change the decl hash if a comment adds a line? That seems like low-hanging fruit to me. Can we enumerate decls and use an index instead? That depends on preprocessor state though, so may be hard to externally verify…

Why I chose to use the location is that in the discourse discussion, it shows the location is still meaningful in debug information in generated objects. And for index..., I feel it is hard to tell the meaning of the index outside the compiler. As you said, how can a consumer be sure that 2 decls with the same index in 2 different invocations to be the same one...

https://github.com/llvm/llvm-project/pull/72956


More information about the cfe-commits mailing list