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

Reply via email to