This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] Fix dead store checker false positive
ClosedPublic

Authored by vsavchenko on Mar 24 2021, 6:53 AM.

Details

Summary

It is common to zero-initialize not only scalar variables,
but also structs. This is also defensive programming and
we shouldn't complain about that.

rdar://34122265

Diff Detail

Event Timeline

vsavchenko created this revision.Mar 24 2021, 6:53 AM
vsavchenko requested review of this revision.Mar 24 2021, 6:53 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 24 2021, 6:53 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

I see your point.

Would it report this issue?

int test() {
  struct Foo foo = {0, 0}; // I would expect a warning here, that 'foo' was initialized but never read.
  (void)foo;
 return 0;
}

Only nits besides this.

clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
25

I don't see any new code that would depend on this header.

422–427

Eh, the indentation looks horrible.
It would be probably better to use braces here.

I see your point.

Would it report this issue?

int test() {
  struct Foo foo = {0, 0}; // I would expect a warning here, that 'foo' was initialized but never read.
  (void)foo;
 return 0;
}

Only nits besides this.

We got one big fat complaint about that, and I can see the point.

clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
25

llvm::all_of?

422–427

Yeah, I agree. I'm not sure braces will help much. I will try to do smith about it

I see your point.

Would it report this issue?

int test() {
  struct Foo foo = {0, 0}; // I would expect a warning here, that 'foo' was initialized but never read.
  (void)foo;
 return 0;
}

Only nits besides this.

We got one big fat complaint about that, and I can see the point.

We should at least document it as testcase.

clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
25

Oh sure!

Add comments

Add another test

vsavchenko marked an inline comment as done.Mar 30 2021, 6:03 AM
martong added inline comments.Mar 30 2021, 7:05 AM
clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
422–423

What about nested InitListExpr's?

std::array<int, 3> a1{ {1, 2, 3} };
VarDecl 0x561b200333a0 </home/egbomrt/tmp/aaa.cc:2:1, col:34> col:20 a1 'std::array<int, 3>':'std::array<int, 3>' listinit
`-InitListExpr 0x561b20036d78 <col:22, col:34> 'std::array<int, 3>':'std::array<int, 3>'
  `-InitListExpr 0x561b20036dc0 <col:24, col:32> 'typename _AT_Type::_Type':'int [3]'
    |-IntegerLiteral 0x561b20033408 <col:25> 'int' 1
    |-IntegerLiteral 0x561b20033428 <col:28> 'int' 2
    `-IntegerLiteral 0x561b20033448 <col:31> 'int' 3
vsavchenko added inline comments.Apr 6 2021, 11:13 AM
clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
422–423

I'm not sure that we'll report anything on that

NoQ accepted this revision.Apr 6 2021, 2:39 PM

Looks great and I'm also curious about nested initializers.

clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
422–423

We probably won't because it's a C++ object, even though it's an aggregate so we should probably warn(?) What about a plain C object like

int x[2][2] = { { 0, 0 }, { 0, 0 } };

?

This revision is now accepted and ready to land.Apr 6 2021, 2:39 PM
vsavchenko added inline comments.Apr 7 2021, 6:05 AM
clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
422–423

The same here, we still don't warn about stores like this, but I think I can add test with nested structs

steakhal accepted this revision.Apr 7 2021, 6:14 AM

Looks good. Thank you.

clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
422–423

Should we add a C++ test case as well?

Looks good. Thank you.

I guess it will do for PODs, but for regular C++ types we have an early exit until we learn about side effects from constructors.

vsavchenko updated this revision to Diff 335795.Apr 7 2021, 6:23 AM

Support nested init lists

NoQ accepted this revision.Apr 7 2021, 10:51 AM
This revision was landed with ongoing or failed builds.Apr 8 2021, 6:20 AM
This revision was automatically updated to reflect the committed changes.

Support nested init lists

Thanks for addressing the nested lists! (And sorry for the late reply, I was on vacation)

Support nested init lists

Thanks for addressing the nested lists! (And sorry for the late reply, I was on vacation)

Hey, thanks for taking your time and reviewing it!