baloghadamsoftware marked an inline comment as done. baloghadamsoftware added inline comments.
================ Comment at: clang/lib/StaticAnalyzer/Core/Store.cpp:472 + break; + } + ---------------- baloghadamsoftware wrote: > Probably this loop could be written better, without `break` at the end, but > for now it des what it should do. For captured parameters of functions and > blocks we must look for the original `CallExpr` and `LocationContext`. If it > does not exist (we analyze the block of the lambda top-level) we revert to > `VarRegion` since the captured parameters are simple variales for the block > or lambda. However, we cannot do this if the block or lambda is not analyzed > top-level, thus the approach I use above seems to be the correct one. > However, this completely breaks the test `objc-radar17039661.m`. Even order > of the `postCall()` hooks is changed and the test fails because it cannot > find the bug. I try to attach the two different outputs annotated by debug > printouts. @NoQ, do you have an idea what could be wrong here? First I > thought on `BlockDataRegion`s where it seems I have to duplicate lots of code > and also change the capture interface to also enable `ParamRegions` for the > captures. However, in this case it does not seem to play a role. The really strange thing is that I originally used a recoursive approach here, instead of the loop, which I still believe is the right one. However, in that case the test failed even if I removed all creations of `ParamRegion`s. The only difference then was that the `LocationContext` of the captured region was the top-level `LocationContext`. This alone changed the calling order of the checker hooks and this happens here as well. It is not the `VarRegion` vs `ParamRegion` problem but the `LocationContext` of the region. I still do not see why this influences the calling order of these hooks. I am already debugging it for almost 15 hours without any clue. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77229/new/ https://reviews.llvm.org/D77229 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
