[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