dblaikie added a comment. This is a bit out of left field, but these comments reminded me of something - a long time ago I was working on fixing some Clang layering to potentially use explicit modules more in our internal build (& then hopefully in the upstream/external build) and one major holdup was the layering of diagnostics - essentially it's somewhat circular that each clang library owns its diagnostics, but libBasic depends on all those lists of diagnostics. Yeah, we could just move the diagnostic files down into libBasic, but the layering is problematic and it'd be great to fix it.
The idea, which I never got around to implementing, was that perhaps each library could have its own diagnostic lists, and the diagnostic library/engine itself would have no hardcoded knowledge of them - different tools, using different subsets of libraries, would have to initialize the diagnostic engine with all the diagnostic groups that cover the libraries they were going to use/they were going to pass the diagnostics engine to. That would fix the layering and lower the overhead of using diagnostics in tools that only need a small subset of the libraries and diagnostics clang uses. Would that be relevant to address thhe concerns here? Would anyone with a vested interest in this review be interested in pursuing that direction? I'd be happy to help/throw around ideas, etc. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90121/new/ https://reviews.llvm.org/D90121 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
