[PATCH] D132236: [analyzer] Fix liveness of LazyCompoundVals

tomasz-kaminski-sonarsource added a comment. > What looks fishy about getInterestingValues() is that it assumes that the > amount of interesting values is finite. This sounds incredibly wrong to me. > If a lazy compound value contains any pointer symbol `$p`, then all values in > the following

[PATCH] D132236: [analyzer] Fix liveness of LazyCompoundVals

steakhal abandoned this revision. steakhal added a comment. I'm abandoning this change in favor of D134947 . I'll leave the patch summary and the discussion here for the history. --- In D132236#3753238 , @NoQ wrote: >>

[PATCH] D132236: [analyzer] Fix liveness of LazyCompoundVals

NoQ added a comment. > For FPs I dont know how to automate this process. :/ Given that our initial hypothesis was that there should be zero new false positives, it could probably work with a creduce predicate //"this code has a warning after the patch but not before the patch"//. The initial hy

[PATCH] D132236: [analyzer] Fix liveness of LazyCompoundVals

steakhal planned changes to this revision. steakhal added a comment. In D132236#3752209 , @NoQ wrote: >> So, what you are suggesting here is an alternative solution to the one you >> already proposed in your last comment? > > I was just expanding the ini

[PATCH] D132236: [analyzer] Fix liveness of LazyCompoundVals

NoQ added a comment. > So, what you are suggesting here is an alternative solution to the one you > already proposed in your last comment? I was just expanding the initial suggestion but also symbol reaper is too complicated for me to make such suggestions confidently. So I'm just sharing some

[PATCH] D132236: [analyzer] Fix liveness of LazyCompoundVals

steakhal added a comment. In D132236#3747652 , @NoQ wrote: > Nice catch but I don't think this is the right solution. > > Symbol liveness corresponds to a concrete runtime property of the program: > can the program obtain this value by executing further

[PATCH] D132236: [analyzer] Fix liveness of LazyCompoundVals

NoQ added a comment. So to be clear, I think your solution is probably an ok stop-gap solution. False negatives aren't that bad, I'm more worried that existing leak reports may become less understandable because they'll be reported later than necessary, which may obscure the reason why we think

[PATCH] D132236: [analyzer] Fix liveness of LazyCompoundVals

NoQ added a comment. Nice catch but I don't think this is the right solution. Symbol liveness corresponds to a concrete runtime property of the program: can the program obtain this value by executing further runtime instructions? The program cannot obtain a pointer to variable `n`, or even a po

[PATCH] D132236: [analyzer] Fix liveness of LazyCompoundVals

steakhal updated this revision to Diff 454861. steakhal added a comment. rebase Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D132236/new/ https://reviews.llvm.org/D132236 Files: clang/lib/StaticAnalyzer/Core/RegionStore.cpp clang/test/Analysis

[PATCH] D132236: [analyzer] Fix liveness of LazyCompoundVals

steakhal created this revision. steakhal added reviewers: NoQ, xazax.hun, martong, ASDenysPetrov, Szelethus, isuckatcs, vabridgers. Herald added subscribers: manas, dkrupp, donat.nagy, mikhail.ramalho, a.sidorin, rnkovacs, szepet, baloghadamsoftware. Herald added a project: All. steakhal requeste