aaron.ballman accepted this revision. aaron.ballman added a comment. This revision is now accepted and ready to land.
LGTM! ================ Comment at: clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-exception-at-new.rst:7 +Finds calls to ``new`` that may throw ``std::bad_alloc`` exception and +the exception handler is missing. + ---------------- balazske wrote: > aaron.ballman wrote: > > This isn't quite accurate -- if the exception handler is missing or doesn't > > handle either `std::bad_alloc` or `std::exception`. > I restructure the text, but do not want to mention `std::exception` because > it is a base class (handling of `std::exception` means handling of > `std::bad_alloc`), and then why not mention generic exception handler > (`catch(...)`). I think this text is for introduction only, should not be > totally precise. The restructured text is good -- I just wanted the information *somewhere* so that users weren't surprised by the behavior. ================ Comment at: clang-tools-extra/test/clang-tidy/checkers/bugprone-unhandled-exception-at-new.cpp:20 +using badalloc3 = std::bad_alloc &; + +void *operator new(std::size_t, int, int); ---------------- balazske wrote: > aaron.ballman wrote: > > Another interesting test case would be when the user subclasses > > `std::bad_alloc` and throws errors of the subclass type from the allocation > > function which are in/correctly caught. > In this case the check must find every (visible) subclass of `std::bad_alloc` > check if there is a catch block for every case. Even then a custom allocation > function may throw other classes (not derived from `std::bad_alloc`) or > classes (may be inherited from `std::bad_alloc` but not visible in the TU) > that are not checked. So this is still a partial solution, probably not > better than the rule that a handler for `bad_alloc` (or more generic) should > exist. > So this is still a partial solution, probably not better than the rule that a > handler for bad_alloc (or more generic) should exist. Okay, that's fair -- we can always address it in follow-up if it turns out to be an issue in practice. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D97196/new/ https://reviews.llvm.org/D97196 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
