[clangd] Add distinct highlightings for declarations of functions and methods

[jvikstrom]

Should we have different highlightings for declarations vs usages? (Although I guess in the end it will be up to the editor if they highlight them differently as the scope is just more specific for declarations)
I guess I personally don't really see the reason as it should be clear from the context if it's a declaration or a function call.
But this might actually be nice if you have macros that declare functions

[ilya-biryukov]

In D66990#1652172, @jvikstrom wrote:

Should we have different highlightings for declarations vs usages? (Although I guess in the end it will be up to the editor if they highlight them differently as the scope is just more specific for declarations)
I guess I personally don't really see the reason as it should be clear from the context if it's a declaration or a function call.

I also second the opinion that usages and declarations should be highlighted the same.
Both represent the same thing, therefore they should have the same color.

And this highlighting does not seem to add any extra information too - it's obvious from the code whether a name is a declaration or a usage.
Even in the macro cases, the users usually know the semantics of the macro or can infer from the name.

[nridge]

There is precedent for highlighting declarations and uses differently in other C++ editors. For example, Eclipse CDT has separate highlightings for function and functions declarations (see screenshot below).

Objectively speaking, I think it makes sense to style function declarations differently from function uses for emphasis. For example, you can use the same color for both, but make the declarations bold. I have found this to aid readability.

[ilya-biryukov]

In D66990#1653833, @nridge wrote:

There is precedent for highlighting declarations and uses differently in other C++ editors. For example, Eclipse CDT has separate highlightings for function and functions declarations (see screenshot below).

Acknowledged.

Objectively speaking, I think it makes sense to style function declarations differently from function uses for emphasis. For example, you can use the same color for both, but make the declarations bold. I have found this to aid readability.

As mentioned before, I think doing this:

• adds some confusion: the same thing highlighted in two different colors,
• provides almost zero value: function declarations have completely different syntax from function usages anyway, there are more than enough signals to distinguish them and we don't need semantic highlighting for that.

[ilya-biryukov]

In D66990#1653833, @nridge wrote:

I think it makes sense to style function declarations differently from function uses for emphasis. For example, you can use the same color for both, but make the declarations bold. I have found this to aid readability.

I think this makes sense, but it should be done for all declarations and not just functions.
But doing that in the current design would mean we need to double the number of styles. In addition to field, method, function, we would need field-declaration, method-declaration, function-declaration, etc.
Combinatorial explosion of that kind is bad, so I would rather avoid it.

That would also mean we would rely on every editor to apply consistent styling for this, at least by default: make somethind-decl just like decl but bold.
I don't think there's any way to enforce this.

If there was an alternative design we could use for this that would not cause combinatorial explosion and would allow us to consistently apply the same modifier to different kinds of highlighting (e.g. something that will consistently turn to bold in all editors that support this), I would be supportive of implementing this.

[nridge]

In D66990#1654312, @ilya-biryukov wrote:

I think this makes sense, but it should be done for all declarations and not just functions.
But doing that in the current design would mean we need to double the number of styles. In addition to field, method, function, we would need field-declaration, method-declaration, function-declaration, etc.
Combinatorial explosion of that kind is bad, so I would rather avoid it.

I agree that a combinatorial explosion would be unfortunate. I actually think that having a linear list of semantic highlighting kinds is a weakness of this protocol extension for exactly this reason.

I think the way cquery does it it better in this regard: in place of a single kind enum, they essentially have a 4-tuple of (kind, parent kind, storage class, role). With this setup:

• The kinds can be a relatively small set of fundamental language entity kinds (variable, function, class, namespace, etc.)
• Things like "field" can be expressed as kind = variable, parentKind = class
• The storage class allows differentiating things like static vs. nonstatic without having to introduce distinct kinds for those.
• The role allows differentiating declarations from uses, and even fancier things like read occurrences from write occurrences.

I've been meaning to comment on the upstream protocol proposal to suggest a more flexible approach like this, though I'm not sure how it would integrate with TextMate scopes (which cquery doesn't bother with).

I was hoping though that a patch like this, which would bring us largely to parity with Eclipse CDT's highlightings, wouldn't need to blocked on a change to the upstream protocol proposal, which could take a while.

That would also mean we would rely on every editor to apply consistent styling for this, at least by default: make somethind-decl just like decl but bold.
I don't think there's any way to enforce this.

Keep in mind that since the scopes for declarations just add .declaration to the scopes for the base entities, by default they would be highlighted the same as the base entity. Only if a user or theme goes to the trouble of adding a specific rule for the .declaration, would they look different, and in that case I think we can trust the judgment of the user or theme author.

[ilya-biryukov]

In D66990#1655030, @nridge wrote:

I was hoping though that a patch like this, which would bring us largely to parity with Eclipse CDT's highlightings, wouldn't need to blocked on a change to the upstream protocol proposal, which could take a while.

Is feature parity a hard requirement? Having slightly different highlightings in that case should not be too disruptive.

I think the way cquery does it it better in this regard: in place of a single kind enum, they essentially have a 4-tuple of (kind, parent kind, storage class, role).

A design like this definitely makes more sense. I was thinking of a slightly simpler model: adding a set of "modifiers" to each highlighting should be enough to encode all of it, e.g. a modifier 'is class member' could be used to distinguish methods and fields from global functions and variables, a modifier 'is usage' can be used to distinguish usages from declarations, etc.
But there's no combinatorial explosion in the cquery's model, which is the important bit.

That would also mean we would rely on every editor to apply consistent styling for this, at least by default: make somethind-decl just like decl but bold.
I don't think there's any way to enforce this.

Different designs lead to different interpretations: if we encode this as a separate highlighting kind, there's a greater chance this would be highlighted in different color rather than just applying modifiers.
If we model this as "something in addition to the main highlighting", there's a greater chance this would be interpreted as something that should be "bold".

Agree there is no way to enforce this.

[nridge]

In D66990#1655175, @ilya-biryukov wrote:

In D66990#1655030, @nridge wrote:

I was hoping though that a patch like this, which would bring us largely to parity with Eclipse CDT's highlightings, wouldn't need to blocked on a change to the upstream protocol proposal, which could take a while.

Is feature parity a hard requirement? Having slightly different highlightings in that case should not be too disruptive.

Not a hard requirement, just a nice-to-have for someone moving from one tool to another :)

