[all-commits] [llvm/llvm-project] 6ab01d: [analyzer] Nullability: Enable analysis of non-inl...

NoQ via All-commits all-commits at lists.llvm.org
Mon Dec 12 14:19:40 PST 2022


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 6ab01d4a5cbd46f521de89b167571c0754e6c557
      https://github.com/llvm/llvm-project/commit/6ab01d4a5cbd46f521de89b167571c0754e6c557
  Author: Paul Pelzl <ppelzl at apple.com>
  Date:   2022-12-12 (Mon, 12 Dec 2022)

  Changed paths:
    M clang/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp
    M clang/test/Analysis/nullability.mm

  Log Message:
  -----------
  [analyzer] Nullability: Enable analysis of non-inlined nullable objc properties.

The NullabilityChecker has a very early policy decision that non-inlined
property accesses will be inferred as returning nonnull, despite nullability
annotations to the contrary. This decision eliminates false positives related
to very common code patterns that look like this:

if (foo.prop) {
    [bar doStuffWithNonnull:foo.prop];
}

While this probably represents a correct nil-check, the analyzer can't
determine correctness without gaining visibility into the property
implementation.

Unfortunately, inferring nullable properties as nonnull comes at the cost of
significantly reduced code coverage. My goal here is to enable detection of
many property-related nullability violations without a large increase
in false positives.

The approach is to introduce a heuristic: after accessing the value of
a property, if the analyzer at any time proves that the property value is
nonnull (which would happen in particular due to a nil-check conditional),
then subsequent property accesses on that code path will be *inferred*
as nonnull. This captures the pattern described above, which I believe
to be the dominant source of false positives in real code.

https://reviews.llvm.org/D131655




More information about the All-commits mailing list