This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] Trust _Nonnull annotations, and trust analyzer knowledge about receiver nullability
ClosedPublic

Authored by george.karpenkov on May 29 2018, 6:54 PM.

Details

Summary

Previously, the checker was using the nullability of the expression, which is nonnull IFF both receiver and method are annotated as _Nonnull. However, the receiver could be known to the analyzer to be nonnull without being explicitly marked as _Nonnull.

rdar://40635584

Diff Detail

Repository
rL LLVM

Event Timeline

NoQ accepted this revision.May 30 2018, 3:22 PM

LG, i have no sensible remarks, so i made a few non-sensible remarks.

clang/lib/StaticAnalyzer/Checkers/TrustNonnullChecker.cpp
28 ↗(On Diff #149019)

We usually skip private: at the top of class because it's implied, but in this case i think it's actually justified.

77–79 ↗(On Diff #149019)

Do we want to generate a sink when L is already known to be null? Theoretically it may happen due to inlining or because another checker models the call to return null. This would not happen if the annotation was indeed correct and our checkers behave correctly. If this at all happens, currently we'll continue the analysis, because addTransition(nullptr), suddenly, doesn't generate a sink.

clang/test/Analysis/trustnonnullchecker_test.m
11–15 ↗(On Diff #149019)

Is this the actual pattern that we're explicitly trying to suppress? I.e., we declare that it's fine to check a definitely-nonnull pointer for null-ness and get no warning for that(?)

Or is the original problem more about, like, correlated if()s in which we're trying to refute a practically path?

This revision is now accepted and ready to land.May 30 2018, 3:22 PM
clang/lib/StaticAnalyzer/Checkers/TrustNonnullChecker.cpp
77–79 ↗(On Diff #149019)

I'm not sure I follow here; this checker only performs API modeling and does not report bugs, what sink should there be?

clang/test/Analysis/trustnonnullchecker_test.m
11–15 ↗(On Diff #149019)

if is here to force the analyzer to split paths; the original problem would be when if would not be direct, but the path would still be (sometimes undesirably) split

NoQ added inline comments.May 30 2018, 5:09 PM
clang/lib/StaticAnalyzer/Checkers/TrustNonnullChecker.cpp
77–79 ↗(On Diff #149019)

You can still have CheckerContext.generateSink() that makes a sink node that isn't supposed to be a node that has a bug report attached to it.

This revision was automatically updated to reflect the committed changes.