Factor out (some of) the checking for invalid forms of pointer

arithmetic into a couple of common routines. Use these to make the
messages more consistent in the various contexts, especially in terms of
consistently diagnosing binary operators with invalid types on both the
left- and right-hand side. Also, improve the grammar and wording of the
messages some, handling both two pointers and two (different) types.

The wording of function pointer arithmetic diagnostics still strikes me
as poorly phrased, and I worry this makes them slightly more awkward if
more consistent. I'm hoping to fix that with a follow-on patch and test
case that will also make them more helpful when a typedef or template
type parameter makes the type completely opaque.

Suggestions on better wording are very welcome, thanks to Richard Smith
for some initial help on that front.

llvm-svn: 133906

1 files changed, 1 insertions, 1 deletions

diff --git a/clang/test/Sema/incomplete-decl.c b/clang/test/Sema/incomplete-decl.c
index e5b6d5f0da6..0214a0c6ce4 100644
--- a/clang/test/Sema/incomplete-decl.c
+++ b/clang/test/Sema/incomplete-decl.c
@@ -22,7 +22,7 @@ void func() {
 }
 
 int h[]; // expected-warning {{tentative array definition assumed to have one element}}
-int (*i)[] = &h+1; // expected-error {{arithmetic on pointer to incomplete type 'int (*)[]'}}
+int (*i)[] = &h+1; // expected-error {{arithmetic on a pointer to an incomplete type 'int []'}}
 
 struct bar j = {1}; // expected-error {{variable has incomplete type 'struct bar'}} \
     expected-note {{forward declaration of 'struct bar'}}