[clang] [analyzer] Ignoring `T v=v; ` idiom for uninitialized variable checker and dead store checker (PR #187530)
Aaron Ballman via cfe-commits
cfe-commits at lists.llvm.org
Wed Jul 1 04:25:00 PDT 2026
================
@@ -0,0 +1,65 @@
+// RUN: %clang_analyze_cc1 %s -verify -xc \
+// RUN: -analyzer-checker=core,debug.ExprInspection,deadcode.DeadStores
+
+// Suppress the C++ -Wuninitialized warnings on struct and reference.
+// RUN: %clang_analyze_cc1 %s -verify -xc++ -Wno-uninitialized \
+// RUN: -analyzer-checker=core,debug.ExprInspection,deadcode.DeadStores
+
+// Self assignment initialization in C code will be treated as nop.
+// We will report the VarDecl only if it was left uninitialized by the time of
+// a subsequent DeclRefExpr.
+
+// NOTE: No warnings from the deadcode.DeadStores checker.
+
+void clang_analyzer_warnIfReached();
+
+struct S { int x; };
+union U { int x; };
+enum T { TT };
+
+// No need to test VarDecl of multiple variables, as they will be split into
+// single ones when constructing the CFG.
+
+int warnvar() {
+ int x = x; // no-warnings for C/C++, binding is skipped via the
----------------
AaronBallman wrote:
> The reasons are similar to the T v = (v); suggestion above. Therefore, I am open to int x{x}; and int x(x);, although I don't think C++ developers will suppress an unused-var warning in this way.
Oh that's right, this is suppressed for C code rather than C++. Huh, I suppose the question there is whether we handle `int c = { c };`
> For the other two, IMO, people just want to suppress the frontend warnings on unused variables. It seems very unlikely for a developer to do that in such ways; at least I will not do that.
Yeah, I thought about this a bit more over night and I don't think it's worth supporting those cases until we have use cases justifying it.
> For the struct S above, the two x are different Decls. They can be distinguished by the filter, even if checked.
I'm aware -- the goal is to ensure we don't regress the behavior in the future (we don't ever want a self-init warn on this case despite it looking somewhat self-init-like at first glance).
https://github.com/llvm/llvm-project/pull/187530
More information about the cfe-commits
mailing list