afe73f4db8
Downstream, some change triggered an investigation if we could move a checker callback from check::PostCall to eval::Call. After a lengthy investigation that lead to ExprEngine::VisitCXXNewExpr we realized that CXXNewExprs only trigger a PreCall and PostCall, but never an EvalCall. It also had a FIXME that maybe it should trigger it. Remember, it called `defaultEvalCall` which either inlines or conservatively evaluates aka. invalidates the call. But never probes the checker eval-calls to see if any would step in. After implementing the changes to trigger the eval call for the checkers, I realized that it doesn't really make sense because we are eval-calling user-provided functions, that we can't be really sure about their semantics, thus there is no generic way to properly implement the eval call callback. This touches on an important point. It only ever makes sense to eval call functions that has a clear spec. such as standard functions, as implementing the callback would prevent the inlining of that function, risking regressing analysis quality if the implemented model is not complete/correct enough. As a conclusion, I opted for not exposing the eval call event to checkers, in other words, keep everything as-is, but document my journey. CPP-6585
51 lines
1.9 KiB
C++
51 lines
1.9 KiB
C++
// RUN: %clang_analyze_cc1 %s \
|
|
// RUN: -analyzer-checker=debug.AnalysisOrder \
|
|
// RUN: -analyzer-config debug.AnalysisOrder:EvalCall=true \
|
|
// RUN: -analyzer-config debug.AnalysisOrder:PreCall=true \
|
|
// RUN: -analyzer-config debug.AnalysisOrder:PostCall=true \
|
|
// RUN: 2>&1 | FileCheck %s
|
|
|
|
// This test ensures that eval::Call event will be triggered for constructors.
|
|
|
|
class C {
|
|
public:
|
|
C(){};
|
|
C(int x){};
|
|
C(int x, int y){};
|
|
};
|
|
|
|
void foo() {
|
|
C C0;
|
|
C C1(42);
|
|
C *C2 = new C{2, 3};
|
|
delete C2;
|
|
}
|
|
|
|
// CHECK: PreCall (C::C) [CXXConstructorCall]
|
|
// CHECK-NEXT: EvalCall (C::C) {argno: 0} [CXXConstructorCall]
|
|
// CHECK-NEXT: PostCall (C::C) [CXXConstructorCall]
|
|
|
|
// CHECK-NEXT: PreCall (C::C) [CXXConstructorCall]
|
|
// CHECK-NEXT: EvalCall (C::C) {argno: 1} [CXXConstructorCall]
|
|
// CHECK-NEXT: PostCall (C::C) [CXXConstructorCall]
|
|
|
|
// CHECK-NEXT: PreCall (operator new) [CXXAllocatorCall]
|
|
// COMMENT: Operator new calls (CXXNewExpr) are intentionally not eval-called,
|
|
// COMMENT: because it does not make sense to eval call user-provided functions.
|
|
// COMMENT: 1) If the new operator can be inlined, then don't prevent it from
|
|
// COMMENT: inlining by having an eval-call of that operator.
|
|
// COMMENT: 2) If it can't be inlined, then the default conservative modeling
|
|
// COMMENT: is what we anyways want anyway.
|
|
// COMMENT: So the EvalCall event will not be triggered for operator new calls.
|
|
// CHECK-NOT: EvalCall
|
|
// CHECK-NEXT: PostCall (operator new) [CXXAllocatorCall]
|
|
|
|
// CHECK-NEXT: PreCall (C::C) [CXXConstructorCall]
|
|
// CHECK-NEXT: EvalCall (C::C) {argno: 2} [CXXConstructorCall]
|
|
// CHECK-NEXT: PostCall (C::C) [CXXConstructorCall]
|
|
|
|
// CHECK-NEXT: PreCall (operator delete) [CXXDeallocatorCall]
|
|
// COMMENT: Same reasoning as for CXXNewExprs above.
|
|
// CHECK-NOT: EvalCall
|
|
// CHECK-NEXT: PostCall (operator delete) [CXXDeallocatorCall]
|