Fix a long standard problem with clang retaining "too much" sugar
information about types. We often print diagnostics where we say
"foo_t" is bad, but the user doesn't know how foo_t is declared
(because it is a typedef). Fix this by expanding sugar when present
in a diagnostic (and not one of a few special cases, like vectors).
Before:
t.m:5:2: error: invalid operands to binary expression ('typeof(P)' and 'typeof(F)')
MAX(P, F);
^~~~~~~~~
t.m:1:78: note: instantiated from:
#define MAX(A,B) ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
^
After:
t.m:5:2: error: invalid operands to binary expression ('typeof(P)' (aka 'struct mystruct') and 'typeof(F)' (aka 'float'))
MAX(P, F);
^~~~~~~~~
t.m:1:78: note: instantiated from:
#define MAX(A,B) ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
^
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65081 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/test/SemaCXX/inherit.cpp b/test/SemaCXX/inherit.cpp
index 6c00218..7e04052 100644
--- a/test/SemaCXX/inherit.cpp
+++ b/test/SemaCXX/inherit.cpp
@@ -28,5 +28,5 @@
typedef G G_copy_2;
typedef G_copy G_copy_3;
-class H : G_copy, A, G_copy_2, // expected-error{{base class 'G_copy' specified more than once as a direct base class}}
- public G_copy_3 { }; // expected-error{{base class 'G_copy' specified more than once as a direct base class}}
+class H : G_copy, A, G_copy_2, // expected-error{{base class 'G_copy' (aka 'class G') specified more than once as a direct base class}}
+ public G_copy_3 { }; // expected-error{{base class 'G_copy' (aka 'class G') specified more than once as a direct base class}}