maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Sema/pointer-addition.c

22 lines
1.5 KiB
C
Raw Normal View History

Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'. - This is designed to make it obvious that %clang_cc1 is a "test variable" which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it can be useful to redefine what gets run as 'clang -cc1' (for example, to set a default target). llvm-svn: 91446
2009-12-16 04:14:24 +08:00
// RUN: %clang_cc1 %s -fsyntax-only -verify -pedantic
Add proper type-checking for pointer additiion; before, we were accepting addition with a pointer and an integer even when it didn't make sense. llvm-svn: 51228
2008-05-19 02:08:51 +08:00
Make one expected-diag directive match exactly one actual diagnostic. This uncovers some bugs, so several test cases now fail. llvm-svn: 64025
2009-02-08 03:52:04 +08:00
typedef struct S S; // expected-note 3 {{forward declaration of 'struct S'}}
Add proper type-checking for pointer additiion; before, we were accepting addition with a pointer and an integer even when it didn't make sense. llvm-svn: 51228
2008-05-19 02:08:51 +08:00
void a(S* b, void* c) {
Support arithmetic on pointer-to-function types as a GNU extension. Addresses clang PR/3371. llvm-svn: 62823
2009-01-23 08:36:41 +08:00
void (*fp)(int) = 0;
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
2011-06-27 16:02:19 +08:00
b++; // expected-error {{arithmetic on a pointer to an incomplete type}}
b += 1; // expected-error {{arithmetic on a pointer to an incomplete type}}
c++; // expected-warning {{arithmetic on a pointer to void is a GNU extension}}
c += 1; // expected-warning {{arithmetic on a pointer to void is a GNU extension}}
c--; // expected-warning {{arithmetic on a pointer to void is a GNU extension}}
c -= 1; // expected-warning {{arithmetic on a pointer to void is a GNU extension}}
Cleanup a fixme by using a specific diagnostic for subscripting a pointer to void. llvm-svn: 133912
2011-06-28 00:32:27 +08:00
(void) c[1]; // expected-warning {{subscript of a pointer to void is a GNU extension}}
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
2011-06-27 16:02:19 +08:00
b = 1+b; // expected-error {{arithmetic on a pointer to an incomplete type}}
Add proper type-checking for pointer additiion; before, we were accepting addition with a pointer and an integer even when it didn't make sense. llvm-svn: 51228
2008-05-19 02:08:51 +08:00
/* The next couple tests are only pedantic warnings in gcc */
void (*d)(S*,void*) = a;
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
2011-06-27 16:02:19 +08:00
d += 1; // expected-warning {{arithmetic on a pointer to the function type 'void (S *, void *)' is a GNU extension}}
d++; // expected-warning {{arithmetic on a pointer to the function type 'void (S *, void *)' is a GNU extension}}
d--; // expected-warning {{arithmetic on a pointer to the function type 'void (S *, void *)' is a GNU extension}}
d -= 1; // expected-warning {{arithmetic on a pointer to the function type 'void (S *, void *)' is a GNU extension}}
(void)(1 + d); // expected-warning {{arithmetic on a pointer to the function type 'void (S *, void *)' is a GNU extension}}
Add proper type-checking for pointer additiion; before, we were accepting addition with a pointer and an integer even when it didn't make sense. llvm-svn: 51228
2008-05-19 02:08:51 +08:00
}