[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

balazske abandoned this revision. balazske added a comment. StreamChecker will be updated in other changes, see: https://reviews.llvm.org/D75158 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69662/new/ https://reviews.llvm.org/D69662 ___

[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

Szelethus added a comment. In D69662#1890007 , @NoQ wrote: > In D69662#1889545 , @Szelethus wrote: > > > Sorry for the slack :) > > > > One should never count on the invocation order of callback funcions in > > bet

[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

NoQ added a comment. In D69662#1889545 , @Szelethus wrote: > Sorry for the slack :) > > One should never count on the invocation order of callback funcions in > between checkers. In fact, I'm not too sure that my patches affect this, but > I suspect that

[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

Szelethus added a comment. Herald added a subscriber: martong. In D69662#1744479 , @NoQ wrote: > In D69662#1736601 , @balazske wrote: > > > Anyway the checks that do not use BindExpr (all except the open functions)

[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

NoQ added a comment. In D69662#1736601 , @balazske wrote: > Anyway the checks that do not use BindExpr (all except the open functions) > could be moved into a PreCall or PostCall callback? Moving from evalCall to PreCall/PostCall has the additional effe

[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

balazske added a comment. I removed the previous comment because I realized that `StdCLibraryFunctionsChecker` does not use `evalCall` for fread (returns false because "non-pure" evaluation). Anyway the checks that do not use BindExpr (all except the open functions) could be moved into a PreCa

[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

NoQ added a comment. Given that i roughly remember what the previous comment was about and i wanted to comment on this: you should totally move `evalCall` for any functions you need from `StdCLibraryFunctionsChecker` to this checker, given that your checker is more specialized. That said, you

[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

balazske added a comment. So we can have only one checker to model `fread` with `eval::Call`. Why is `fread` now modeled by StreamChecker and StdLibraryFunctionsChecker (both use `eval::Call`)? These checkers look at the function from different aspects, I do not like to have one checker with bo

[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

NoQ added a comment. Yes, indeed, `evalCall` can only be performed by one checker. But if any, it is this checker that's fully responsible for stream functions. So i recommend doing evalCall in this particular checker and falling back to `PreCall`/`PostCall` in other checkers that model other a

[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

balazske added a comment. From the same book: There are multiple preconditions required for inlining to happen, including: — Source code of the callee function body needs to be available; — No checker should evaluate the function call via eval::Call; Abandon this change? Repository: rG

[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

Szelethus added a comment. In 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

[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

Charusso added a comment. On multiple evaluation of the same call the Analyzer will warn and prevent you to do so. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69662/new/ https://reviews.llvm.org/D69662

[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

balazske marked an inline comment as done. balazske added a comment. 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. ==

[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

NoQ added a comment. But why? Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:161 .castAs(); state = state->BindExpr(CE, C.getLocationContext(), RetVal); You're not allowed to do this in `checkPostCall` because other post-call c

[PATCH] D69662: [Checkers] Avoid using evalCall in StreamChecker.

balazske created this revision. Herald added subscribers: cfe-commits, gamesh411, Szelethus, dkrupp. Herald added a project: clang. Use of evalCall is replaced by preCall and postCall. Repository: rG LLVM Github Monorepo https://reviews.llvm.org/D69662 Files: clang/lib/StaticAnalyzer/Check