With this patch a nullability violation no longer generates a sink node, so it does not cause any coverage loss for other checkers.
From now on, it also do not warns, when a nullability precondition is violated. These changes are related, because in order to be able to remove the sinks (without generating duplicate reports for the same symbol), there should be a mechanism to turn off this checker for a path.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp | ||
---|---|---|
166 ↗ | (On Diff #33458) | The difference is not clear by looking at the signature; maybe you should rename the method to make it more clear what the difference is. Please, use doxygen style comments everywhere! |
228 ↗ | (On Diff #33458) | preconditions -> precondition |
371 ↗ | (On Diff #33458) | Looks like you are assuming that you cannot get to this point with OriginalState having the PreconditionViolation bit set. This seems fragile. At minimum, you should assert this, but maybe changing the checkPreconditionViolation API would be better? |
395 ↗ | (On Diff #33458) | Maybe you should only do this if there was at least one symbol with nullability info removed in the loop above? Would that work? |
430 ↗ | (On Diff #33458) | Please, spell check your comments. We are not dereferencing null.. we are dereferencing a nullable pointer.. |
565 ↗ | (On Diff #33458) | I do not understand how this works.. Does this ever report an issue? I thought this version of the bugReport will only report an issue if PreconditionViolation is not set. (Same for the code below and above..) Is this tested? |
Addressed the comments.
lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp | ||
---|---|---|
395 ↗ | (On Diff #33458) | That would not work. |
430 ↗ | (On Diff #33458) | You are right. |
565 ↗ | (On Diff #33458) | Yes, it works. The reason is that, reportBug does report bugs, when PreconditionViolated is set to true. It does not report bugs, when one of the nonnull argument is constrained to be null. PreconditionViolated is used at the beginning of some callbacks to return early. However I think this behavior might be confusing, so I refactored the code. From now on reportBugConditionally does not report any bug, when PreconditionViolated is set to true, and it does set it to true when a reported bug should suppress other bugs along the path. |
lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp | ||
---|---|---|
166 ↗ | (On Diff #33704) | It is still not clear what the condition is.. |
374 ↗ | (On Diff #33704) | Shouldn't this be part of checkPreconditionViolation? |
806 ↗ | (On Diff #33704) | Maybe we should only check these at the time the bug is about to be reported.. That way the code would be less error prone.. |
Style fixes according to the review.
lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp | ||
---|---|---|
806 ↗ | (On Diff #33704) | This is checked before error reporting as well. |