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
Somewhat surprisingly, signature help is emitted as a side-effect of
computing the expected type of a function argument.
The reason is that both actions require enumerating the possible
function signatures and running partial overload resolution, and doing
this twice would be wasteful and complicated.
Change #1: document this, it's subtle :-)
However, sometimes we need to compute the expected type without having
reached the code completion cursor yet - in particular to allow
completion of designators.
eb4ab3358cd4dc834a761191b5531b38114f7b13 did this but introduced a
regression - it emits signature help in the wrong location as a side-effect.
Change #2: only emit signature help if the code completion cursor was reached.
Currently there is PP.isCodeCompletionReached(), but we can't use it
because it's set *after* running code completion.
It'd be nice to set this implicitly when the completion token is lexed,
but ConsumeCodeCompletionToken() makes this complicated.
Change #3: call cutOffParsing() *first* when seeing a completion token.
After this, the fact that the Sema::Produce*SignatureHelp() functions
are even more confusing, as they only sometimes do that.
I don't want to rename them in this patch as it's another large
mechanical change, but we should soon.
Change #4: prepare to rename ProduceSignatureHelp() to GuessArgumentType() etc.
Differential Revision: https://reviews.llvm.org/D98488
PreferedType were not set when parsing compound literals, hence
designated initializers were not available as code completion suggestions.
This patch sets the preferedtype to parsed type for the following initializer
list.
Fixes https://github.com/clangd/clangd/issues/142.
Differential Revision: https://reviews.llvm.org/D92370
