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
(This relands 59337263ab45d7657e and makes sure comma operator
diagnostics are suppressed in a SFINAE context.)
While at it, add the diagnosis message "left operand of comma operator has no effect" (used by GCC) for comma operator.
This also makes Clang diagnose in the constant evaluation context which aligns with GCC/MSVC behavior. (https://godbolt.org/z/7zxb8Tx96)
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D103938
While at it, add the diagnosis message "left operand of comma operator has no effect" (used by GCC) for comma operator.
This also makes Clang diagnose in the constant evaluation context which aligns with GCC/MSVC behavior. (https://godbolt.org/z/7zxb8Tx96)
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D103938
While at it, add the diagnosis message "left operand of comma operator has no effect" (used by GCC) for comma operator.
This also makes Clang diagnose in the constant evaluation context which aligns with GCC/MSVC behavior. (https://godbolt.org/z/7zxb8Tx96)
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D103938
Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expression statements and full expressions in a more generic way when acting on the final expression statement. This results in more appropriate diagnostics for [[nodiscard]] where we were previously lacking them, such as when the body of a for loop is not a compound statement.
This patch fixes PR39837.
llvm-svn: 350404
in macro argument pre-expansion mode when skipping a function body
This commit fixes a token caching problem that currently occurs when clang is
skipping a function body (e.g. when looking for a code completion token) and at
the same time caching the tokens for _Pragma when lexing it in macro argument
pre-expansion mode.
When _Pragma is being lexed in macro argument pre-expansion mode, it caches the
tokens so that it can avoid interpreting the pragma immediately (as the macro
argument may not be used in the macro body), and then either backtracks over or
commits these tokens. The problem is that, when we're backtracking/committing in
such a scenario, there's already a previous backtracking position stored in
BacktrackPositions (as we're skipping the function body), and this leads to a
situation where the cached tokens from the pragma (like '(' 'string_literal'
and ')') will remain in the cached tokens array incorrectly even after they're
consumed (in the case of backtracking) or just ignored (in the case when they're
committed). Furthermore, what makes it even worse, is that because of a previous
backtracking position, the logic that deals with when should we call
ExitCachingLexMode in CachingLex no longer works for us in this situation, and
more tokens in the macro argument get cached, to the point where the EOF token
that corresponds to the macro argument EOF is cached. This problem leads to all
sorts of issues in code completion mode, where incorrect errors get presented
and code completion completely fails to produce completion results.
rdar://28523863
Differential Revision: https://reviews.llvm.org/D28772
llvm-svn: 296140
