maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Index/complete-recovery.m

30 lines
1.3 KiB
Mathematica
Raw Normal View History

Improve code completion in failure cases in two ways: 1) Suppress diagnostics as soon as we form the code-completion token, so we don't get any error/warning spew from the early end-of-file. 2) If we consume a code-completion token when we weren't expecting one, go into a code-completion recovery path that produces the best results it can based on the context that the parser is in. llvm-svn: 104585
2010-05-25 13:58:43 +08:00
/* Run lines are at the end, since line/column matter in this test. */
@interface A
- (void)method:(int)x;
@end
@implementation A
- (void)method:(int)x {
A *a = [A method:1];
When we run into an error parsing or type-checking the left-hand side of a binary expression, continue on and parse the right-hand side of the binary expression anyway, but don't call the semantic actions to type-check. Previously, we would see the error and then, effectively, skip tokens until the end of the statement. The result should be more useful recovery, both in the normal case (we'll actually see errors beyond the first one in a statement), but it also helps code completion do a much better job, because we do "real" code completion on the right-hand side of an invalid binary expression rather than completing with the recovery completion. For example, given x = p->y if there is no variable named "x", we can still complete after the p-> as a member expression. Along the recovery path, we would have completed after the "->" as if we were in an expression context, which is mostly useless. llvm-svn: 114225
2010-09-18 06:25:06 +08:00
blarg * blah = wibble;
A *a2;
z = [a2 method:1];
Improve code completion in failure cases in two ways: 1) Suppress diagnostics as soon as we form the code-completion token, so we don't get any error/warning spew from the early end-of-file. 2) If we consume a code-completion token when we weren't expecting one, go into a code-completion recovery path that produces the best results it can based on the context that the parser is in. llvm-svn: 104585
2010-05-25 13:58:43 +08:00
}
@end
Only enable code patterns (e.g., try { statements } catch (...) { statements }) in the code-completion results if explicitly requested. llvm-svn: 104637
2010-05-26 05:41:55 +08:00
// RUN: c-index-test -code-completion-at=%s:9:20 -Xclang -code-completion-patterns %s 2>%t | FileCheck -check-prefix=CHECK-CC1 %s
Improve code completion in failure cases in two ways: 1) Suppress diagnostics as soon as we form the code-completion token, so we don't get any error/warning spew from the early end-of-file. 2) If we consume a code-completion token when we weren't expecting one, go into a code-completion recovery path that produces the best results it can based on the context that the parser is in. llvm-svn: 104585
2010-05-25 13:58:43 +08:00
// RUN: not grep error %t
// CHECK-CC1: NotImplemented:{TypedText @encode}{LeftParen (}{Placeholder type-name}{RightParen )}
Do not produce types as valid code completions when we're in an expression context in C/Objective-C, or when we're in an @interface/@implementation/@protocol in Objective-C(++). llvm-svn: 104908
2010-05-28 08:49:12 +08:00
// CHECK-CC1-NOT: NotImplemented:{TypedText _Bool}
Improve code completion in failure cases in two ways: 1) Suppress diagnostics as soon as we form the code-completion token, so we don't get any error/warning spew from the early end-of-file. 2) If we consume a code-completion token when we weren't expecting one, go into a code-completion recovery path that produces the best results it can based on the context that the parser is in. llvm-svn: 104585
2010-05-25 13:58:43 +08:00
// CHECK-CC1: VarDecl:{ResultType A *}{TypedText a}
// CHECK-CC1: NotImplemented:{TypedText sizeof}{LeftParen (}{Placeholder expression-or-type}{RightParen )}
Avoid unnecessary redirect, so that stderr shows up in output. llvm-svn: 112965
2010-09-03 23:45:00 +08:00
// RUN: c-index-test -code-completion-at=%s:10:24 -Xclang -code-completion-patterns %s | FileCheck -check-prefix=CHECK-CC2 %s
Do not produce types as valid code completions when we're in an expression context in C/Objective-C, or when we're in an @interface/@implementation/@protocol in Objective-C(++). llvm-svn: 104908
2010-05-28 08:49:12 +08:00
// CHECK-CC2: NotImplemented:{TypedText @encode}{LeftParen (}{Placeholder type-name}{RightParen )}
// CHECK-CC2: NotImplemented:{TypedText _Bool}
// CHECK-CC2: VarDecl:{ResultType A *}{TypedText a}
// CHECK-CC2: NotImplemented:{TypedText sizeof}{LeftParen (}{Placeholder expression-or-type}{RightParen )}
When we run into an error parsing or type-checking the left-hand side of a binary expression, continue on and parse the right-hand side of the binary expression anyway, but don't call the semantic actions to type-check. Previously, we would see the error and then, effectively, skip tokens until the end of the statement. The result should be more useful recovery, both in the normal case (we'll actually see errors beyond the first one in a statement), but it also helps code completion do a much better job, because we do "real" code completion on the right-hand side of an invalid binary expression rather than completing with the recovery completion. For example, given x = p->y if there is no variable named "x", we can still complete after the p-> as a member expression. Along the recovery path, we would have completed after the "->" as if we were in an expression context, which is mostly useless. llvm-svn: 114225
2010-09-18 06:25:06 +08:00
// RUN: c-index-test -code-completion-at=%s:12:11 -Xclang -code-completion-patterns %s | FileCheck -check-prefix=CHECK-CC3 %s
// CHECK-CC3: ObjCInstanceMethodDecl:{ResultType void}{TypedText method:}{Placeholder (int)} (17)