NoQ marked an inline comment as done. NoQ added a comment. In D64274#1586282 <https://reviews.llvm.org/D64274#1586282>, @Szelethus wrote:
> //Ackchyually//, it doesn't per se break anything, but will result in > CodeChecker no longer enabling `optin.cplusplus.VirtualCall` :^) Sorry, > oversight on my end. Observe the following monster of a clang invocation... Mmm. Aha. Ok, i can reproduce your problem, but i don't think reversing the dependencies is gonna work. If we make the pure checker depend on the optin checker, we would always have the opt-in checker registered first, and therefore there's no way to figure out if we really wanted to opt in into the optin checker or we are simply loading it as a dependency. Which, in particular, makes it impossible to discriminate between `-analyzer-checker cplusplus.PureVirtualCall` and `-analyzer-checker optin.cplusplus.VirtualCall` when the option is unset: in both cases we'll first register the opt-in checker and then the pure checker. I'm confused though; the way i was previously understanding your work, when disabling a dependency and then enabling a dependent checker *later* in the run-line, it should re-enable the dependency automatically. Did you consciously decide not to implement it that way? ================ Comment at: clang/include/clang/StaticAnalyzer/Checkers/Checkers.td:569 "false", - Released> + InAlpha> ]>, ---------------- Szelethus wrote: > Lets hide it as well. > > ``` > CmdLineOption<Boolean, > "PureOnly", > "Disables the checker. Keeps cplusplus.PureVirtualCall " > "enabled. This option is only provided for backwards " > "compatibility.", > "false", > InAlpha, > Hide> > ``` Yup! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64274/new/ https://reviews.llvm.org/D64274 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits