[clang] [analyzer][NFC] Explain why operator new/delete should never be eval-called (PR #161370)
Balázs Benics via cfe-commits
cfe-commits at lists.llvm.org
Tue Sep 30 06:56:53 PDT 2025
================
@@ -262,6 +262,14 @@ class CheckerDocumentation
/// state. This callback allows a checker to provide domain specific knowledge
/// about the particular functions it knows about.
///
+ /// Note that to evaluate a call, the handler MUST bind the return value if
+ /// its a non-void function. Invalidate the arguments if necessary.
+ ///
+ /// Note that in general, user-provided functions should not be eval-called
+ /// because the checker can't predict the exact semantics/contract of the
+ /// callee, and by having the eval::Call callback, we also prevent it from
+ /// getting inlined, potentially regressing analysis quality.
----------------
balazs-benics-sonarsource wrote:
```suggestion
/// getting inlined, potentially regressing analysis quality.
/// Consider using check::PreCall or check::PostCall to allow inlining.
```
https://github.com/llvm/llvm-project/pull/161370
More information about the cfe-commits
mailing list