balazske added inline comments.
================ 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); ---------------- 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. 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