If you feel that for now it's better not to do this, I can respect that.

I think the way cquery does it it better in this regard: in place of a single kind enum, they essentially have a 4-tuple of (kind, parent kind, storage class, role).

A design like this definitely makes more sense. I was thinking of a slightly simpler model: adding a set of "modifiers" to each highlighting should be enough to encode all of it, e.g. a modifier 'is class member' could be used to distinguish methods and fields from global functions and variables, a modifier 'is usage' can be used to distinguish usages from declarations, etc.
But there's no combinatorial explosion in the cquery's model, which is the important bit.

I will suggest this for the upstream protocol and see where that goes.

[ilya-biryukov]

In D66990#1656230, @nridge wrote:

Not a hard requirement, just a nice-to-have for someone moving from one tool to another :)
If you feel that for now it's better not to do this, I can respect that.

Thanks, if that works for you, I would wait until we get/build a better support in the protocol for this.
If Eclipse CDT gets a lot of user complaints and this turns out to be an important missing feature, happy to reconsider.
FWIW, I find having Eclipse CDT on board to be important for us and therefore happy to make trade-offs when needed.
This is a small thing, though, so waiting for an explicit support for this in the protocol does not sound too bad.

I will suggest this for the upstream protocol and see where that goes.

SG, keep us posted!

[nridge]

In D66990#1656230, @nridge wrote:

I think the way cquery does it it better in this regard: in place of a single kind enum, they essentially have a 4-tuple of (kind, parent kind, storage class, role).

A design like this definitely makes more sense. I was thinking of a slightly simpler model: adding a set of "modifiers" to each highlighting should be enough to encode all of it, e.g. a modifier 'is class member' could be used to distinguish methods and fields from global functions and variables, a modifier 'is usage' can be used to distinguish usages from declarations, etc.
But there's no combinatorial explosion in the cquery's model, which is the important bit.

I will suggest this for the upstream protocol and see where that goes.

For reference, I made this suggestion here.

[nridge]

Abandoning as this was superseded by D77811.

