[all-commits] [llvm/llvm-project] c7afb3: [analyzer] Invalidate the object in opaque ctor ca...

[Balázs Benics via All-commits]

  Branch: refs/heads/release/22.x
  Home:   https://github.com/llvm/llvm-project
  Commit: c7afb3647b373dff122c6948d0a96de3cbaac309
      https://github.com/llvm/llvm-project/commit/c7afb3647b373dff122c6948d0a96de3cbaac309
  Author: Balázs Benics <benicsbalazs at gmail.com>
  Date:   2026-01-15 (Thu, 15 Jan 2026)

  Changed paths:
    M clang/lib/StaticAnalyzer/Core/CallEvent.cpp
    M clang/test/Analysis/call-invalidation.cpp

  Log Message:
  -----------
  [analyzer] Invalidate the object in opaque ctor calls regardless if an arg refers to it (#170887)

The conservative call invalidation logic is a bit complicated, and would
deserve some refactoring.

When a call has some arguments, we escape them. Except, if its a pointer
to constant storage - because we assume that the program honors
const-correctness.

In that case, it puts it in the "Preserved" list to keep its contents.
However, if we had a constructor call that's job is to initialize an
object had a const pointer/reference parameter then the invalidation
didn't take place.

This meant that if the object was on the stack, that we start warning
about uninitialized fields when accessed. (See the example) Similar
could be achieved on the heap of course.

We should have honored the fact that the constructor should initialize
the pointee of "this", thus escape that region regardless (in other
words, don't put it on the "preserved" list).

This doesn't fix the root cause, but cures a symptom.
Ideally, we should redesign the argument invalidation from the ground up.
See the attached FIXME test case.

rdar://156942972
(cherry picked from commit efa32e36323e0c92b33c34aea61009026c164686)



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications