I'm involved with the Static Analyzer for the most part.
I think we should embrace newer language standard features and gradually move forward.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
There remained a few more cases using raw-for loops, but those were slightly more tricky to uplift as they either use weird iterators or employ some fancy look-ahead/behind or iterate in parallel over different sequences etc.
I'll also make a measurement to confirm it doesn't change any reports.
The transformations were done by hand. So I'd encourage you all to have a look and find places where it breaks. Also, it might have personal biases about the style I settled with. Feel free to challenge.
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CoreEngine.h | ||
---|---|---|
501 | Is this just a dummy to make sure this satisfies some concepts? I think I comment might be helpful in that case, people might find a noop dereference operator confusing. Same for some other places. | |
clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h | ||
749–750 | Do we need these with the addition of referenced_vars? | |
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h | ||
637–638 | Should we remove these? | |
clang/lib/StaticAnalyzer/Checkers/MallocSizeofChecker.cpp | ||
194–195 | ||
clang/lib/StaticAnalyzer/Core/AnalysisManager.cpp | ||
54 | Hm, I wonder whether we actually want to use unique_ptrs to make the ownership explicit. Feel free to leave as is in this PR. | |
clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp | ||
173–177 | Might be an issue with Phab, but indent looks strange to me here. | |
clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp | ||
1190 | Ha about using capture_inits? |
I don't have concrete remarks, but I would like to note that I'm happy to see this cleanup :)
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CoreEngine.h | ||
---|---|---|
501 | Yes. I'll add a comment. | |
clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h | ||
749–750 | I no longer remember where, but yes. But for sure I went through these to see if I could remove them. | |
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h | ||
637–638 | I'm pretty sure we need these somewhere. | |
clang/lib/StaticAnalyzer/Checkers/MallocSizeofChecker.cpp | ||
194–195 | Makes sense. | |
clang/lib/StaticAnalyzer/Core/AnalysisManager.cpp | ||
54 | The ownership model of these consumers is so messed up. | |
clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp | ||
173–177 | Thanks for catching this. Indeed. I'll have a look. Probably I messed something up. | |
clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp | ||
1190 | I would count this as a "fancy" iteration as we increment/advance more logical sequences together. |
Fixed remarks, cleaned up residual includes, rebased.
Should be read to land.
Final thoughts?
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CoreEngine.h | ||
---|---|---|
501 | Added comments to both places. | |
clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h | ||
749–750 | Now I remember. | |
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h | ||
637–638 | This was just an oversight. Removed. Thanks! | |
clang/lib/StaticAnalyzer/Checkers/TrustNonnullChecker.cpp | ||
72 | Oh, I didn't know this is a word :D | |
clang/lib/StaticAnalyzer/Core/Environment.cpp | ||
29 | Removed this extra include. | |
clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp | ||
173–177 | Clang-format went crazy, and I'm using clang-format on save, thus messed this up. | |
clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp | ||
1190 | I had a better idea and llvm::zip all these together. |
I love it, I think we can land this as is. If there are further comments, we can address those in follow-up PRs.
clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp | ||
---|---|---|
1190 | Nice! |
clang/lib/StaticAnalyzer/Core/AnalysisManager.cpp | ||
---|---|---|
54 | Fixed by https://reviews.llvm.org/D154478 |
Is this just a dummy to make sure this satisfies some concepts? I think I comment might be helpful in that case, people might find a noop dereference operator confusing. Same for some other places.