User Details
- User Since
- Jul 11 2012, 7:44 PM (558 w, 1 d)
Jan 13 2023
Dec 27 2022
Dec 21 2022
Dec 15 2022
Nov 1 2022
Oct 27 2022
I noticed some build failures after your commit. I'm trying to get a standalone reproducer.
Oct 11 2022
Sep 22 2022
Sep 9 2022
Do you have a test case for this?
Aug 17 2022
Aug 16 2022
This patch has been moving back and forth between IsIntegerLiteralConstantExpr and getIntegerLiteralSubexpressionValue. The first function is preexisting and the second one is a new function. The final patch seems to settle on using just getIntegerLiteralSubexpressionValue. Can you explain why the existing function does not meet your needs? It wasn't clear from the update messages why you went that way.
Aug 10 2022
I think this is a reasonable step for improving compile times. I put some suggestions for more descriptive names below (he said, after suggesting those names in the first place).
Aug 4 2022
void foo(long x) { if ((x & 1) == 1L) return; // bad always false warning here static_assert(sizeof(int) < sizeof(long), "long is bigger than int"); static_assert((long(15) & 1) == 1L, "proof that condition can be true"); }
I found this false positive case when testing your new patch. The condition is fine, but it gives an always false warning. When fixed, this would be another good test case to include.
Aug 3 2022
Can you add my earlier test case or something like it to SemaCXX/warn-bitwise-compare.cpp ?
Aug 2 2022
Not being able to detect when expressions are dependent inside template instantiations has been a pain for warnings since forever.
I believe that evaluating the expression would make this warning too broad and would need more testing that what was included here. Only handling UnaryOperator with IntegerLiteral sub-expression makes more sense for the warning, and adding in any new cases if we find them.
I agree that the warning is too broad right now and that's unintentional. However, manually handling every single case in the CFG as something special is fragile and what got us this bug in the first place. We have a constant expression evaluator (two, actually) and we shouldn't have to reimplement it a third time in the CFG. However, asking a GSoC mentee to address that is well beyond the scope of what they should be working on. So for now I'm going to revert this change, reopen the issue, and we'll discuss the next steps off-list with Usman.
Aug 1 2022
This warning is now flagging some code which I believe is a false positive. In particular, when template arguments are involved, their values can be calculated during template instantiation, but they should be treated as variables instead of constants. For example:
Jul 29 2022
Jul 26 2022
Jul 25 2022
Jun 1 2022
I wrote the original for loop warning. I did try to extend it to while loops, but due to the different usage of these types of loops, there was a higher false positive rate for while loops that in for loops. For loops are generally self-contained, so checking only the loop and loop body is a good way to determine if the condition is changed. However, while loops are also used in things like multi-threaded code and the while loop is used as a wait.
May 3 2022
May 2 2022
Apr 18 2022
This seems to be acting weird in template instantations. Here's an example where the lambda only errors inside a template.
Feb 11 2022
Feb 10 2022
Jan 28 2022
Jan 14 2022
Dec 1 2021
Nov 23 2021
This was causing some issues in tests.
I've reverted this in 1150f02c77b81adca4d0c67afdef23321e93db89
and sent @dvyukov details to reproduce the problem I saw.
Sep 2 2021
Aug 31 2021
It looks like a strict improvement on printing and most callers using the default args won't need to be updated.
Aug 17 2021
Aug 16 2021
Jun 9 2021
Thanks for the quick fix. I've verified that it fixes my full test case.
Jun 8 2021
I ran across a llvm_unreachable that points to this commit. Repro instructions below:
Apr 27 2021
Apr 6 2021
Aug 12 2020
LGTM
Aug 10 2020
LGTM
Aug 6 2020
I looked back on the commits and while I did commit, I did it on the behalf of Anders Rönnholm, who did not have commit access at the time. I haven't seen activity from Anders in a while, but added to subscribers just in case.
LGTM
Jun 19 2020
May 7 2020
May 6 2020
Apr 27 2020
Mar 31 2020
Jan 30 2020
Jan 24 2020
Jan 23 2020
I'm in favor of splitting the warning into subgroups, then deciding which ones should be in -Wall. We've done this with other warnings such as the conversion warnings and tautological compare warnings, with only a subset of them in -Wall.
Jan 21 2020
Jan 14 2020
Heads up in case it affects you refactoring work:
While looking through this code, I found a bug I previously made. I fixed it with a small change, but that lies in the middle of your refactoring during FieldDecl handling. The change is here:
Jan 10 2020
Jan 9 2020
Jan 8 2020
Dec 16 2019
Dec 13 2019
Nov 15 2019
Nov 12 2019
Nov 7 2019
Add -Wall tests to check that certain warning groups are active with it and a test to check all warning groups that are turned on by -Wall.
Nov 6 2019
The recommited patch is hitting an assert. See message and reduced test case below: