[PATCH] D75430: [analyzer][NFC] Introduce CXXDeallocatorCall, deploy it in MallocChecker
Kristóf Umann via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Apr 3 06:57:41 PDT 2020
Szelethus requested review of this revision.
Szelethus added a comment.
Since this change had a few blocking issues, I'm placing it back to review for greater visibility.
================
Comment at: clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h:67
CE_CXXAllocator,
+ CE_CXXDeallocator,
CE_BEG_FUNCTION_CALLS = CE_Function,
----------------
NoQ wrote:
> After this you probably received compiler warnings saying "case isn't covered in switch". You'll need to clean them up.
>
> Another thing to do would be to update `CallEventManager`'s `getCall()` and `getCaller()` methods that'd allow the users to construct the new `CallEvent` easily without thinking about what specific kind of call event it is.
No, I did not, infuriatingly. I did however get //errors// after trying to make a `toString` function for `CallEventKind`, apparently both `CE_CXXDeallocator` and `CE_Block` has the value of 7. When I moved the enum, everything was fine, and I did get the warnings you mentioned.
================
Comment at: clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h:958
+
+ unsigned getNumArgs() const override { return getDecl()->getNumParams(); }
+
----------------
steakhal wrote:
> NoQ wrote:
> > Charusso wrote:
> > > `return getOriginExpr()->getNumArgs()`
> > This wouldn't compile. `CXXDeleteExpr` is not a `CallExpr`.
> >
> > It sounds like there are currently [[ http://www.cplusplus.com/reference/new/operator%20delete/ | five different `operator delete`s ]]:
> > {F11474783}
> >
> > And, unlike `operator new`, there's no option to provide custom "placement" arguments.
> >
> > So i think the logic in this patch is correct but we should do some custom logic for all 5 cases in the `getArgExpr` method, where argument expressions for the extra arguments will have to be conjured out of thin air (or we might as well return null).
> > It sounds like there are currently five different `operator delete`s:
> I think it is even worse since C++17 and C++20 introduced a couple of others like:
> - overloads with `std::align_val_t` parameter (C++17)
> - overloads with `std::destroying_delete_t` parameter (C++20) which I haven't heard of yet :D
>
> You can check it in the draft: http://eel.is/c++draft/new.delete
> And of course at cppreference as well: https://en.cppreference.com/w/cpp/memory/new/operator_delete
Okay so here is the biggest issue: non-simple `delete`s don't appear in the AST as `CXXDeleteExpr`, but rather as a `CXXOperatorCall`. This is a big problem, what could be the reason for it?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D75430/new/
https://reviews.llvm.org/D75430
More information about the cfe-commits
mailing list