For Plist consumers that don't support notes just yet, this flag can be used to convert them into warnings. For now, I defaulted it to false.
Details
- Reviewers
NoQ george.karpenkov xazax.hun rnkovacs whisperity - Commits
- rG9bd44390b4e3: [analyzer][UninitializedObjectChecker] Added a NotesAsWarnings flag
rL335964: [analyzer][UninitializedObjectChecker] Added a NotesAsWarnings flag
rC335964: [analyzer][UninitializedObjectChecker] Added a NotesAsWarnings flag
Diff Detail
- Repository
- rC Clang
Event Timeline
LGTM provided the nit on passing arguments is fixed.
lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp | ||
---|---|---|
698 | registerChecker passes through arguments to the constructor. Could we use that instead of mutable fields? |
I wonder if this could be done when plist is emitted generally, independent of any checks.
lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp | ||
---|---|---|
698 | 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. |
Also, great, and can i has tests?^^
Like a simple code snippet with two // RUN: ... -analyzer-output=text lines and different expected-warnings/notes under #ifs.
I intended to, but forgot git add. Whoops. I didn't find a satisfying way to add it to the existing tests without surrounding the entire file with #if, so I added a new test file instead.
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).
lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp | ||
---|---|---|
698 | 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: |
Looks great, thanks!
lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp | ||
---|---|---|
698 | Yeah, well, i guess if you just use this as the last argument of getBooleanOption(), you'll still have CheckName unset during construction. A slight refactoring might help, but it doesn't currently work "out of the box". |
registerChecker passes through arguments to the constructor. Could we use that instead of mutable fields?