Snape3058 wrote: > > Have you explored teaching the relevant checker to not raise the issues? > > I'm surprised that we need to change the engine to achieve this. > > @steakhal I'm not totally opposed to handling this in the checker(s), but if > this is indeed an established idiom, then I think that this single change in > the engine is a better approach than suppressing this in the relevant > checker(s)... and later adding more suppressions if it turns out that this > affects other checkers as well.
My previous idea is also to suppress this warning in the checker. We have discussed this in #173210, and @haoNoQ suggested this. TL, DR: since this idiom is interpreted as nop in the assembly generated by GCC, the analyzer is expected to do nothing for such a DeclStmt. But adjusting the CFG seems misleading, so we adjust the engine directly. After finishing the first version, the failure in stack-addr-ps.cpp (refer to the comments in my test) reminds me that this is not an idiom in C++ and, for reference types, such usage must be reported. So the patch finally became like this. Actually, GCC will not generate assembly for C++ code either (https://godbolt.org/z/Yoso4MMWM), which behaves as if the statement is removed. However, in this patch, the assignment is only skipped for C code, but reserved for C++ code. I don't know whether and to what extent we should be aligned with the behavior of the compiler. If we align with the Clang-generated assembly, suppressing the warning in the checker but reserving the assignment seems to be better, as Clang does generate assembly for such an idiom in both C and C++. If we align with the frontend warnings, I think that I should also allow non-reference and non-compond types for C++ code, as the self-assignment initializations for integer-kind variables in C++ are not warned (the godblot example above). Anyway, I am now kind of unsatisfied with my current version and want more suggestions for it. https://github.com/llvm/llvm-project/pull/187530 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
