[PATCH] D123352: [analyzer] Add FixItHint to `nullability.NullReturnedFromNonnull` and `nullability.NullableReturnedFromNonnull`

[Moshe via Phabricator via cfe-commits]

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.

Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123352/new/

https://reviews.llvm.org/D123352