Clang-tidy seems to output color only when printing directly to
terminal, but an option to force color-output has been added in
https://reviews.llvm.org/D7947
Now, given `template <typename T> foo() {}` when user types `fo^<int>()` the
completion snippet will not contain `<int>()`.
Also, when the next token is opening parenthesis (`(`) and completion snippet
contains template argument list, it is still emitted.
This patch complements D81380.
Related issue: https://github.com/clangd/clangd/issues/387
Reviewed By: kadircet
Differential Revision: https://reviews.llvm.org/D89870
Some URI scheme needs the hint path to do a correct resolution, we pass
one of the open files as hint path.
This is not perfect, and it might not work for opening files across
project, but it would fix a bug with our internal scheme.
in the long run, removing URIs from all the index internals is a more proper fix.
Differential Revision: https://reviews.llvm.org/D96844
Because it no longer relies on finding implicit casts, this check now
works on templates which are not instantiated in the translation unit.
Differential Revision: https://reviews.llvm.org/D96138
The redundancy around work-done-progress is annoying but ok for now.
There's a weirdness with context lifetimes around outgoing method calls, which
I've preserved to keep this NFC. We should probably fix it though.
Differential Revision: https://reviews.llvm.org/D96717
Path{Match,Exclude} and MountPoint were checking paths case-sensitively
on all platforms, as with other features, this was causing problems on
windows. Since users can have capital drive letters on config files, but
editors might lower-case them.
This patch addresses that issue by:
- Creating regexes with case-insensitive matching on those platforms.
- Introducing a new pathIsAncestor helper, which performs checks in a
case-correct manner where needed.
Differential Revision: https://reviews.llvm.org/D96690
The patch also does some cleanup on the interface of the entry
points from TargetFinder into the heuristic resolution code.
Since the heuristic resolver is created in a place where the
ASTContext is available, it can store the ASTContext and the
NameFactory hack can be removed.
Differential revision: https://reviews.llvm.org/D92290
This is NFC because the MessageHandler refused to dispatch to them until the
server is initialized anyway.
This is a more natural time to bind them - it's when they become callable, and
it's when client capabalities are available and server ones can be set.
One module-lifecycle function will be responsible for all three.
Differential Revision: https://reviews.llvm.org/D96608
The goal is to allow the LSP bindings of features to be defined outside
the ClangdLSPServer class, turning it into less of a monolith.
Differential Revision: https://reviews.llvm.org/D96544
In clangd-12 the ability to override what clang tidy checks should run was moved into config.
For the 13 release its a wise progression to remove the command line option for this.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D96508
Currently Clang tidy provider searches from the root directory up to the target directory, this is the opposite of how clang-tidy searches for config files.
The result of this is .clang-tidy files are ignored in any subdirectory of a directory containing a .clang-tidy file.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D96204
Currently, all include insertions are directed to the main file. However,
Transformer rules can specify alternative destinations for include
insertions. This patch fixes the code to associate the include with the correct
file.
This patch was tested manually. The clang tidy unit test framework does not
support testing changes to header files. Given that this is a bug fix for a live
bug, the patch relies on manual testing rather than blocking on upgrading the
unit test framework.
Differential Revision: https://reviews.llvm.org/D96542
- Instead of `AppDelegate::application:didFinishLaunchingWithOptions:` you
will now see `-[AppDelegate application:didFinishLaunchingWithOptions:]`
- Also include categories in the name when printing the scopes, e.g. `Class(Category)` and `-[Class(Category) method]`
Differential Revision: https://reviews.llvm.org/D68590
This patch only focuses on the flag. Removing actual single-file mode
(and the flag in RenameOption) will come in a follow-up.
Differential Revision: https://reviews.llvm.org/D96495
In addition to wall time etc. this should allow us to get less noisy
values for time measurements.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D96049
Today, inside a template, you can get completion for:
Foo<T> t;
t.^
t has dependent type Foo<T>, and we use the primary template to find its members.
However we also want this to work:
t.foo.bar().^
The type of t.foo.bar() is DependentTy, so we attempt to resolve using similar
heuristics (e.g. primary template).
Differential Revision: https://reviews.llvm.org/D96376
This is obsoleted by the standard semanticTokens request family.
As well as the protocol details, this allows us to remove a bunch of plumbing
around pushing highlights to clients.
This should not land until the new protocol has feature parity, see D77702.
Differential Revision: https://reviews.llvm.org/D95576
This change makes dependentName a modifier, rather than a token type.
It can be combined with:
- type (new, standard) - this combination replaces dependentType like T::typename Foo
- unknown (new, nonstandard) - for general dependent names
- Field, etc - when the name is dependent but we heuristically resolve it
While here, fix cases where template-template-parameter cases were
incorrectly flagged as type-dependent.
And the merging of modifiers when resolving conflicts accidentally
happens to work around a bug that showed up in a test.
The behavior observed through the pre-standard protocol should be mostly
unchanged (it'll see the bugfixes only). This is done in a somehat
fragile way but it's not expected to live long.
Differential Revision: https://reviews.llvm.org/D95706
These allow (function-) local variables to be distinguished, but also a
bunch more cases.
It's not quite independent with existing information (e.g. the
field/variable distinction is redundant if you have class-scope + static
attributes) but I don't think this is terribly important.
Depends on D77811
Differential Revision: https://reviews.llvm.org/D95701
- Infrastructure to support modifiers (protocol etc)
- standard modifiers:
- declaration (but no definition, yet)
- deprecated
- readonly (based on a fairly fuzzy const checking)
- static (for class members and locals, but *not* file-scope things!)
- abstract (for C++ classes, and pure-virtual methods)
- nonstandard modifier:
- deduced (on "auto" whose Kind is Class etc)
Happy to drop this if it's controversial at all.
- While here, update sample tweak to use our internal names, in
anticipation of theia TM scopes going away.
This addresses some of the goals of D77702, but leaves some things undone.
Mostly because I think these will want some discussion.
- no split between dependent type/name.
(We may want to model this as a modifier, type+dependent vs ???+dependent)
- no split between primitive/typedef.
(Is introducing a nonstandard kind is worth this distinction?)
- no nonstandard local attribute
This probably makes sense, I'm wondering if we want others and how
they fit together.
There's one minor regression in explicit template specialization declarations
due to a latent bug in findExplicitReferences, but fixing it after seems OK.
Differential Revision: https://reviews.llvm.org/D77811
`clang-tidy -std=c++20` with `modernize-use-nullptr` mistakenly inserts `nullptr` in place of the comparison operator if the comparison internally expands in the AST to a rewritten spaceship operator. This can be reproduced by running the new `modernize-use-nullptr-cxx20.cpp` test without applying the supplied patch to `UseNullptrCheck.cpp`; the current clang-tidy will mistakenly replace:
```result = (a1 < a2);```
with
```result = (a1 nullptr a2);```
Reviewed By: njames93
Differential Revision: https://reviews.llvm.org/D95714
`modernize-loop-convert` handles //array-like// objects like vectors fairly well, but strips slightly too much information from the iteration expression by converting:
```
Vector<Vector<int>> X;
for (int J = 0; J < X[5].size(); ++J)
copyArg(X[5][J]);
```
to
```
Vector<Vector<int>> X;
for (int J : X) // should be for (int J : X[5])
copyArg(J);
```
The `[5]` is a call to `operator[]` and gets stripped by `LoopConvertCheck::getContainerString`. This patch fixes that and adds several test cases.
Reviewed By: njames93
Differential Revision: https://reviews.llvm.org/D95771
The new trace event includes what's already in the queue when adding.
For tracers that follow contexts, the trace event will span the time that the action
spends in the queue.
For tracers that follow threads, the trace will be a tiny span on the enqueuing thread.
Differential Revision: https://reviews.llvm.org/D96027
Use IgnoreUnlessSpelledInSource to make the matcher code smaller and
more visibly-related to the code.
Differential Revision: https://reviews.llvm.org/D91303
Current indexes merge logic skip data from the static index if the file is in the dynamic index, but sometimes the dynamic index does not contain references (e.g. preamble (dynamic) index vs background (static) index).
This problem is masked with the fact, that the preamble index file list consists of file URI's and other indexes file lists consist of file paths.
This patch introduces the index contents (symbols, references, etc.), which makes indexes merge more flexible and makes it able to use URI's for the index file list.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D94952
Follow-up on D95925: adds better detection for function arguments and also
checks for conflicts in muli-variable init statements in ForStmt.
Reviewed By: hokein
Differential Revision: https://reviews.llvm.org/D96009
This patch allows detecting conflicts with variables defined in the current
CompoundStmt or If/While/For variable init statements.
Reviewed By: hokein
Differential Revision: https://reviews.llvm.org/D95925
Use mapAnyOf() and matchers based on it.
Use of binaryOperation() means that modernize-loop-convert and
readability-container-size-empty can now be used with rewritten binary
operators.
Differential Revision: https://reviews.llvm.org/D94131
lightmelodies