llvm-project/clang/test/SemaCXX/unreachable-catch-clauses.cpp
Aaron Ballman 0950332e91 Fix false positive with unreachable C++ catch handlers
This addresses an issue found by WG21 and tracked by CWG2699 (which is
not yet publicly published). The basic problem is that Clang issues a
diagnostic about not being able to reach a handler, but that handler
*is* reached at runtime. Clang's diagnostic behavior was matching the
standard wording, and our runtime behavior was matching the standard's
intent.

This fixes the diagnostic so that it matches the runtime behavior more
closely, and reduces the number of false positives. This is the
direction of choice taken by Core for CWG2699 and it seems unlikely
that WG21 will change direction here.

Fixes https://github.com/llvm/llvm-project/issues/61177
Differential Revision: https://reviews.llvm.org/D145408
2023-03-14 11:08:39 -04:00

34 lines
1.1 KiB
C++

// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -fsyntax-only -verify %s
class BaseEx {};
class Ex1: public BaseEx {};
typedef Ex1 Ex2;
void f();
void test()
try {}
catch (BaseEx &e) { f(); } // expected-note 2{{for type 'BaseEx &'}}
catch (Ex1 &e) { f(); } // expected-warning {{exception of type 'Ex1 &' will be caught by earlier handler}} \
expected-note {{for type 'Ex1 &'}}
// FIXME: It would be nicer to only issue one warning on the below line instead
// of two. We get two diagnostics because the first one is noticing that there
// is a class hierarchy inversion where the earlier base class handler will
// catch throwing the derived class and the second one is because Ex2 and Ex1
// are the same type after canonicalization.
catch (Ex2 &e) { f(); } // expected-warning 2{{exception of type 'Ex2 &' (aka 'Ex1 &') will be caught by earlier handler}}
namespace GH61177 {
void func() {
const char arr[4] = "abc";
// We should not issue an "exception will be caught by earlier handler"
// diagnostic, as that is a lie.
try {
throw arr;
} catch (char *p) {
} catch (const char *p) {
}
}
} // GH61177