Fix false positive in magic number checker
https://bugs.llvm.org/show_bug.cgi?id=40640: cppcoreguidelines-avoid-magic-numbers should not warn about enum class
Test case code reduced by Pavel Kryukov.
Sadly, it would seem so.
if (ValueArray[(int)4] > ValueArray) produces the following AST:
| | | | `-ArraySubscriptExpr 0x11545f0 <col:7, col:24> 'int' lvalue | | | | |-ImplicitCastExpr 0x11545d8 <col:7> 'int *' <ArrayToPointerDecay> | | | | | `-DeclRefExpr 0x1154558 <col:7> 'int ' lvalue Var 0x1153cb0 'ValueArray' 'int ' | | | | `-CStyleCastExpr 0x11545b0 <col:18, col:23> 'int' <NoOp> | | | | `-IntegerLiteral 0x1154578 <col:23> 'int' 4
While the test case we're trying to avoid is:
`-TemplateSpecializationType 0x1169ee0 'holder<(Letter)9U>' sugar holder |-TemplateArgument expr | `-ConstantExpr 0x1169dc0 <col:59> 'Letter' 9 | `-SubstNonTypeTemplateParmExpr 0x1169da0 <col:59> 'Letter' | `-CStyleCastExpr 0x1169d78 <col:59> 'Letter' <IntegralCast> | `-IntegerLiteral 0x1169d48 <col:59> 'unsigned int' 9 `-RecordType 0x1169ec0 'holder<Letter::J>' `-ClassTemplateSpecialization 0x1169de0 'holder'
Now, the question is - do we care? How many people use a C cast with a bare integer?
I suppose I can add a check for the grandparent node to be SubstNonTypeTemplateParmExpr, in order to filter this out?
An interesting fact is that the C-style cast does not produce a warning now anyway (even before applying this change.) and I don't have any idea why.
Adding these lines does not create a test failure:
+ 79 if (((int)4) > IntSquarer) + 80 return 0;
This test fails even with clang-tidy-9.
$ clang-tidy-9 --checks="-*,readability-magic-numbers" clang-tools-extra/test/clang-tidy/checkers/readability-magic-numbers-todo.cpp /home/florin/tools/llvm-project/clang-tools-extra/test/clang-tidy/checkers/readability-magic-numbers-todo.cpp:9:35: warning: 10 is a magic number; consider replacing it with a named constant [readability-magic-numbers] if (((int)4) > ProcessSomething(10)) ^
Nothing about the "4" here.
I sort of wonder whether we want to document this as a blessed approach to silencing the warning. I'm not certain if it's too obtuse or not, but I notice the check has no documented ways to silence the diagnostic aside from using the correct kind of magic number or adding it to a list of excluded magic numbers.
You mean Hyrum's Law is not sufficient?
The check can be silenced with the regular NOLINT, or with defining and using a constant/enum. Using this "backdoor" way seems even more cumbersome and confusing than the NOLINT. At least with NOLINT it is clear what you're doing, and somebody else can grep for it and fix it if it is appropriate.
My concern is that NOLINT is insufficient. Consider: foo(12, 42, 18); where the 42 is not desired to be warned about due to domain-specific knowledge but the 12 and 18 are.
However, I am not convinced that you're wrong either -- casting is cumbersome. But it's also a somewhat well-used workaround to silence warnings (casting to void silencing unused value warnings being a common example).
For right now, we can leave it as a bug -- we can decide to bless the approach later.
LGTM aside from some minor nits.
You might as well move this onto the previous line; it just looks strange here.
prove -> Prove
and add a full stop to the end of the comment.