We want to trust user type annotations and stop assuming pointers declared
as _Nonnull still can be null. This functionality is implemented as part
of NullabilityChecker as it tracks non-null types already. It could
be easily implemented as a part of NSError checker, but it would look like
a simple "shut up" plug as opposed to a more generic solution.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Hi everyone!
I'm thinking about adding support for __attribute((nonnull))__ as well, but it should be handled a bit differently. That annotation is for parameters and not for types, so the corresponding constraints should be generated only when entering the function (as opposed to each load). I'm not sure that it should be a part of this commit though because it will have a completely standalone solution. Another question about __attribute((nonnull))__ is "Where should we put it?". It is quite reasonable to put it into NullabilityChecker, but NonnullParamChecker seems like a good candidate as well.
NonnullParamChecker
Yup, looks like that's actually the one that deals with __attribute__((nonnull)), as opposed to _Nonnull.
clang/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp | ||
---|---|---|
521 | ||
527 | ([[ https://reviews.llvm.org/D33672?id=171506#inline-475812 | this auto is good ]]) | |
537 | Ok, so we're continuing normally if the value is already known to have been assigned to null. We could sink the analysis instead but presumably it's not our job as another checker must have warned before we get there (let's comment about this maybe). |
clang/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp | ||
---|---|---|
521 | Yup, this one should be const auto *. |
Wait, we don't already assume nonnull attributed parameters as, well, not null? That's crazy.
Yep, I was shocked by it as well. Maybe for some warnings it is checked in the end and they are truncated before reporting. However, DereferenceChecker definitely dispatches ImplicitNullDerefEvent for params marked with __attribute__((nonnull)).
That's only for the top frame. For nested stack frames we're not only assuming they're not null, we're also emitting a warning when they're null. But, yeah, it's clearly an unfortunate omission.
clang/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp | ||
---|---|---|
536 | That's still too much auto. |
[[ https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable | Too much auto ]]!