Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Great job on the patch! Thanks!
clang/lib/StaticAnalyzer/Core/LoopUnrolling.cpp | ||
---|---|---|
165–198 | One thought here. | |
184–185 | But actually, it's a bit different with this one. I don't know exact details and rules how clang sema fills in the class for lambda.
It can be pretty much specified in clang, that's true, but it looks like in DeadStoreChecker we have a very similar situation and we do not assume that captured variable always have a corresponding field. | |
187–190 | There is a general rule in LLVM's style guide of trying to minimize nestedness of if's, forms and so on. | |
201–202 | I think that this comment has to be updated now. | |
201–202 | I think this whole section is less obvious now and requires one good solid comment explaining what are the different situations here, what is "entry" and so on. |
By checking the line coverage of the LoopUnrolling.cpp test file, looks like all lines are covered you touched.
There are only two return statements uncovered though: L200, L251.
We should consider extending this test file to cover them as well in a follow-up patch.
clang/lib/StaticAnalyzer/Core/LoopUnrolling.cpp | ||
---|---|---|
184–185 | Yes, I based this on the fact that DeadStoreChecker considers it possible, but I have never faced a case where it does not have a corresponding field. |
Thanks for addressing my comments! I still have some left though
clang/lib/StaticAnalyzer/Core/LoopUnrolling.cpp | ||
---|---|---|
170 | dyn_cast_or_null also tells the reader that D can be null and can be not CXXMethodDecl. So it's better to use cast here if you are sure about D and have assertions about it. | |
174–177 | Body of this function seems to be too dense. It is usually hard to read something that doesn't have rest places for eyes. You can think of it as paragraphs in the written text. | |
178 | We can just do cast here | |
184–185 | I still think that we should do something about this else | |
191–192 | I think it's a great idea to list all the cases. I think we can go even further: enumerate them and actually pinpoint in the implementation where we cover which case. With numbers it can be much easier. | |
193 | Can we not introduce new terms and simply call it a reference? | |
196 | This should be also modified then |
clang/lib/StaticAnalyzer/Core/LoopUnrolling.cpp | ||
---|---|---|
184–185 | It still would be good to have some proof that it is indeed like this or simply fallback into returning true (which you already do when in doubt). |
clang/lib/StaticAnalyzer/Core/LoopUnrolling.cpp | ||
---|---|---|
184–185 | As I said, I believe it cannot happen but I assumed based on the other checker that there is something I don't know. void CXXRecordDecl::getCaptureFields( llvm::DenseMap<const VarDecl *, FieldDecl *> &Captures, FieldDecl *&ThisCapture) const { Captures.clear(); ThisCapture = nullptr; LambdaDefinitionData &Lambda = getLambdaData(); RecordDecl::field_iterator Field = field_begin(); for (const LambdaCapture *C = Lambda.Captures, *CEnd = C + Lambda.NumCaptures; C != CEnd; ++C, ++Field) { if (C->capturesThis()) ThisCapture = *Field; else if (C->capturesVariable()) Captures[C->getCapturedVar()] = *Field; } assert(Field == field_end()); } I dropped the defensive code |
I've just been patching up clang-tidy's infinite loop checker and the problem sounds soooo similar. Maybe we should move clang-tidy's alias analysis into libAnalysis and re-use it?
I'm not familiar with clang-tidy's alias analysis. Do you think it should be part of this patch? or a follow-up one?
Note: I don't have the right to re-run the failed build/test. I assume that it is not related to my change since the test compile and runs omp code(Static analyzer doesn't run on that test)
Great! Thanks for addressing all of the comments!
clang/lib/StaticAnalyzer/Core/LoopUnrolling.cpp | ||
---|---|---|
184–185 | OK, sounds reasonable! |
Thank you for the review! Can you take care of merging it? I don't have the required permission.
dyn_cast_or_null also tells the reader that D can be null and can be not CXXMethodDecl. So it's better to use cast here if you are sure about D and have assertions about it.