<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/clang/test/CodeCompletion/call.cpp, branch main</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[lit] Script to automate use of %(line-n). Use in CodeComplete tests.</title>
<updated>2022-12-19T13:19:21+00:00</updated>
<author>
<name>Sam McCall</name>
<email>sam.mccall@gmail.com</email>
</author>
<published>2022-12-16T14:59:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=cf9b25e0adc42546e4dc5ff51ee8674d45bac26b'/>
<id>cf9b25e0adc42546e4dc5ff51ee8674d45bac26b</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>[clang] Make signature help work with dependent args</title>
<updated>2020-08-17T08:06:36+00:00</updated>
<author>
<name>Kadir Cetinkaya</name>
<email>kadircet@google.com</email>
</author>
<published>2020-08-11T19:10:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=53c593c2c893a40083771789e3d3e164eea1892d'/>
<id>53c593c2c893a40083771789e3d3e164eea1892d</id>
<content type='text'>
Fixes https://github.com/clangd/clangd/issues/490

Differential Revision: https://reviews.llvm.org/D85826
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixes https://github.com/clangd/clangd/issues/490

Differential Revision: https://reviews.llvm.org/D85826
</pre>
</div>
</content>
</entry>
<entry>
<title>[clang][CodeComplete] Make completion work after initializer lists</title>
<updated>2020-01-23T14:32:46+00:00</updated>
<author>
<name>Kadir Cetinkaya</name>
<email>kadircet@google.com</email>
</author>
<published>2020-01-22T13:10:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=24364cd12bbfa2e58fa74bfb49d4ea85c64c0951'/>
<id>24364cd12bbfa2e58fa74bfb49d4ea85c64c0951</id>
<content type='text'>
Summary:
CodeCompletion was not being triggered after successfully parsed
initializer lists, e.g.

```cpp
void foo(int, bool);
void bar() {
  foo({1}^, false);
}
```

CodeCompletion would suggest the function foo as an overload candidate up until
the point marked with `^` but after that point we do not trigger signature help
since parsing succeeds.

This patch handles that case by failing in parsing expression lists whenever we
see a codecompletion token, in addition to getting an invalid subexpression.

Reviewers: sammccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D73177
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
CodeCompletion was not being triggered after successfully parsed
initializer lists, e.g.

```cpp
void foo(int, bool);
void bar() {
  foo({1}^, false);
}
```

CodeCompletion would suggest the function foo as an overload candidate up until
the point marked with `^` but after that point we do not trigger signature help
since parsing succeeds.

This patch handles that case by failing in parsing expression lists whenever we
see a codecompletion token, in addition to getting an invalid subexpression.

Reviewers: sammccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D73177
</pre>
</div>
</content>
</entry>
<entry>
<title>[CodeComplete] Clearly distinguish signature help and code completion.</title>
<updated>2018-09-07T14:04:39+00:00</updated>
<author>
<name>Ilya Biryukov</name>
<email>ibiryukov@google.com</email>
</author>
<published>2018-09-07T14:04:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=832c4afe00916c11c84130cd39b29e330a5e4d70'/>
<id>832c4afe00916c11c84130cd39b29e330a5e4d70</id>
<content type='text'>
Summary:
Code completion in clang is actually a mix of two features:
- Code completion is a familiar feature. Results are exposed via the
  CodeCompleteConsumer::ProcessCodeCompleteResults callback.
- Signature help figures out if the current expression is an argument of
  some function call and shows corresponding signatures if so.
  Results are exposed via CodeCompleteConsumer::ProcessOverloadCandidates.

This patch refactors the implementation to untangle those two from each
other and makes some naming tweaks to avoid confusion when reading the
code.

The refactoring is required for signature help fixes, see D51038.

The only intended behavior change is the order of callbacks.
ProcessOverloadCandidates is now called before ProcessCodeCompleteResults.

Reviewers: sammccall, kadircet

Reviewed By: sammccall

Subscribers: cfe-commits

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

llvm-svn: 341660
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
Code completion in clang is actually a mix of two features:
- Code completion is a familiar feature. Results are exposed via the
  CodeCompleteConsumer::ProcessCodeCompleteResults callback.
- Signature help figures out if the current expression is an argument of
  some function call and shows corresponding signatures if so.
  Results are exposed via CodeCompleteConsumer::ProcessOverloadCandidates.

This patch refactors the implementation to untangle those two from each
other and makes some naming tweaks to avoid confusion when reading the
code.

The refactoring is required for signature help fixes, see D51038.

The only intended behavior change is the order of callbacks.
ProcessOverloadCandidates is now called before ProcessCodeCompleteResults.

Reviewers: sammccall, kadircet

Reviewed By: sammccall

Subscribers: cfe-commits

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

llvm-svn: 341660
</pre>
</div>
</content>
</entry>
<entry>
<title>Avoid printing some redundant name qualifiers in completion</title>
<updated>2017-11-08T10:39:09+00:00</updated>
<author>
<name>Ilya Biryukov</name>
<email>ibiryukov@google.com</email>
</author>
<published>2017-11-08T10:39:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b5da91c875c53918a9bafc9afbd54390b0819422'/>
<id>b5da91c875c53918a9bafc9afbd54390b0819422</id>
<content type='text'>
Summary:
Adjusted PrintingPolicy inside code completion to avoid printing some
redundant name qualifiers.

Before this change, typedefs that were written unqualified in source
code were printed with qualifiers in completion. For example, in the
following code

    struct foo {
        typedef int type;
        type method();
    };

completion item for `method` had return type of `foo::type`, even
though the original code used `type` without qualifiers.
After this change, the completion item has return type `type`, as
originally written in the source code.

Note that this change does not suppress qualifiers written by the
user. For example, in the following code

    typedef int type;
    struct foo {
        typedef int type;
        ::type method(foo::type);
    };