clang-tools-extra/clangd/SemanticHighlighting.h

 namespace clang {
 namespace clangd {
 
 enum class HighlightingKind {
   Variable = 0,
   LocalVariable,
   Parameter,
   Function,
+  FunctionDeclaration,
   Method,
+  MethodDeclaration,
   StaticMethod,
+  StaticMethodDeclaration,
   Field,
   StaticField,
   Class,
   Enum,
   EnumConstant,
   Namespace,
   TemplateParameter,
   Primitive,

clang-tools-extra/clangd/SemanticHighlighting.cpp

if (ND->getDeclName().getNameKind() ==
         DeclarationName::CXXConstructorName) {
       addToken(ND->getLocation(), ND);
       return true;
     }
 
     if (ND->getDeclName().getNameKind() != DeclarationName::Identifier)
       return true;
 
-    addToken(ND->getLocation(), ND);
+    addToken(ND->getLocation(), ND, /*IsDeclaration=*/true);
     return true;
   }
 
   bool VisitDeclRefExpr(DeclRefExpr *Ref) {
     if (Ref->getNameInfo().getName().getNameKind() !=
         DeclarationName::Identifier)
       // Only want to highlight identifiers.
       return true;
if (!TP)
       return;
     if (TP->isBuiltinType())
       // Builtins must be special cased as they do not have a TagDecl.
       addToken(Loc, HighlightingKind::Primitive);
     if (const TagDecl *TD = TP->getAsTagDecl())
       addToken(Loc, TD);
   }
 
-  void addToken(SourceLocation Loc, const NamedDecl *D) {
+  void addToken(SourceLocation Loc, const NamedDecl *D,
+                bool IsDeclaration = false) {
     if (D->getDeclName().isIdentifier() && D->getName().empty())
       // Don't add symbols that don't have any length.
       return;
     // We highlight class decls, constructor decls and destructor decls as
     // `Class` type. The destructor decls are handled in `VisitTypeLoc` (we will
     // visit a TypeLoc where the underlying Type is a CXXRecordDecl).
     if (isa<ClassTemplateDecl>(D)) {
       addToken(Loc, HighlightingKind::Class);
       return;
     }
     if (isa<RecordDecl>(D)) {
       addToken(Loc, HighlightingKind::Class);
       return;
     }
     if (isa<CXXConstructorDecl>(D)) {
       addToken(Loc, HighlightingKind::Class);
       return;
     }
     if (auto *MD = dyn_cast<CXXMethodDecl>(D)) {
+      if (IsDeclaration) {
+        addToken(Loc, MD->isStatic() ? HighlightingKind::StaticMethodDeclaration
+                                     : HighlightingKind::MethodDeclaration);
+        return;
+      }
       addToken(Loc, MD->isStatic() ? HighlightingKind::StaticMethod
                                    : HighlightingKind::Method);
       return;
     }
     if (isa<FieldDecl>(D)) {
       addToken(Loc, HighlightingKind::Field);
       return;
     }
     if (isa<EnumDecl>(D)) {
       addToken(Loc, HighlightingKind::Enum);
       return;
     }
     if (isa<EnumConstantDecl>(D)) {
       addToken(Loc, HighlightingKind::EnumConstant);
       return;
     }
     if (isa<ParmVarDecl>(D)) {
       addToken(Loc, HighlightingKind::Parameter);
       return;
     }
-    if (const VarDecl *VD = dyn_cast<VarDecl>(D)) {
+    if (auto *VD = dyn_cast<VarDecl>(D)) {
       addToken(Loc, VD->isStaticDataMember()
                         ? HighlightingKind::StaticField
                         : VD->isLocalVarDecl() ? HighlightingKind::LocalVariable
                                                : HighlightingKind::Variable);
       return;
     }
     if (isa<FunctionDecl>(D)) {
-      addToken(Loc, HighlightingKind::Function);
+      addToken(Loc, IsDeclaration ? HighlightingKind::FunctionDeclaration
+                                  : HighlightingKind::Function);
       return;
     }
     if (isa<NamespaceDecl>(D)) {
       addToken(Loc, HighlightingKind::Namespace);
       return;
     }
     if (isa<NamespaceAliasDecl>(D)) {
       addToken(Loc, HighlightingKind::Namespace);
toSemanticHighlightingInformation(llvm::ArrayRef<LineHighlightings> Tokens) {
   return Lines;
 }
 
 llvm::StringRef toTextMateScope(HighlightingKind Kind) {
   // FIXME: Add scopes for C and Objective C.
   switch (Kind) {
   case HighlightingKind::Function:
     return "entity.name.function.cpp";
+  case HighlightingKind::FunctionDeclaration:
+    return "entity.name.function.declaration.cpp";
   case HighlightingKind::Method:
     return "entity.name.function.method.cpp";
+  case HighlightingKind::MethodDeclaration:
+    return "entity.name.function.method.declaration.cpp";
   case HighlightingKind::StaticMethod:
     return "entity.name.function.method.static.cpp";
+  case HighlightingKind::StaticMethodDeclaration:
+    return "entity.name.function.method.static.declaration.cpp";
   case HighlightingKind::Variable:
     return "variable.other.cpp";
   case HighlightingKind::LocalVariable:
     return "variable.other.local.cpp";
   case HighlightingKind::Parameter:
     return "variable.parameter.cpp";
   case HighlightingKind::Field:
     return "variable.other.field.cpp";

clang-tools-extra/clangd/test/semantic-highlighting.test

 # CHECK-NEXT:          ],
 # CHECK-NEXT:          [
 # CHECK-NEXT:            "variable.parameter.cpp"
 # CHECK-NEXT:          ],
 # CHECK-NEXT:          [
 # CHECK-NEXT:            "entity.name.function.cpp"
 # CHECK-NEXT:          ],
 # CHECK-NEXT:          [
+# CHECK-NEXT:            "entity.name.function.declaration.cpp"
+# CHECK-NEXT:          ],
+# CHECK-NEXT:          [
 # CHECK-NEXT:            "entity.name.function.method.cpp"
 # CHECK-NEXT:          ],
 # CHECK-NEXT:          [
+# CHECK-NEXT:            "entity.name.function.method.declaration.cpp"
+# CHECK-NEXT:          ],
+# CHECK-NEXT:          [
 # CHECK-NEXT:            "entity.name.function.method.static.cpp"
 # CHECK-NEXT:          ],
 # CHECK-NEXT:          [
+# CHECK-NEXT:            "entity.name.function.method.static.declaration.cpp"
+# CHECK-NEXT:          ],
+# CHECK-NEXT:          [
 # CHECK-NEXT:            "variable.other.field.cpp"
 # CHECK-NEXT:          ],
 # CHECK-NEXT:          [
 # CHECK-NEXT:            "variable.other.field.static.cpp"
 # CHECK-NEXT:          ],
 # CHECK-NEXT:          [
 # CHECK-NEXT:            "entity.name.type.class.cpp"
 # CHECK-NEXT:          ],

 # CHECK-NEXT:      },
 ---
 {"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///foo.cpp","languageId":"cpp","version":1,"text":"int x = 2;"}}}
 #      CHECK:  "method": "textDocument/semanticHighlighting",
 # CHECK-NEXT:  "params": {
 # CHECK-NEXT:    "lines": [
 # CHECK-NEXT:      {
 # CHECK-NEXT:        "line": 0,
-# CHECK-NEXT:        "tokens": "AAAAAAADAA0AAAAEAAEAAA=="
+# CHECK-NEXT:        "tokens": "AAAAAAADABAAAAAEAAEAAA=="
 # CHECK-NEXT:      }
 # CHECK-NEXT:    ],
 # CHECK-NEXT:    "textDocument": {
 # CHECK-NEXT:      "uri": "file:///clangd-test/foo.cpp"
 # CHECK-NEXT:    }
 # CHECK-NEXT:  }
 # CHECK-NEXT:}
 ---
 {"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///foo2.cpp","languageId":"cpp","version":1,"text":"int x = 2;\nint y = 2;"}}}
 #      CHECK:  "method": "textDocument/semanticHighlighting",
 # CHECK-NEXT:  "params": {
 # CHECK-NEXT:    "lines": [
 # CHECK-NEXT:      {
 # CHECK-NEXT:        "line": 0,
-# CHECK-NEXT:        "tokens": "AAAAAAADAA0AAAAEAAEAAA=="
+# CHECK-NEXT:        "tokens": "AAAAAAADABAAAAAEAAEAAA=="
 # CHECK-NEXT:      }
 # CHECK-NEXT:      {
 # CHECK-NEXT:        "line": 1,
-# CHECK-NEXT:        "tokens": "AAAAAAADAA0AAAAEAAEAAA=="
+# CHECK-NEXT:        "tokens": "AAAAAAADABAAAAAEAAEAAA=="
 # CHECK-NEXT:      }
 # CHECK-NEXT:    ],
 # CHECK-NEXT:    "textDocument": {
 # CHECK-NEXT:      "uri": "file:///clangd-test/foo2.cpp"
 # CHECK-NEXT:    }
 # CHECK-NEXT:  }
 # CHECK-NEXT:}
 ---
 {"jsonrpc":"2.0","method":"textDocument/didChange","params":{"textDocument":{"uri":"test:///foo.cpp","version":2},"contentChanges": [{"range":{"start": {"line": 0,"character": 10},"end": {"line": 0,"character": 10}},"rangeLength": 0,"text": "\nint y = 2;"}]}}
 #      CHECK:  "method": "textDocument/semanticHighlighting",
 # CHECK-NEXT:  "params": {
 # CHECK-NEXT:    "lines": [
 # CHECK-NEXT:      {
 # CHECK-NEXT:        "line": 1,
-# CHECK-NEXT:        "tokens": "AAAAAAADAA0AAAAEAAEAAA=="
+# CHECK-NEXT:        "tokens": "AAAAAAADABAAAAAEAAEAAA=="
 # CHECK-NEXT:      }
 # CHECK-NEXT:   ],
 # CHECK-NEXT:    "textDocument": {
 # CHECK-NEXT:      "uri": "file:///clangd-test/foo.cpp"
 # CHECK-NEXT:    }
 # CHECK-NEXT:  }
 # CHECK-NEXT:}
 ---

clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

 }
 
 std::vector<HighlightingToken> getExpectedTokens(Annotations &Test) {
   static const std::map<HighlightingKind, std::string> KindToString{
       {HighlightingKind::Variable, "Variable"},
       {HighlightingKind::LocalVariable, "LocalVariable"},
       {HighlightingKind::Parameter, "Parameter"},
       {HighlightingKind::Function, "Function"},
+      {HighlightingKind::FunctionDeclaration, "FunctionDeclaration"},
       {HighlightingKind::Class, "Class"},
       {HighlightingKind::Enum, "Enum"},
       {HighlightingKind::Namespace, "Namespace"},
       {HighlightingKind::EnumConstant, "EnumConstant"},
       {HighlightingKind::Field, "Field"},
       {HighlightingKind::StaticField, "StaticField"},
       {HighlightingKind::Method, "Method"},
+      {HighlightingKind::MethodDeclaration, "MethodDeclaration"},
       {HighlightingKind::StaticMethod, "StaticMethod"},
+      {HighlightingKind::StaticMethodDeclaration, "StaticMethodDeclaration"},
       {HighlightingKind::TemplateParameter, "TemplateParameter"},
       {HighlightingKind::Primitive, "Primitive"}};
   std::vector<HighlightingToken> ExpectedTokens;
   for (const auto &KindString : KindToString) {
     std::vector<HighlightingToken> Toks = makeHighlightingTokens(
         Test.ranges(KindString.second), KindString.first);
     ExpectedTokens.insert(ExpectedTokens.end(), Toks.begin(), Toks.end());
   }

 TEST(SemanticHighlighting, GetsCorrectTokens) {
   const char *TestCases[] = {
       R"cpp(
       struct $Class[[AS]] {
         $Primitive[[double]] $Field[[SomeMember]];
       };
       struct {
       } $Variable[[S]];
-      $Primitive[[void]] $Function[[foo]]($Primitive[[int]] $Parameter[[A]], $Class[[AS]] $Parameter[[As]]) {
+      $Primitive[[void]] $FunctionDeclaration[[foo]]($Primitive[[int]] $Parameter[[A]], $Class[[AS]] $Parameter[[As]]) {
         $Primitive[[auto]] $LocalVariable[[VeryLongVariableName]] = 12312;
         $Class[[AS]]     $LocalVariable[[AA]];
         $Primitive[[auto]] $LocalVariable[[L]] = $LocalVariable[[AA]].$Field[[SomeMember]] + $Parameter[[A]];
         auto $LocalVariable[[FN]] = [ $LocalVariable[[AA]]]($Primitive[[int]] $Parameter[[A]]) -> $Primitive[[void]] {};
         $LocalVariable[[FN]](12312);
       }
     )cpp",
       R"cpp(
-      $Primitive[[void]] $Function[[foo]]($Primitive[[int]]);
-      $Primitive[[void]] $Function[[Gah]]();
-      $Primitive[[void]] $Function[[foo]]() {
+      $Primitive[[void]] $FunctionDeclaration[[foo]]($Primitive[[int]]);
+      $Primitive[[void]] $FunctionDeclaration[[Gah]]();
+      $Primitive[[void]] $FunctionDeclaration[[foo]]() {
         auto $LocalVariable[[Bou]] = $Function[[Gah]];
       }
       struct $Class[[A]] {
-        $Primitive[[void]] $Method[[abc]]();
+        $Primitive[[void]] $MethodDeclaration[[abc]]();
       };
     )cpp",
       R"cpp(
       namespace $Namespace[[abc]] {
         template<typename $TemplateParameter[[T]]>
         struct $Class[[A]] {
           $TemplateParameter[[T]] $Field[[t]];
         };
       }
       template<typename $TemplateParameter[[T]]>
       struct $Class[[C]] : $Namespace[[abc]]::$Class[[A]]<$TemplateParameter[[T]]> {
         typename $TemplateParameter[[T]]::A* $Field[[D]];
       };
       $Namespace[[abc]]::$Class[[A]]<$Primitive[[int]]> $Variable[[AA]];
       typedef $Namespace[[abc]]::$Class[[A]]<$Primitive[[int]]> $Class[[AAA]];
       struct $Class[[B]] {
         $Class[[B]]();
         ~$Class[[B]]();
         $Primitive[[void]] operator<<($Class[[B]]);
         $Class[[AAA]] $Field[[AA]];
       };
       $Class[[B]]::$Class[[B]]() {}
       $Class[[B]]::~$Class[[B]]() {}
-      $Primitive[[void]] $Function[[f]] () {
+      $Primitive[[void]] $FunctionDeclaration[[f]] () {
         $Class[[B]] $LocalVariable[[BB]] = $Class[[B]]();
         $LocalVariable[[BB]].~$Class[[B]]();
         $Class[[B]]();
       }
     )cpp",
       R"cpp(
       enum class $Enum[[E]] {
         $EnumConstant[[A]],
)cpp",
       R"cpp(
       struct $Class[[D]] {
         $Primitive[[double]] $Field[[C]];
       };
       struct $Class[[A]] {
         $Primitive[[double]] $Field[[B]];
         $Class[[D]] $Field[[E]];
         static $Primitive[[double]] $StaticField[[S]];
-        static $Primitive[[void]] $StaticMethod[[bar]]() {}
-        $Primitive[[void]] $Method[[foo]]() {
+        static $Primitive[[void]] $StaticMethodDeclaration[[bar]]() {}
+        $Primitive[[void]] $MethodDeclaration[[foo]]() {
           $Field[[B]] = 123;
           this->$Field[[B]] = 156;
           this->$Method[[foo]]();
           $Method[[foo]]();
           $StaticMethod[[bar]]();
           $StaticField[[S]] = 90.1;
         }
       };
-      $Primitive[[void]] $Function[[foo]]() {
+      $Primitive[[void]] $FunctionDeclaration[[foo]]() {
         $Class[[A]] $LocalVariable[[AA]];
         $LocalVariable[[AA]].$Field[[B]] += 2;
         $LocalVariable[[AA]].$Method[[foo]]();
         $LocalVariable[[AA]].$Field[[E]].$Field[[C]];
         $Class[[A]]::$StaticField[[S]] = 90;
       }
     )cpp",
       R"cpp(
)cpp",
         typedef $Primitive[[char]] $Primitive[[C]];
       }
       typedef $Namespace[[a]]::$Class[[A]] $Class[[B]];
       using $Class[[BB]] = $Namespace[[a]]::$Class[[A]];
       enum class $Enum[[E]] {};
       typedef $Enum[[E]] $Enum[[C]];
       typedef $Enum[[C]] $Enum[[CC]];
       using $Enum[[CD]] = $Enum[[CC]];
-      $Enum[[CC]] $Function[[f]]($Class[[B]]);
-      $Enum[[CD]] $Function[[f]]($Class[[BB]]);
+      $Enum[[CC]] $FunctionDeclaration[[f]]($Class[[B]]);
+      $Enum[[CD]] $FunctionDeclaration[[f]]($Class[[BB]]);
       typedef $Namespace[[a]]::$Primitive[[C]] $Primitive[[PC]];
       typedef $Primitive[[float]] $Primitive[[F]];
     )cpp",
       R"cpp(
       template<typename $TemplateParameter[[T]], typename = $Primitive[[void]]>
       class $Class[[A]] {
         $TemplateParameter[[T]] $Field[[AA]];
-        $TemplateParameter[[T]] $Method[[foo]]();
+        $TemplateParameter[[T]] $MethodDeclaration[[foo]]();
       };
       template<class $TemplateParameter[[TT]]>
       class $Class[[B]] {
         $Class[[A]]<$TemplateParameter[[TT]]> $Field[[AA]];
       };
       template<class $TemplateParameter[[TT]], class $TemplateParameter[[GG]]>
       class $Class[[BB]] {};
       template<class $TemplateParameter[[T]]>
       class $Class[[BB]]<$TemplateParameter[[T]], $Primitive[[int]]> {};
       template<class $TemplateParameter[[T]]>
       class $Class[[BB]]<$TemplateParameter[[T]], $TemplateParameter[[T]]*> {};
 
       template<template<class> class $TemplateParameter[[T]], class $TemplateParameter[[C]]>
-      $TemplateParameter[[T]]<$TemplateParameter[[C]]> $Function[[f]]();
+      $TemplateParameter[[T]]<$TemplateParameter[[C]]> $FunctionDeclaration[[f]]();
 
       template<typename>
       class $Class[[Foo]] {};
 
       template<typename $TemplateParameter[[T]]>
-      $Primitive[[void]] $Function[[foo]]($TemplateParameter[[T]] ...);
+      $Primitive[[void]] $FunctionDeclaration[[foo]]($TemplateParameter[[T]] ...);
     )cpp",
       R"cpp(
       template <class $TemplateParameter[[T]]>
       struct $Class[[Tmpl]] {$TemplateParameter[[T]] $Field[[x]] = 0;};
       extern template struct $Class[[Tmpl]]<$Primitive[[float]]>;
       template struct $Class[[Tmpl]]<$Primitive[[double]]>;
     )cpp",
       // This test is to guard against highlightings disappearing when using
       // conversion operators as their behaviour in the clang AST differ from
       // other CXXMethodDecls.
       R"cpp(
       class $Class[[Foo]] {};
       struct $Class[[Bar]] {
         explicit operator $Class[[Foo]]*() const;
         explicit operator $Primitive[[int]]() const;
         operator $Class[[Foo]]();
       };
-      $Primitive[[void]] $Function[[f]]() {
+      $Primitive[[void]] $FunctionDeclaration[[f]]() {
         $Class[[Bar]] $LocalVariable[[B]];
         $Class[[Foo]] $LocalVariable[[F]] = $LocalVariable[[B]];
         $Class[[Foo]] *$LocalVariable[[FP]] = ($Class[[Foo]]*)$LocalVariable[[B]];
         $Primitive[[int]] $LocalVariable[[I]] = ($Primitive[[int]])$LocalVariable[[B]];
       }
     )cpp"
       R"cpp(
       struct $Class[[B]] {};
)cpp",
       R"cpp(
       class $Class[[G]] {};
       template<$Class[[G]] *$TemplateParameter[[U]]>
       class $Class[[GP]] {};
       template<$Class[[G]] &$TemplateParameter[[U]]>
       class $Class[[GR]] {};
       template<$Primitive[[int]] *$TemplateParameter[[U]]>
       class $Class[[IP]] {
-        $Primitive[[void]] $Method[[f]]() {
+        $Primitive[[void]] $MethodDeclaration[[f]]() {
           *$TemplateParameter[[U]] += 5;
         }
       };
       template<$Primitive[[unsigned]] $TemplateParameter[[U]] = 2>
       class $Class[[Foo]] {
-        $Primitive[[void]] $Method[[f]]() {
+        $Primitive[[void]] $MethodDeclaration[[f]]() {
           for($Primitive[[int]] $LocalVariable[[I]] = 0;
             $LocalVariable[[I]] < $TemplateParameter[[U]];) {}
         }
       };
 
       $Class[[G]] $Variable[[L]];
-      $Primitive[[void]] $Function[[f]]() {
+      $Primitive[[void]] $FunctionDeclaration[[f]]() {
         $Class[[Foo]]<123> $LocalVariable[[F]];
         $Class[[GP]]<&$Variable[[L]]> $LocalVariable[[LL]];
         $Class[[GR]]<$Variable[[L]]> $LocalVariable[[LLL]];
       }
     )cpp",
       R"cpp(
       template<typename $TemplateParameter[[T]], 
         $Primitive[[void]] (T::*$TemplateParameter[[method]])($Primitive[[int]])>
       struct $Class[[G]] {
-        $Primitive[[void]] $Method[[foo]](
+        $Primitive[[void]] $MethodDeclaration[[foo]](
             $TemplateParameter[[T]] *$Parameter[[O]]) {
           ($Parameter[[O]]->*$TemplateParameter[[method]])(10);
         }
       };
       struct $Class[[F]] {
-        $Primitive[[void]] $Method[[f]]($Primitive[[int]]);
+        $Primitive[[void]] $MethodDeclaration[[f]]($Primitive[[int]]);
       };
       template<$Primitive[[void]] (*$TemplateParameter[[Func]])()>
       struct $Class[[A]] {
-        $Primitive[[void]] $Method[[f]]() {
+        $Primitive[[void]] $MethodDeclaration[[f]]() {
           (*$TemplateParameter[[Func]])();
         }
       };
 
-      $Primitive[[void]] $Function[[foo]]() {
+      $Primitive[[void]] $FunctionDeclaration[[foo]]() {
         $Class[[F]] $LocalVariable[[FF]];
         $Class[[G]]<$Class[[F]], &$Class[[F]]::$Method[[f]]> $LocalVariable[[GG]];
         $LocalVariable[[GG]].$Method[[foo]](&$LocalVariable[[FF]]);
         $Class[[A]]<$Function[[foo]]> $LocalVariable[[AA]];
     )cpp",
       // Tokens that share a source range but have conflicting Kinds are not
       // highlighted.
       R"cpp(
       #define DEF_MULTIPLE(X) namespace X { class X { int X; }; }
       #define DEF_CLASS(T) class T {};
       DEF_MULTIPLE(XYZ);
       DEF_MULTIPLE(XYZW);
       DEF_CLASS($Class[[A]])
       #define MACRO_CONCAT(X, V, T) T foo##X = V
       #define DEF_VAR(X, V) int X = V
       #define DEF_VAR_T(T, X, V) T X = V
       #define DEF_VAR_REV(V, X) DEF_VAR(X, V)
       #define CPY(X) X
       #define DEF_VAR_TYPE(X, Y) X Y
       #define SOME_NAME variable
       #define SOME_NAME_SET variable2 = 123
       #define INC_VAR(X) X += 2
-      $Primitive[[void]] $Function[[foo]]() {
+      $Primitive[[void]] $FunctionDeclaration[[foo]]() {
         DEF_VAR($LocalVariable[[X]],  123);
         DEF_VAR_REV(908, $LocalVariable[[XY]]);
         $Primitive[[int]] CPY( $LocalVariable[[XX]] );
         DEF_VAR_TYPE($Class[[A]], $LocalVariable[[AA]]);
         $Primitive[[double]] SOME_NAME;
         $Primitive[[int]] SOME_NAME_SET;
         $LocalVariable[[variable]] = 20.1;
         MACRO_CONCAT(var, 2, $Primitive[[float]]);
         DEF_VAR_T($Class[[A]], CPY(CPY($LocalVariable[[Nested]])),
               CPY($Class[[A]]()));
         INC_VAR($LocalVariable[[variable]]);
       }
       $Primitive[[void]] SOME_NAME();
       DEF_VAR($Variable[[XYZ]], 567);
       DEF_VAR_REV(756, $Variable[[AB]]);
 
       #define CALL_FN(F) F();
       #define DEF_FN(F) void F ()
-      DEF_FN($Function[[g]]) {
+      DEF_FN($FunctionDeclaration[[g]]) {
         CALL_FN($Function[[foo]]);
       }
     )cpp",
       R"cpp(
       #define fail(expr) expr
       #define assert(COND) if (!(COND)) { fail("assertion failed" #COND); }
       $Primitive[[int]] $Variable[[x]];
       $Primitive[[int]] $Variable[[y]];
-      $Primitive[[int]] $Function[[f]]();
-      $Primitive[[void]] $Function[[foo]]() {
+      $Primitive[[int]] $FunctionDeclaration[[f]]();
+      $Primitive[[void]] $FunctionDeclaration[[foo]]() {
         assert($Variable[[x]] != $Variable[[y]]);
         assert($Variable[[x]] != $Function[[f]]());
       }
     )cpp"};
   for (const auto &TestCase : TestCases) {
     checkHighlightings(TestCase);
   }
 
EXPECT_THAT(ActualDiff,
               testing::UnorderedElementsAre(
                   testing::AllOf(LineNumber(3), EmptyHighlightings()),
                   testing::AllOf(LineNumber(4), EmptyHighlightings())));
 }
 
 } // namespace
 } // namespace clangd
 } // namespace clang
 No newline at end of file

clang-tools-extra/clangd/unittests/TweakTests.cpp

 namespace {
 
 TWEAK_TEST(SwapIfBranches);
 TEST_F(SwapIfBranchesTest, Test) {
   Context = Function;
   EXPECT_EQ(apply("^if (true) {return 100;} else {continue;}"),
             "if (true) {continue;} else {return 100;}");
   EXPECT_EQ(apply("^if () {return 100;} else {continue;}"),
-            "if () {continue;} else {return 100;}") << "broken condition";
+            "if () {continue;} else {return 100;}")
+      << "broken condition";
   EXPECT_AVAILABLE("^i^f^^(^t^r^u^e^) { return 100; } ^e^l^s^e^ { continue; }");
   EXPECT_UNAVAILABLE("if (true) {^return ^100;^ } else { ^continue^;^ }");
   // Available in subexpressions of the condition;
   EXPECT_THAT("if(2 + [[2]] + 2) { return 2 + 2 + 2; } else {continue;}",
               isAvailable());
   // But not as part of the branches.
   EXPECT_THAT("if(2 + 2 + 2) { return 2 + [[2]] + 2; } else { continue; }",
               Not(isAvailable()));

 TEST_F(RawStringLiteralTest, Test) {
   Context = Expression;
   EXPECT_AVAILABLE(R"cpp(^"^f^o^o^\^n^")cpp");
   EXPECT_AVAILABLE(R"cpp(R"(multi )" ^"token " "str\ning")cpp");
   EXPECT_UNAVAILABLE(R"cpp(^"f^o^o^o")cpp"); // no chars need escaping
   EXPECT_UNAVAILABLE(R"cpp(R"(multi )" ^"token " u8"str\ning")cpp"); // nonascii
   EXPECT_UNAVAILABLE(R"cpp(^R^"^(^multi )" "token " "str\ning")cpp"); // raw
   EXPECT_UNAVAILABLE(R"cpp(^"token\n" __FILE__)cpp"); // chunk is macro
-  EXPECT_UNAVAILABLE(R"cpp(^"a\r\n";)cpp"); // forbidden escape char
+  EXPECT_UNAVAILABLE(R"cpp(^"a\r\n";)cpp");           // forbidden escape char
 
   const char *Input = R"cpp(R"(multi
 token)" "\nst^ring\n" "literal")cpp";
   const char *Output = R"cpp(R"(multi
 token
 string
 literal)")cpp";
   EXPECT_EQ(apply(Input), Output);
const std::vector<std::pair<llvm::StringLiteral, llvm::StringLiteral>>
                              break;
                        }
                  })cpp"},*/
           // Macros
           {R"cpp(#define PLUS(x) x++
                  void f(int a) {
                    int y = PLUS([[1+a]]);
                  })cpp",
            /*FIXME: It should be extracted like this.
             R"cpp(#define PLUS(x) x++
                   void f(int a) {
                     auto dummy = 1+a; int y = PLUS(dummy);
                   })cpp"},*/
            R"cpp(#define PLUS(x) x++
                  void f(int a) {
                    auto dummy = PLUS(1+a); int y = dummy;
                  })cpp"},
           // ensure InsertionPoint isn't inside a macro
           {R"cpp(#define LOOP(x) while (1) {a = x;}
                  void f(int a) {
                    if(1)
                     LOOP(5 + [[3]])
                  })cpp",
            /*FIXME: It should be extracted like this. SelectionTree needs to be
              * fixed for macros.
             R"cpp(#define LOOP(x) while (1) {a = x;}
                 void f(int a) {
                   auto dummy = 3; if(1)
                    LOOP(5 + dummy)
                 })cpp"},*/
            R"cpp(#define LOOP(x) while (1) {a = x;}
                  void f(int a) {
                    auto dummy = LOOP(5 + 3); if(1)
                     dummy
                  })cpp"},
           {R"cpp(#define LOOP(x) do {x;} while(1);
                  void f(int a) {
                    if(1)
const std::vector<std::pair<llvm::StringLiteral, llvm::StringLiteral>>
            R"cpp(struct S {
                    S(int);
                  };
                  S operator+(S, S);
 
                  void f() {
                    auto dummy = S(2) + S(3) + S(4); S x = S(1) + dummy + S(5);
                  })cpp"},
