llvm-project/clang/test/Parser/recovery.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

102 lines
2.4 KiB
C
Raw Normal View History

// RUN: %clang_cc1 -fsyntax-only -verify -pedantic -fblocks %s
// PR2241
float test2241[2] = {
1e, // expected-error {{exponent}}
1ee0 // expected-error {{exponent}}
};
// Testcase derived from PR2692
2009-07-22 08:43:08 +08:00
static void f (char * (*g) (char **, int), char **p, ...) {
char *s;
va_list v; // expected-error {{identifier}}
s = g (p, __builtin_va_arg(v, int)); // expected-error {{identifier}}
}
// PR3172
} // expected-error {{extraneous closing brace ('}')}}
// rdar://6094870
2009-07-22 08:43:08 +08:00
void test(int a) {
struct { int i; } x;
if (x.hello) // expected-error {{no member named 'hello'}}
test(0);
else
;
if (x.hello == 0) // expected-error {{no member named 'hello'}}
test(0);
else
;
if ((x.hello == 0)) // expected-error {{no member named 'hello'}}
test(0);
else
;
// PR12595
if (x.i == 0)) // expected-error {{extraneous ')' after condition, expected a statement}}
test(0);
else
;
}
char (((( /* expected-note {{to match this '('}} */
*X x ] )))); /* expected-error {{expected ')'}} */
; // expected-warning {{extra ';' outside of a function}}
struct S { void *X, *Y; };
struct S A = {
&BADIDENT, 0 /* expected-error {{use of undeclared identifier}} */
};
// rdar://6248081
2009-07-22 08:43:08 +08:00
void test6248081() {
[10] // expected-error {{expected expression}}
}
struct forward; // expected-note{{forward declaration of 'struct forward'}}
void x(struct forward* x) {switch(x->a) {}} // expected-error {{incomplete definition of type}}
Introduce code modification hints into the diagnostics system. When we know how to recover from an error, we can attach a hint to the diagnostic that states how to modify the code, which can be one of: - Insert some new code (a text string) at a particular source location - Remove the code within a given range - Replace the code within a given range with some new code (a text string) Right now, we use these hints to annotate diagnostic information. For example, if one uses the '>>' in a template argument in C++98, as in this code: template<int I> class B { }; B<1000 >> 2> *b1; we'll warn that the behavior will change in C++0x. The fix is to insert parenthese, so we use code insertion annotations to illustrate where the parentheses go: test.cpp:10:10: warning: use of right-shift operator ('>>') in template argument will require parentheses in C++0x B<1000 >> 2> *b1; ^ ( ) Use of these annotations is partially implemented for HTML diagnostics, but it's not (yet) producing valid HTML, which may be related to PR2386, so it has been #if 0'd out. In this future, we could consider hooking this mechanism up to the rewriter to actually try to fix these problems during compilation (or, after a compilation whose only errors have fixes). For now, however, I suggest that we use these code modification hints whenever we can, so that we get better diagnostics now and will have better coverage when we find better ways to use this information. This also fixes PR3410 by placing the complaint about missing tokens just after the previous token (rather than at the location of the next token). llvm-svn: 65570
2009-02-27 05:00:50 +08:00
// PR3410
void foo() {
int X;
X = 4 // expected-error{{expected ';' after expression}}
}
// rdar://9045701
void test9045701(int x) {
#define VALUE 0
x = VALUE // expected-error{{expected ';' after expression}}
}
// rdar://7980651
typedef int intptr_t; // expected-note {{'intptr_t' declared here}}
void bar(intptr y); // expected-error {{unknown type name 'intptr'; did you mean 'intptr_t'?}}
void test1(void) {
int x = 2: // expected-error {{expected ';' at end of declaration}}
int y = x;
int z = y;
}
void test2(int x) {
#define VALUE2 VALUE+VALUE
#define VALUE3 VALUE+0
#define VALUE4(x) x+0
x = VALUE2 // expected-error{{expected ';' after expression}}
x = VALUE3 // expected-error{{expected ';' after expression}}
x = VALUE4(0) // expected-error{{expected ';' after expression}}
}