Details
- Reviewers
xazax.hun george.karpenkov NoQ rnkovacs - Commits
- rG8c1190982638: [analyzer][UninitializedObjectChecker] Fixed captured lambda variable name
rL336995: [analyzer][UninitializedObjectChecker] Fixed captured lambda variable name
rC336995: [analyzer][UninitializedObjectChecker] Fixed captured lambda variable name
Diff Detail
Event Timeline
Looks good overall, but some nits inline.
lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp | ||
---|---|---|
683 | Can we have a comment explaining the semantics? From my understanding, you find a corresponding capture using a source location, and get a name from there. | |
686 | CXXParent is guaranteed to be non-null at this stage, otherwise dyn_cast fails | |
688 | Could we just use a for-each here? Sorry for being opinionated, I'm pretty sure it would be both shorter and more readable. | |
690 | That's exactly the semantics of the equality operator on source locations, so why not Field->getLocation() == L.getLocation() ? |
Thanks for the review!
I spend some time thinking about the support for lambda functions, and I start to think that checking for lambda misuse shouldn't be the responsibility of this checker. I created a new revision for that discussion, I wouldn't like to abandon this one until I heard what you think of this! :)
D48318
edit: I was wrong on this one, sorry about that, so please just ignore it. I'll update this diff tomorrow.
lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp | ||
---|---|---|
688 | Great idea! :) I completely agree, to be honest I scratched my head too while I wrote it down. |
lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp | ||
---|---|---|
686 | I found this on http://llvm.org/docs/ProgrammersManual.html#the-isa-cast-and-dyn-cast-templates:
So I guess this should be alright. |
lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp | ||
---|---|---|
686 | Oops sorry my bad. |
lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp | ||
---|---|---|
691 | Uhm, this source location comparison looks really flaky. Ideally we would have looked up by field and get the captured variable directly, but it seems that we don't have a ready-made method for this. The second ideal thing would probably be a reverse variant of CXXRecordDecl::getCaptureFields(). Looking at how it's implemented, it seems that capture indix is in sync with field index. Because we have FieldDecl::getFieldIndex(), probably we could just lookup the captures array by that index? |
Few more nits.
lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp | ||
---|---|---|
683 | Is this a member method? Then it should be prefixed with a class name. | |
684 | Doxygen-style comments in LLVM start with a triple slash, and are located above the function. Then the tools for autocompletion (e.g. clangd) can pick them up. |
lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp | ||
---|---|---|
683 | It is a statically defined method, and you can see its forward declaration in the same diff. Back when I started writing this checker, the amount of function laying in the anonymous namespace was very few, but this has changed. I'll fix it sometime because it's getting somewhat annoying (and is against the coding standards). |
Looks good!
lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp | ||
---|---|---|
683 | Yeah, just make them static, it's easier to read (https://llvm.org/docs/CodingStandards.html#anonymous-namespaces). |
Can we have a comment explaining the semantics? From my understanding, you find a corresponding capture using a source location, and get a name from there.