================
@@ -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.
>
> 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 };`
`int c (c);` has the same AST structure as `int c = c;`, so it is currently
handled.
`int c {c};` is different, so perhaps we can also add this, as `int c (c);` has
already been handled.
`int c = {c};` has the same AST structure as `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).
OK. But I actually don't get the point of this test. We are checking the AST
rather than the literal text of the code. There seems to be no chance that we
get them mixed up.
https://github.com/llvm/llvm-project/pull/187530
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
