================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
