[PATCH] D48285: [analyzer]{UninitializedObjectChecker] Added "NotesAsWarnings" flag

Umann Kristóf via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Jun 19 01:27:13 PDT 2018


Szelethus added a comment.

In https://reviews.llvm.org/D48285#1135480, @xazax.hun wrote:

> I wonder if this could be done when plist is emitted generally, independent of any checks.


Well, there's `-analyzer-config notes-as-events=true`. By the time plist files are generated, every warning is just regarded as an event (as far as I know).



================
Comment at: lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp:696
 void ento::registerUninitializedObjectChecker(CheckerManager &Mgr) {
   auto Chk = Mgr.registerChecker<UninitializedObjectChecker>();
   Chk->IsPedantic = Mgr.getAnalyzerOptions().getBooleanOption(
----------------
NoQ wrote:
> george.karpenkov wrote:
> > registerChecker passes through arguments to the constructor. Could we use that instead of mutable fields?
> Really? Yay. I never noticed that. I think currently all checkers that need options use mutable fields for that purpose, and everybody thought it was intended to work this way.
> 
> I'm not super worried about fields being mutable because all checker callbacks are `const` (so you're still protected from mutating them in all of your code), but that'd definitely make the code look better.
Well, I didn't really find that to be the case. Even if it was, `getBooleanOption(StringRef, /*DefaultVal*/ bool, const ento::CheckerBase *);` depends on the constructed checker, so I don't think I can pull this off.

There actually is a way to get boolean options without having to pass the checker as an argument, but then it wouldn't be a checker specific option:
`-analyzer-config Pedantic=true`
instead of
`-analyzer-config alpha.cplusplus.UninitializedObject:Pedantic=true`.


https://reviews.llvm.org/D48285





More information about the cfe-commits mailing list