baloghadamsoftware marked an inline comment as done. baloghadamsoftware added inline comments.
================ Comment at: clang/lib/StaticAnalyzer/Core/Store.cpp:472 + break; + } + ---------------- baloghadamsoftware wrote: > 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. Problem solved. Captured variables are always variables, even if they were paramseters originally. I added support for binding the old values to the new regions upon capture for `ParamRegion`s as well. This solved the failing test. 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