Szelethus added a comment. In D69662#1731974 <https://reviews.llvm.org/D69662#1731974>, @balazske wrote:
> I wanted to remove `eval::Call` because only one checker can do this > otherwise it is undefined behavior (according to the not very new "Analyzer > Guide"). If it is essentially needed in this checker it will remain. Lets get the direct quote from the book: > Usage of this callback is discouraged because only one checker may evaluate > any call event; if two or more checkers, probably developed by different > people, accidentally evaluate the same function, behavior of the analyzer is > undefined. So, if possible, `check::PreCall` and `check::PostCall` should be > considered, and most of the time they are flexible enough to model effects of > the call on the program state. I think this statement just doesn't reflect our current stance on the issue, mostly because In D69662#1731987 <https://reviews.llvm.org/D69662#1731987>, @Charusso wrote: > On multiple evaluation of the same call the Analyzer will warn and prevent > you to do so. I think modeling core library functions is more fitting to be handled by `eval::Call`s. Do I understand correctly that a function modeled by `eval::Call` won't be inlined? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69662/new/ https://reviews.llvm.org/D69662 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
