[PATCH] D123352: [analyzer] Add FixItHint to `nullability.NullReturnedFromNonnull` and `nullability.NullableReturnedFromNonnull`
Moshe via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Apr 8 10:39:36 PDT 2022
MosheBerman added a comment.
In D123352#3439390 <https://reviews.llvm.org/D123352#3439390>, @steakhal wrote:
> tldr; static-analyzer fixits are not completely implemented.
Where can I learn more about this? Would it be possible and idiomatically/architecturally sounds to write a clang-tidy that processes output from this checker?
> When I passed the `apply-fixits`, it modified the input source file - as I expected.
Did you test this diff, or an existing checker? Would you please share the command you used to test?
> Then I tried the `-analyzer-output=text` and suddenly it inserted the fixit 2 times xD, which is less than ideal and we should fix this.
> And I'm expecting many more bugs with this feature.
This is why it's gated. xD.
> There is a `clang/test/Analysis/check-analyzer-fixit.py` script which could be invoked by a RUN line like this:
> // RUN: %check-analyzer-fixit %s %t -analyzer-checker=core
> At least, the comment of that script says so.
> I'm quite skeptical about inserting such fixits in general - regarding path-sensitive analysis.
> For fixits, we should be confident that some property holds, but the static analyzer might conclude erroneously that a given pointer is null resulting in a **bad** fixit.
> Thus, relying on this might be dangerous.
Understood, and I don't disagree (both because of lack of expertise, and because false-positives is a logical concern.) The intention here is to enable us to add `NS_ASSUME` macros to a bunch of files, then use the nullability return checkers to catch the functions/methods which violate the new contract. This assumes that the existing code is the source of truth, as opposed to, say, callsites.
> You can read more about false-positive cases regarding null pointers in the `clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.def`, namely `suppress-null-return-paths`, `avoid-suppressing-null-argument-paths`, `suppress-inlined-defensive-checks`. These options were introduced for mitigating such false-positive null pointer deref reports.
I'll take a look at that, thanks! Would those suppressions interact with the nullability checkers? They seem to have a lot of defenses against false positives.
> Let me invite @Szelethus for his expertise in the null pointer checker.
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
More information about the cfe-commits