completion item for `method` has return type of `::type` and
parameter type of `foo::type`, as originally written in the source
code.

Reviewers: arphaman, bkramer, klimek

Reviewed By: arphaman

Subscribers: mgorny, eraman, cfe-commits

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

llvm-svn: 317677
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
Adjusted PrintingPolicy inside code completion to avoid printing some
redundant name qualifiers.

Before this change, typedefs that were written unqualified in source
code were printed with qualifiers in completion. For example, in the
following code

    struct foo {
        typedef int type;
        type method();
    };

completion item for `method` had return type of `foo::type`, even
though the original code used `type` without qualifiers.
After this change, the completion item has return type `type`, as
originally written in the source code.

Note that this change does not suppress qualifiers written by the
user. For example, in the following code

    typedef int type;
    struct foo {
        typedef int type;
        ::type method(foo::type);
    };

completion item for `method` has return type of `::type` and
parameter type of `foo::type`, as originally written in the source
code.

Reviewers: arphaman, bkramer, klimek

Reviewed By: arphaman

Subscribers: mgorny, eraman, cfe-commits

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

llvm-svn: 317677
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix FileCheck --check-prefix lines.</title>
<updated>2013-08-12T12:51:05+00:00</updated>
<author>
<name>Tim Northover</name>
<email>tnorthover@apple.com</email>
</author>
<published>2013-08-12T12:51:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=19ae1175ae8d2597d16ea5ce7bb9f0993cd6765c'/>
<id>19ae1175ae8d2597d16ea5ce7bb9f0993cd6765c</id>
<content type='text'>
Various tests had sprung up over the years which had --check-prefix=ABC on the
RUN line, but "CHECK-ABC:" later on. This happened to work before, but was
strictly incorrect. FileCheck is getting stricter soon though.

Patch by Ron Ofir.

llvm-svn: 188174
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Various tests had sprung up over the years which had --check-prefix=ABC on the
RUN line, but "CHECK-ABC:" later on. This happened to work before, but was
strictly incorrect. FileCheck is getting stricter soon though.

Patch by Ron Ofir.

llvm-svn: 188174
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert the fix for PR8013.</title>
<updated>2010-11-09T20:03:54+00:00</updated>
<author>
<name>Douglas Gregor</name>
<email>dgregor@apple.com</email>
</author>
<published>2010-11-09T20:03:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=928479e727a0cdf5c245b30d708fe2de3b67bb08'/>
<id>928479e727a0cdf5c245b30d708fe2de3b67bb08</id>
<content type='text'>
That bug concerned the well-formedness of code such as (&amp;ovl)(a, b,
c). GCC rejects the code, while EDG accepts it. On further study of the
standard, I see no support for EDG's position: in particular, C++
[over.over] does not list this as a context where we can take the
address of an overloaded function, C++ [over.call.func] does not
reference the address-of operator at any point, and C++ [expr.call]
claims that the function argument in a call is either a function
lvalue or a pointer-to-function; (&amp;ovl) is neither.

llvm-svn: 118620
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
That bug concerned the well-formedness of code such as (&amp;ovl)(a, b,
c). GCC rejects the code, while EDG accepts it. On further study of the
standard, I see no support for EDG's position: in particular, C++
[over.over] does not list this as a context where we can take the
address of an overloaded function, C++ [over.call.func] does not
reference the address-of operator at any point, and C++ [expr.call]
claims that the function argument in a call is either a function
lvalue or a pointer-to-function; (&amp;ovl) is neither.

llvm-svn: 118620
</pre>
</div>
</content>
</entry>
<entry>
<title>Handle overload resolution when calling an overloaded function set</title>
<updated>2010-11-09T16:13:15+00:00</updated>
<author>
<name>Douglas Gregor</name>
<email>dgregor@apple.com</email>
</author>
<published>2010-11-09T16:13:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=8f225bb5083e190e77c3cd41b936ed36b47b7c80'/>
<id>8f225bb5083e190e77c3cd41b936ed36b47b7c80</id>
<content type='text'>
with, e.g., (&amp;f)(a, b, c). Fixes PR8013.

llvm-svn: 118508
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
with, e.g., (&amp;f)(a, b, c). Fixes PR8013.

llvm-svn: 118508
</pre>
</div>
</content>
</entry>
<entry>
<title>Make -code-completion-patterns only cover multi-line code</title>
<updated>2010-05-28T00:22:41+00:00</updated>
<author>
<name>Douglas Gregor</name>
<email>dgregor@apple.com</email>
</author>
<published>2010-05-28T00:22:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f4c33349b59795c9abb9a661eb0b6eae7b628f72'/>
<id>f4c33349b59795c9abb9a661eb0b6eae7b628f72</id>
<content type='text'>
completions. Plus, tweak a few completion patterns to better reflect
the language grammar.

llvm-svn: 104905
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
completions. Plus, tweak a few completion patterns to better reflect
the language grammar.

llvm-svn: 104905
</pre>
</div>
</content>
</entry>
<entry>
<title>Only enable code patterns (e.g., try { statements } catch (...) {</title>
<updated>2010-05-25T21:41:55+00:00</updated>
<author>
<name>Douglas Gregor</name>
<email>dgregor@apple.com</email>
</author>
<published>2010-05-25T21:41:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f64acca2f50bc4fbe8e2740ca7980b7700f62b40'/>
<id>f64acca2f50bc4fbe8e2740ca7980b7700f62b40</id>
<content type='text'>
statements }) in the code-completion results if explicitly requested.

llvm-svn: 104637
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
statements }) in the code-completion results if explicitly requested.

llvm-svn: 104637
</pre>
</div>
</content>
</entry>
</feed>
