Dummy is a word with inappropriate associations. This patch updates the
references to it in clangd code base with more precise ones.
The only user-visible change is the default variable name used when extracting a
variable. It will be named as `placeholder` from now on.
Differential Revision: https://reviews.llvm.org/D99065
GCC warning:
```
/llvm-project/clang-tools-extra/clangd/SemanticHighlighting.cpp: In function ‘bool clang::clangd::{anonymous}::canHighlightName(clang::DeclarationName)’:
/llvm-project/clang-tools-extra/clangd/SemanticHighlighting.cpp:64:1: warning: control reaches end of non-void function [-Wreturn-type]
64 | }
| ^
```
- highlight references to protocols in class/protocol/extension decls
- support multi-token selector highlights in semantic + xref highlights
(method calls and declarations only)
- In `@interface I(C)`, I now references the interface and C the category
- highlight uses of interfaces as types
- added semantic highlightings of protocol names (as "interface") and
category names (as "namespace").
These are both standard kinds, maybe "extension" will be standardized...
- highlight `auto` as "class" when it resolves to an ObjC pointer
- don't highlight `self` as a variable even though the AST models it as one
Not fixed: uses of protocols in type names (needs some refactoring of
unrelated code first)
Differential Revision: https://reviews.llvm.org/D97617
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 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
This patch is a try to fix `WorkspaceSymbols.Macros` test after D93796.
If a macro definition is in the preamble section, then it appears to be in the preamble (static) index and not in the main-file (dynamic) index.
Thus, a such macro could not be found at a symbol search according to the logic that we skip symbols from the static index if the location of these symbols is inside the dynamic index files.
To fix this behavior this patch adds main file macros into the main-file (dynamic) index.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D94477
SmallVector<T> with default size is now the recommended version (D92522).
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D92788
Update clang-tools-extra, clang/tools, clang/unittests to migrate from
`SourceManager::getBuffer`, which returns an always dereferenceable
`MemoryBuffer*`, to `getBufferOrNone` or `getBufferOrFake`, both of
which return a `MemoryBufferRef`, depending on whether the call site was
checking for validity of the buffer. No functionality change intended.
Differential Revision: https://reviews.llvm.org/D89416
Summary:
This returns incremental highlights as a set of edits against the
previous highlights.
Server-side, we compute the full set of highlights, this just saves
wire-format size.
For now, the diff used is trivial: everything from the first change to
the last change is sent as a single edit.
The wire format is grungy - the replacement offset/length refer to
positions in the encoded array instead of the logical list of tokens.
We use token-oriented structs and translating to LSP forms when serializing.
This departs from LSP (but is consistent with semanticTokens today).
Tested in VSCode insiders (with a patched client to enable experimental
features).
Reviewers: hokein
Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77225
llvm/Support/Base64, fix its implementation and provide a decent test suite.
Previous implementation code was using + operator instead of | to combine
results, which is a problem when shifting signed values. (0xFF << 16) is
implicitly converted to a (signed) int, and thus results in 0xffff0000,
h is
negative. Combining negative numbers with a + in that context is not what we
want to do.
This is a recommit of 5a1958f267 with UB removved.
This fixes https://github.com/llvm/llvm-project/issues/149.
Differential Revision: https://reviews.llvm.org/D75057
Move Base64 implementation from clangd/SemanticHighlighting to
llvm/Support/Base64, fix its implementation and provide a decent test suite.
Previous implementation code was using + operator instead of | to combine some
results, which is a problem when shifting signed values. (0xFF << 16) is
implicitly converted to a (signed) int, and thus results in 0xffff0000, which is
negative. Combining negative numbers with a + in that context is not what we
want to do.
This fixes https://github.com/llvm/llvm-project/issues/149.
Differential Revision: https://reviews.llvm.org/D75057
This patch adds the cross references for Macros in the MainFile.
We add references for the main file to the ParsedAST. We query the
references from it using the SymbolID.
Xref outside main file will be added to the index in a separate patch.
Summary:
To keep the logic of finding locations of interesting AST nodes in one
place.
The advantage is better coverage of various AST nodes, both now and in
the future: as new nodes get added to `findExplicitReferences`, semantic
highlighting will automatically pick them up.
The drawback of this change is that we have to traverse declarations
inside our file twice in order to highlight dependent names, 'auto'
and 'decltype'. Hopefully, this should not affect the actual latency
too much, most time should be spent in building the AST and not
traversing it.
Reviewers: hokein
Reviewed By: hokein
Subscribers: nridge, merge_guards_bot, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69673
Summary:
Editors are good at highlightings the keywords themselves.
Note that this only affects highlightings of builtin types spelled out
as keywords in the source code. Highlightings of typedefs to builtin
types are unchanged.
Reviewers: hokein
Reviewed By: hokein
Subscribers: merge_guards_bot, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69431
Summary:
- store all macro references in the ParsedAST;
- unify the two variants of CollectMainFileMacros;
Reviewers: ilya-biryukov
Subscribers: MaskRay, jkorous, mgrang, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67496
llvm-svn: 372725
Summary:
- Functions to compute highlighting kinds for things are separated from
the ones that add highlighting tokens.
This keeps each of them more focused on what they're doing: getting
locations and figuring out the kind of the entity, correspondingly.
- Less special cases in visitor for various nodes.
This change is an NFC.
Reviewers: hokein
Reviewed By: hokein
Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67341
llvm-svn: 372008
Summary:
We still attempt to highlight them as underlying types, but fallback to
the generic 'typedef' highlighting kind if the underlying type is too
complicated.
Reviewers: hokein
Reviewed By: hokein
Subscribers: nridge, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67290
llvm-svn: 371402
Summary:
Template parameters were handled outside `addType`, this led to lack of highlightings for typedefs
to template types.
This was never desirable, we want to highlight our typedefs as their underlying type.
Note that typedefs to more complicated types, like pointers and references are still not highlighted.
Original patch by Johan Vikström.
Reviewers: hokein, jvikstrom
Reviewed By: hokein
Subscribers: nridge, javed.absar, kristof.beyls, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66516
llvm-svn: 371379
Summary:
The latter simplifies the client code by avoiding the need to handle it
as a separate case statement.
Reviewers: hokein
Reviewed By: hokein
Subscribers: nridge, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67277
llvm-svn: 371375
Summary:
Instead of matching lists of highlightings, we annotate input code with
resulting highlightings and diff it against the expected annotated input.
In case of failures, this produces much nicer output in form of text-based
diffs.
Reviewers: hokein
Reviewed By: hokein
Subscribers: nridge, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67274
llvm-svn: 371373
This much better reflects what is (now) in this header.
Maybe a rename to ParsedTU would be an improvement, but that's a much
more invasive change and life is too short.
ClangdUnit is dead, long live ClangdUnitTests!
llvm-svn: 370862
Nathan Ridge