With the goal of eventually being able to make `-Wreturn-type` default to an
error in all language modes, this is a follow-up to #123464 and updates even
more tests, mainly clang-tidy and clangd tests.
Reapplies #84050, addressing a bug which cases a crash when an
expression with the type of the current instantiation is used as the
_postfix-expression_ in a class member access expression (arrow form).
Consider the following:
```cpp
template<typename T>
struct A
{
auto f()
{
return this->x;
}
};
```
Although `A` has no dependent base classes and the lookup context for
`x` is the current instantiation, we currently do not diagnose the
absence of a member `x` until `A<T>::f` is instantiated. This patch
moves the point of diagnosis for such expressions to occur at the point
of definition (i.e. prior to instantiation).
This patch introduces the following configurations to .clangd:
```
SemanticTokens:
DisabledKinds: [ ... ]
DisabledModifiers: [ ... ]
```
Based on the config, clangd would stop producing a certain type of semantic tokens from the source file.
Fixes https://github.com/clangd/clangd/discussions/1598
Reviewed By: nridge
Differential Revision: https://reviews.llvm.org/D148489
Extend the existing MainFileMacros structure:
- record more information (InConditionalDirective) in MacroOccurrence
- collect macro references inside macro body (fix a long-time FIXME)
So that the MainFileMacros preseve enough information, which allows a
just-in-time convertion to interop with include-cleaner::Macro for
include-cleaer features.
See the context in https://reviews.llvm.org/D146017.
Differential Revision: https://reviews.llvm.org/D146279
VarTemplateSpecializationDecl does not store a template param list,
so the "template<>" needs to be stored in the ExtInfo.
Differential Revision: https://reviews.llvm.org/D142692
This is needed for clients that would like to visualize matching
opening and closing angle brackets, which can be valuable in non-trivial
template declarations or instantiations.
It is not possible to do this with simple lexing, as the tokens
could also refer to operators.
Reviewed By: kadircet
Differential Revision: https://reviews.llvm.org/D139926
Also add new modifier for differentiating between built-in and user-
provided operators.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D136594
... in semantic highlighting.
These specifiers cannot be identified by simple lexing (since e.g.
variables with these names can legally be declared), which means they
should be semantic tokens.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D137943
Counterpart to "usedAsMutableReference". Just as for references, there
are const and non-const pointer parameters, and it's valuable to be able
to have different highlighting for the two cases at the call site.
We could have re-used the existing modifier, but having a dedicated one
maximizes client flexibility.
Reviewed By: nridge
Differential Revision: https://reviews.llvm.org/D130015
This is useful for clients that want to highlight constructors and
destructors different from classes, e.g. like functions.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D134728
- store NestedNameSpecifier & Loc for the qualifiers
This information was entirely missing from the AST.
- expose the location information for qualifier/identifier/typedefs as typeloc
This allows many traversals/astmatchers etc to handle these generically along
with other references. The decl vs type split can help preserve typedef
sugar when https://github.com/llvm/llvm-project/issues/57659 is resolved.
- fix the SourceRange of UsingEnumDecl to include 'using'.
Fixes https://github.com/clangd/clangd/issues/1283
Differential Revision: https://reviews.llvm.org/D134303
That is, mark constructor parameters being used to initialize
non-const reference members.
Reviewed By: nridge
Differential Revision: https://reviews.llvm.org/D128977
... with the "usedAsMutableReference" semantic token modifier.
It's quite unusual to declare the index parameter of a subscript
operator as a non-const reference type, but arguably that makes it even
more helpful to be aware of it when working with such code.
Reviewed By: nridge
Differential Revision: https://reviews.llvm.org/D128892
There's no reason that arguments to e.g. lambda calls should be treated
differently than those to "real" functions.
Reviewed By: nridge
Differential Revision: https://reviews.llvm.org/D128329
Fixes https://github.com/clangd/clangd/issues/1132
where clangd's semantic highlighting is missing for symbols of a template
specialization definition. It turns out the visitor didn't traverse the
base classes of Class/Var##TemplateSpecializationDecl, i.e.
CXXRecordDecl/VarDecl. This patch adds them back as what is done in
DEF_TRAVERSE_TMPL_PART_SPEC_DECL.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D126757
Even though they're implemented via typedefs, we typically
want to treat them like keywords.
We could add hover information / xrefs, but it's very unlikely
to provide any value.
Differential Revision: https://reviews.llvm.org/D108556
This is needed for clients that want to highlight virtual functions
differently.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D107145
Objective-C lets you use the `self.prop` syntax as sugar for both
`[self prop]` and `[self setProp:]`, but clangd previously did not
provide a semantic token for `prop`.
Now, we provide a semantic token, treating it like a normal property
except it's backed by a `ObjCMethodDecl` instead of a
`ObjCPropertyDecl`.
Differential Revision: https://reviews.llvm.org/D104117
This allows us to differentiate symbols from the system (e.g. system
includes or sysroot) differently than symbols defined in the user's
project, which can be used by editors to display them differently.
This is currently based on `FileCharacteristic`, but we can
consider alternatives such as `Sysroot` and file paths in the future.
Differential Revision: https://reviews.llvm.org/D101554
Treat them just like we do for properties - as a `property` semantic
token although ideally we could differentiate the two.
Differential Revision: https://reviews.llvm.org/D101785
