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
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