-           // Don't try to analyze across macro boundaries
-           // FIXME: it'd be nice to do this someday (in a safe way)
           {R"cpp(#define ECHO(X) X
                  void f() {
                    int x = 1 + [[ECHO(2 + 3) + 4]] + 5;
                  })cpp",
            R"cpp(#define ECHO(X) X
                  void f() {
                    auto dummy = 1 + ECHO(2 + 3) + 4; int x = dummy + 5;
                  })cpp"},
TEST_F(ExtractVariableTest, Test) {
   }
 }
 
 TWEAK_TEST(AnnotateHighlightings);
 TEST_F(AnnotateHighlightingsTest, Test) {
   EXPECT_AVAILABLE("^vo^id^ ^f(^) {^}^"); // available everywhere.
   EXPECT_AVAILABLE("[[int a; int b;]]");
   EXPECT_EQ("/* storage.type.primitive.cpp */void "
-            "/* entity.name.function.cpp */f() {}",
+            "/* entity.name.function.declaration.cpp */f() {}",
             apply("void ^f() {}"));
 
   EXPECT_EQ(apply("[[void f1(); void f2();]]"),
             "/* storage.type.primitive.cpp */void "
-            "/* entity.name.function.cpp */f1(); "
+            "/* entity.name.function.declaration.cpp */f1(); "
             "/* storage.type.primitive.cpp */void "
-            "/* entity.name.function.cpp */f2();");
+            "/* entity.name.function.declaration.cpp */f2();");
 
   EXPECT_EQ(apply("void f1(); void f2() {^}"),
             "void f1(); "
             "/* storage.type.primitive.cpp */void "
-            "/* entity.name.function.cpp */f2() {}");
+            "/* entity.name.function.declaration.cpp */f2() {}");
 }
 
 TWEAK_TEST(ExpandMacro);
 TEST_F(ExpandMacroTest, Test) {
   Header = R"cpp(
     #define FOO 1 2 3
     #define FUNC(X) X+X+X
     #define EMPTY
TEST_F(ExpandAutoTypeTest, Test) {
   // function pointers should not be replaced
   EXPECT_THAT(apply("au^to x = &ns::Func;"),
               StartsWith("fail: Could not expand type of function pointer"));
   // lambda types are not replaced
   EXPECT_THAT(apply("au^to x = []{};"),
               StartsWith("fail: Could not expand type of lambda expression"));
   // inline namespaces
   EXPECT_EQ(apply("au^to x = inl_ns::Visible();"),
-              "Visible x = inl_ns::Visible();");
   // local class
   EXPECT_EQ(apply("namespace x { void y() { struct S{}; ^auto z = S(); } }"),
             "namespace x { void y() { struct S{}; S z = S(); } }");
   // replace array types
   EXPECT_EQ(apply(R"cpp(au^to x = "test")cpp"),
             R"cpp(const char * x = "test")cpp");
 }