ArcsinX wrote: > > The issue is that ParsedAST::build has a non-trivial amount of code > > building a ClangTidy context for identifying and processing ClangTidy > > diagnostics, which is not accessible in a feature module. > > Would it make sense to move all of clang-tidy into a feature module? And make > the ClangTidy context an implementation detail of that Then you could add the > "suppress diagnostic" as part of that clang-tidy feature module. Since you > would be inside that module, you would have access to the module-private > ClangTidy context. > > (That being said, I know next to nothing about feature modules, and hence > don't know how much work that refactoring would be or if it's even doable)
Personally, I think this is a great idea. And maybe the reason it wasn't done this way initially is because feature modules were introduced after clang-tidy had already been integrated into clangd. I don't have time to do this by myself right now, but if someone wants to implement it, I'll be happy to review it. The implementation can be based on the use of `FeatureModule::ASTListener::beforeExecute()` to replace AST consumer in `CompilerInstance` with `MultiplexConsumer` which will contain both: current AST consumer and clang-tidy AST consumer. https://github.com/llvm/llvm-project/pull/188796 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
