This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] SuspiciousEnumUsageCheck bugfix
ClosedPublic

Authored by szepet on Sep 7 2017, 8:12 AM.

Details

Summary

There is a reported bug on the checker not handling the some APSInt values correctly: https://bugs.llvm.org/show_bug.cgi?id=34400

This patch fixes it, however, it shows a false positive. (Added to the test cases)
I am not sure if it's a checker or AST problem. The AST dump shows the following:

-BinaryOperator 0x1195b98 <col:38, col:43> 'int' '|'
 |-ImplicitCastExpr 0x1195b68 <col:38> 'int' <IntegralCast>
 | `-DeclRefExpr 0x1195b18 <col:38> 'enum j<struct c<int, 0, 0, 0, 0, 0> >::(anonymous at dude.cpp:15:3)' EnumConstant 0x1193b98 'ah' 'enum a<struct f<struct c<int, 0, 0, 0, 0, 0>, struct c<int, 0, -1, 0, 0, -1>, 0> >::(anonymous at dude.cpp:29:3)'
 `-ImplicitCastExpr 0x1195b80 <col:43> 'int' <IntegralCast>
   `-DeclRefExpr 0x1195b40 <col:43> 'enum j<struct c<int, 0, -1, 0, 0, -1> >::(anonymous at dude.cpp:15:3)' EnumConstant 0x1195ad0 'ai' 'enum a<struct f<struct c<int, 0, 0, 0, 0, 0>, struct c<int, 0, -1, 0, 0, -1>, 0> >::(anonymous at dude.cpp:29:3)'

I am not sure if this is right since this belongs to the following code snippet (maybe I am just missing something):

enum { ah = ad::m, ai = ae::m, l = ah | ai };

What do you think?

Diff Detail

Repository
rL LLVM

Event Timeline

szepet created this revision.Sep 7 2017, 8:12 AM
aaron.ballman added inline comments.Sep 8 2017, 7:46 AM
clang-tidy/misc/SuspiciousEnumUsageCheck.cpp
46 ↗(On Diff #114180)

I would test for < 0 rather than a direct equality test (compare functions generally follow the C idioms).

61–62 ↗(On Diff #114180)

Same here, though I would also get rid of the local variables and just perform the comparison in the return statement.

test/clang-tidy/misc-suspicious-enum-usage.cpp
1 ↗(On Diff #114180)

I thought we built in C++11 mode by default these days?

122 ↗(On Diff #114180)

This seems like a lot of complicated code for the test case -- can this be reduced further?

alexfh accepted this revision.Sep 8 2017, 8:37 AM

LG modulo comments. Thank you for the fix!

test/clang-tidy/misc-suspicious-enum-usage.cpp
1 ↗(On Diff #114180)

I'm not sure, but if we actually do, we could later remove -std=c++11 from the test script and all tests.

92 ↗(On Diff #114180)

I'd suggest enclosing the test case in a namespace PR34400 {} for clarity and to avoid possible name conflicts.

122 ↗(On Diff #114180)

This is the best creduce could do. It should be possible to make this much shorter, but I wouldn't spend too much time on that.

This revision is now accepted and ready to land.Sep 8 2017, 8:37 AM
aaron.ballman added inline comments.Sep 8 2017, 8:45 AM
test/clang-tidy/misc-suspicious-enum-usage.cpp
122 ↗(On Diff #114180)

I'd appreciate the time spent because this is an almost-unintelligible test for anyone reading it -- it's hard to understand what's going on there.

alexfh added inline comments.Sep 8 2017, 10:39 AM
test/clang-tidy/misc-suspicious-enum-usage.cpp
122 ↗(On Diff #114180)

namespace PR34400 {

enum { E1 = 0 };
enum { E2 = -1 };

enum { l = E1 | E2 };

}

alexfh added inline comments.Sep 8 2017, 10:44 AM
test/clang-tidy/misc-suspicious-enum-usage.cpp
122 ↗(On Diff #114180)

This might not cover both code paths affected by the bug. But it should be easy to construct a case for the second one.

aaron.ballman added inline comments.Sep 8 2017, 1:24 PM
test/clang-tidy/misc-suspicious-enum-usage.cpp
122 ↗(On Diff #114180)

It's certainly an easier case to grok, thank you! :-D

szepet updated this revision to Diff 114567.Sep 11 2017, 4:31 AM
szepet marked 3 inline comments as done.

Updates based on the comments. Thanks for the reduced test case and the fast review!

Not sure if in these cases am I allowed to commit (since it was accepted) or since it was accepted a lot of comments ago I should wait for another response?

alexfh accepted this revision.Sep 11 2017, 6:50 AM

Still LG. Fine to commit.

Thanks for the fix!

If you find time to construct the test case that triggers both affected code paths (my test seems to only inspect one of them, IIUC), it would be nice to do as a follow up.

This revision was automatically updated to reflect the committed changes.