There are various checks implemented for condition expression in for loop. I thought that we could have similar in while and do..while loops. Curious what you think.
Details
Diff Detail
- Repository
- rC Clang
Event Timeline
Cool, this conceptually makes a lot of sense to me! That said, I'm not a competent reviewer in this area anymore, @klimek can you recommend someone?
Sorry for the delay of fixing failed builds. Full builds and tests take some time. I'm working on it, promise.
The code itself won't change much, so I think it can be reviewed. Or at least the idea can be judged if it's something desired to have in clang. @lattner or @klimek could you please recommend someone to ask for review?
I think clang-format is yelling at places where formatting should not be applied, so I'm gonna ignore that.
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.
void Run() { bool Wait = true; Execute(&Wait); while (Wait) { // Do some waiting } }
To lower the false positive rate, I tried to add a bool to Decl's to track if they are possible referenced from other places. To do that, Sema needs to be changed to track that bit. Unfortunately, the Sema change was not accepted, so without a way to lower the false positive rate, I abandoned the warning.
Links to old discussions on mailing lists:
Patch to add warning to while loops
https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20120604/058677.html
Patch to add reference bit to Decl
https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20121112/068241.html
There's a few ways forward if you want to keep working on this warning.
- Run your version of the warning over a large codebase to get more recent data on true versus false positives. If the numbers have changed since last time, it makes for a greater argument to have this warning.
- Find another method to reduce the false positive rate, specifically, examples as listed above.
- Instead of making it a warning, implement it in static analysis as mentioned in the review of the original patch
Thank you for such a detailed comment. Makes sense. I need to think how to proceed. Will ping you when I figure something out.
Please sink this variable down to the point where we've decided we're going to emit a diagnostic, and switch from PDiag to Diag.