================
@@ -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
----------------
Snape3058 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.
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.
I am not familiar with the use case of the `_Generic` keyword. However, IMO, it
is more like an actual initialization in a polymorphic macro, rather than a
workaround to suppress a warning.
For the `struct S` above, the two `x` are different `Decl`s. They can be
distinguished by the filter, even if checked. Besides, even if there were a
self-init in the initializer list, i.e.,
```
struct S {
int x;
S() : x(x) {}
};
```
as not initializing `S::x` will not trigger a frontend warning, I don't think
developer will introduce an intended self-init here.
In a word, the decision-making question I ask myself is "will people elaborate
themselves to suppress an unused-var warning in that way under such a code
context?".
https://github.com/llvm/llvm-project/pull/187530
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
