[lit] Script to automate use of %(line-n). Use in CodeComplete tests.

Tests where the RUN-lines/CHECK-ed output refer to line numbers in the test
file are a maintenance burden, as inserting text in

[lit] Script to automate use of %(line-n). Use in CodeComplete tests.

Tests where the RUN-lines/CHECK-ed output refer to line numbers in the test
file are a maintenance burden, as inserting text in the appropriate place
invalidates all the subsequent line numbers.

Lit supports %(line+n) for this, and FileCheck supports [[@LINE+N]].
But many existing tests don't make use of it and still need to be modified.

This commit adds a script that can find line numbers in tests according to a
regex and replace them with the appropriate relative-line reference.
It contains some options to avoid inappropriately rewriting tests where absolute
numbers are appropriate: a "nearby" threshold and a refusal by default to
replace only some matched line numbers.

I've applied it to CodeComplete tests, this proves the concept but also are the
single worst group of tests I've seen in this respect.
These changes are likely to hit merge conflicts, but can be regenerated with:

```
find ../clang/test/CodeCompletion/ -type f | grep -v /Inputs/ | xargs ../llvm/utils/relative_lines.py --verbose --near=20 --pattern='-code-completion-at[ =]%s:(\\d+):' --pattern='requires fix-it: {(\d+):\d+-(\d+):\d+}'
````

As requested in https://reviews.llvm.org/D140044

Fixes https://github.com/llvm/llvm-project/issues/59553

Differential Revision: https://reviews.llvm.org/D140217

show more ...

[CodeCompletion] (mostly) fix completion in incomplete C++ ctor initializers.

C++ member function bodies (including ctor initializers) are first captured
into a buffer and then parsed after the clas

[CodeCompletion] (mostly) fix completion in incomplete C++ ctor initializers.

C++ member function bodies (including ctor initializers) are first captured
into a buffer and then parsed after the class is complete. (This allows
members to be referenced even if declared later).

When the boundary of the function body cannot be established, its buffer is
discarded and late-parsing never happens (it would surely fail).
For code completion this is the wrong tradeoff: the point of the parse is to
generate completions as a side-effect.
Today, when the ctor body wasn't typed yet there are no init list completions.
With this patch we parse such an init-list if it contains the completion point.

There's one caveat: the parser has to decide where to resume parsing members
after a broken init list. Often the first clear recovery point is *after* the
next member, so that member is missing from completion/signature help etc. e.g.
struct S {
S() m //<- completion here
int maaa;
int mbbb;
}
Here "int maaa;" is treated as part of the init list, so "maaa" is not available
as a completion. Maybe in future indentation can be used to recognize that
this is a separate member, not part of the init list.

Differential Revision: https://reviews.llvm.org/D116294

show more ...

[clang] Improve ctor initializer completions.

Summary:
Instead of providing generic "args" for member and base class
initializers, tries to fetch relevant constructors and show their signatures.

Re

[clang] Improve ctor initializer completions.

Summary:
Instead of providing generic "args" for member and base class
initializers, tries to fetch relevant constructors and show their signatures.

Reviewers: ilya-biryukov

Reviewed By: ilya-biryukov

Subscribers: ZaMaZaN4iK, eraman, arphaman, cfe-commits

Differential Revision: https://reviews.llvm.org/D53654

llvm-svn: 345844

show more ...

[CodeCompletion] Enable signature help when initializing class/struct/union members.

Summary:
Factors out member decleration gathering and uses it in parsing to call signature
help. Doesn't support

[CodeCompletion] Enable signature help when initializing class/struct/union members.

Summary:
Factors out member decleration gathering and uses it in parsing to call signature
help. Doesn't support signature help for base class constructors, the code was too
coupled with diagnostic handling, but still can be factored out but just needs
more afford.

Reviewers: sammccall, ilya-biryukov, ioeric

Reviewed By: ilya-biryukov

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D51917

llvm-svn: 341949

show more ...

[CodeComplete] Fix completion in the middle of ident in ctor lists.

Summary:
The example that was broken before (^ designates completion points):

class Foo {
Foo() : fie^ld^() {} // no co

[CodeComplete] Fix completion in the middle of ident in ctor lists.

Summary:
The example that was broken before (^ designates completion points):

class Foo {
Foo() : fie^ld^() {} // no completions were provided here.
int field;
};

To fix it we don't cut off lexing after an identifier followed by code
completion token is lexed. Instead we skip the rest of identifier and
continue lexing.
This is consistent with behavior of completion when completion token is
right before the identifier.

Reviewers: sammccall, aaron.ballman, bkramer, sepavloff, arphaman, rsmith

Reviewed By: aaron.ballman

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D44932

llvm-svn: 330833

show more ...

Fix heuristics skipping invalid ctor-initializers with C++11

Use better heuristics to detect if a '{' might be the start of the constructor body
or not. Especially when there is a completion token.

Fix heuristics skipping invalid ctor-initializers with C++11

Use better heuristics to detect if a '{' might be the start of the constructor body
or not. Especially when there is a completion token.

Fix the test 'test/CodeCompletion/ctor-initializer.cpp ' when clang defaults to c++11

The problem was is how we recover invalid code in the ctor-init part as we skip the
function body. In particular, we want to know if a '{' is the begining of the body.
In C++03, we always consider it as the beginng of the body. The problem was that in
C++11, it may be the start of an initializer, so we skip over it, causing further
parse errors later. (It is important that we are able to parse correctly the rest
of the class definition, to know what are the class member, for example)

This commit is improving the heuristics to decide if the '{' is starting a function
body. The rules are the following: If we are not in a template argument, and that the
previous tokens are not an identifier, or a >, then it is much more likely to be the
function body. We verify that further by checking the token after the matching '}'

The commit also fix the behavior when there is a code_completion token in the
ctor-initializers.

Differential Revision: https://reviews.llvm.org/D21502

llvm-svn: 285883

show more ...

Fix a few issues while skipping function bodies

- In functions with try { } catch { }, only the try block would be
skipped, not the catch blocks

- The template functions would still be parsed.

Fix a few issues while skipping function bodies

- In functions with try { } catch { }, only the try block would be
skipped, not the catch blocks

- The template functions would still be parsed.

- The initializers within a constructor would still be parsed.

- The inline functions within class would still be stored, only to be
discared later.

- Invalid code with try would assert (as in "int foo() try assert_here")

This attempt to do even less while skipping function bodies.

Differential Revision: http://reviews.llvm.org/D20821

llvm-svn: 272963

show more ...