Szelethus added a comment. This looks great!
================ Comment at: clang/test/Analysis/NewDelete-checker-test.cpp:41-52 +// RUN: %clang_analyze_cc1 -std=c++17 -fblocks %s \ +// RUN: -verify=expected,newdelete \ +// RUN: -analyzer-checker=core \ +// RUN: -analyzer-checker=cplusplus.NewDelete \ +// RUN: -analyzer-config c++-allocator-inlining=true +// +// RUN: %clang_analyze_cc1 -std=c++17 -fblocks -verify %s \ ---------------- This mail adds some insight into the usage of `c++-allocator-inlining`: https://lists.llvm.org/pipermail/cfe-dev/2020-February/064754.html About the code in `MallocChecker` that handles this flag (`NewDelete` is a part of this as well): > Yes, we should remove the old code for c++-allocator-inlining=false. The > worry we've had back then as that in the new mode we've disabled aggressive > behavior of MallocChecker in which it reacted to some overloaded operator new > invocations but i think this was the right thing to do and also nobody > complained; also nothing prevents us from bringing back the old behavior in a > much less confusing way. As a response, D75432 removed all code that handed `c++-allocator-inlinging=false`. So these RUN lines can be removed I think. ================ Comment at: clang/test/Analysis/NewDelete-checker-test.cpp:54-57 +// RUN: %clang_analyze_cc1 -std=c++17 -fblocks -verify %s \ +// RUN: -verify=expected,leak \ +// RUN: -analyzer-checker=core \ +// RUN: -analyzer-checker=cplusplus.NewDeleteLeaks ---------------- This last RUN seems to be the same as the first. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D102835/new/ https://reviews.llvm.org/D102835 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
