[PATCH] D143260: [clangd] Add semantic token for labels

[Christian Kandeler via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe72baa76b91f: [clangd] Add semantic token for labels 
(authored by ckandeler).

Changed prior to commit:
  https://reviews.llvm.org/D143260?vs=494583&id=529234#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143260/new/

https://reviews.llvm.org/D143260

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -1028,6 +1028,16 @@
 template $Bracket[[<]]$Concept[[C2]]$Bracket[[<]]int$Bracket[[>]] 
$TemplateParameter_def[[A]]$Bracket[[>]]
 class $Class_def[[B]] {};
   )cpp",
+  // Labels
+  R"cpp(
+bool $Function_def[[funcWithGoto]](bool $Parameter_def[[b]]) {
+  if ($Parameter[[b]])
+goto $Label[[return_true]];
+  return false;
+  $Label_decl[[return_true]]:
+return true;
+}
+  )cpp",
   // no crash
   R"cpp(
 struct $Class_def[[Foo]] {
Index: clang-tools-extra/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/clangd/SemanticHighlighting.h
+++ clang-tools-extra/clangd/SemanticHighlighting.h
@@ -52,6 +52,7 @@
   Modifier,
   Operator,
   Bracket,
+  Label,
 
   // This one is different from the other kinds as it's a line style
   // rather than a token style.
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -166,6 +166,8 @@
 return HighlightingKind::TemplateParameter;
   if (isa(D))
 return HighlightingKind::Concept;
+  if (isa(D))
+return HighlightingKind::Label;
   if (const auto *UUVD = dyn_cast(D)) {
 auto Targets = Resolver->resolveUsingValueDecl(UUVD);
 if (!Targets.empty() && Targets[0] != UUVD) {
@@ -1271,6 +1273,8 @@
 return OS << "Operator";
   case HighlightingKind::Bracket:
 return OS << "Bracket";
+  case HighlightingKind::Label:
+return OS << "Label";
   case HighlightingKind::InactiveCode:
 return OS << "InactiveCode";
   }
@@ -1470,6 +1474,8 @@
 return "operator";
   case HighlightingKind::Bracket:
 return "bracket";
+  case HighlightingKind::Label:
+return "label";
   case HighlightingKind::InactiveCode:
 return "comment";
   }


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -1028,6 +1028,16 @@
 template $Bracket[[<]]$Concept[[C2]]$Bracket[[<]]int$Bracket[[>]] $TemplateParameter_def[[A]]$Bracket[[>]]
 class $Class_def[[B]] {};
   )cpp",
+  // Labels
+  R"cpp(
+bool $Function_def[[funcWithGoto]](bool $Parameter_def[[b]]) {
+  if ($Parameter[[b]])
+goto $Label[[return_true]];
+  return false;
+  $Label_decl[[return_true]]:
+return true;
+}
+  )cpp",
   // no crash
   R"cpp(
 struct $Class_def[[Foo]] {
Index: clang-tools-extra/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/clangd/SemanticHighlighting.h
+++ clang-tools-extra/clangd/SemanticHighlighting.h
@@ -52,6 +52,7 @@
   Modifier,
   Operator,
   Bracket,
+  Label,
 
   // This one is different from the other kinds as it's a line style
   // rather than a token style.
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -166,6 +166,8 @@
 return HighlightingKind::TemplateParameter;
   if (isa(D))
 return HighlightingKind::Concept;
+  if (isa(D))
+return HighlightingKind::Label;
   if (const auto *UUVD = dyn_cast(D)) {
 auto Targets = Resolver->resolveUsingValueDecl(UUVD);
 if (!Targets.empty() && Targets[0] != UUVD) {
@@ -1271,6 +1273,8 @@
 return OS << "Operator";
   case HighlightingKind::Bracket:
 return OS << "Bracket";
+  case HighlightingKind::Label:
+return OS << "Label";
   case HighlightingKind::InactiveCode:
 return OS << "InactiveCode";
   }
@@ -1470,6 +1474,8 @@
 return "operator";
   case HighlightingKind::Bracket:
 return "bracket";
+  case Highli

[PATCH] D143260: [clangd] Add semantic token for labels

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet accepted this revision.
kadircet added a comment.
This revision is now accepted and ready to land.

alright then, this patch LGTM. going forward let's try to introduce new kinds 
(or handling for different semantic constructs) in a more holistic manner.

concerns with new language structs are OK, as the language evolves we'll surely 
need to add more highlighting, hopefully we can fit them under existing 
highlight kinds.

(sorry for the late reply)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143260/new/

https://reviews.llvm.org/D143260

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143260: [clangd] Add semantic token for labels

[Christian Kandeler via Phabricator via cfe-commits]

ckandeler added a comment.

In D143260#4328948 , @kadircet wrote:

> Considering that we have added a bunch of token kinds, let me ask you another 
> question then, how many more new token kinds do we expect to have? e.g. if 
> label is the last one sure, but if we plan to have 10 more or if we don't 
> know how many more we would like to have, i think it's better to first come 
> up with a plan and an agreement to make sure we can avoid such discussions 
> with every attempt. does that sound fair?

Speaking for myself, I don't currently have any plans to add further tokens, 
but it's difficult to say with certainty that this will be the last one. For 
instance, new C++ features in future standards might suggest new token types 
(like "concept" for C++20). And if https://github.com/clangd/clangd/issues/1115 
gets implemented, then there will be "string", "number" and "keyword", though 
these are all part of the LSP spec already.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143260/new/

https://reviews.llvm.org/D143260

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143260: [clangd] Add semantic token for labels

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

In D143260#4328948 , @kadircet wrote:

> Considering that we have added a bunch of token kinds, let me ask you another 
> question then, how many more new token kinds do we expect to have? e.g. if 
> label is the last one sure, but if we plan to have 10 more or if we don't 
> know how many more we would like to have, i think it's better to first come 
> up with a plan and an agreement to make sure we can avoid such discussions 
> with every attempt. does that sound fair?

That's a totally fair question.

For my part, I don't have any additional token kinds in mind to add. (The 
suggestion in https://github.com/clangd/clangd/issues/787 to split "template 
parameter" into type vs. non-type is an interesting one, but it's more like a 
nice-to-have enhancement.)

Not sure about Qt Creator, will let @ckandeler chime in on whether he had any 
other token kinds in mind for it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143260/new/

https://reviews.llvm.org/D143260

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143260: [clangd] Add semantic token for labels

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

(sorry for taking so long to get back to this)

In D143260#4270807 , @nridge wrote:

> In the case of labels (and angle brackets (D139926 
> ) and operators (D136594 
> )), the set of users benefiting from them 
> includes presumably "all QtCreator users" (assuming QtCreator assigns a 
> default color to these).

thanks this is useful, i think i know about this reasoning in the previous two 
reviews but wasn't sure about this one.

> You're right that vscode users don't benefit from them unless they configure 
> `semanticTokenColorCustomizations`; in my mind, this is a reason for us to 
> write some vscode themes, rather than to avoid adding new tokens. (I 
> volunteer to write vscode themes if that helps change your mind.)

Vscode is one that we have control over (similar to Qt creator if that helps 
reasoning) but I am afraid customizing vscode too much and assessing impact of 
features with a bias of those customization might hinder usability in the long 
run (also again custom themes etc. doesn't really scale).

> I'm not sure whether you mean LSP-based editors, but if we're counting 
> editors that had "label" as a semantic token type pre-LSP, and are now 
> looking to maintain that through their switch to LSP, then both Eclipse CDT 
> and (I assume) Qt Creator fall into that category.

Considering that we have added a bunch of token kinds, let me ask you another 
question then, how many more new token kinds do we expect to have? e.g. if 
label is the last one sure, but if we plan to have 10 more or if we don't know 
how many more we would like to have, i think it's better to first come up with 
a plan and an agreement to make sure we can avoid such discussions with every 
attempt. does that sound fair?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143260/new/

https://reviews.llvm.org/D143260

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143260: [clangd] Add semantic token for labels

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

In D143260#4267883 , @kadircet wrote:

> I am not sure if access specifiers and label declarations occur in the same 
> context often enough for this mixing to actually cause trouble TBH.

I think the focus on access specifiers is a bit of a distraction, especially 
given the mentioned "labels as values" language extension, which makes possible 
usages of the label of the form `&&labelname` in any expression context 
(producing a pointer value).

In my mind, having a semantic token for labels is a matter of completeness: all 
other identifier tokens get some sort of semantic token depending on what kind 
of `Decl` they resolve to. `LabelDecl` is a kind of `Decl` that can be declared 
as `label:`, and referenced as `goto label` or `&&label` where `label` is 
lexically an identifier token -- so it makes sense for those identifiers to be 
covered by a semantic token as well.

> I believe today we've too low of a bar in clangd's semantic highlighting 
> functionality for introducing "custom" token types, which are probably not 
> used by any people apart from the ones involved in the introduction of the 
> token (we don't have custom themes/scopes even for vscode, we don't even 
> mention them in our user-facing documentation).

In the case of labels (and angle brackets (D139926 
) and operators (D136594 
)), the set of users benefiting from them is 
presumably "all QtCreator users" (assuming QtCreator assigns a default color to 
these).

You're right that vscode users don't benefit from them unless they configure 
`semanticTokenColorCustomizations`; in my mind, this is a reason for us to 
write some vscode themes, rather than to avoid adding new tokens. (I volunteer 
to write vscode themes if that helps change your mind.)

> we'll slowly get into a state in which we're spending time both calculating 
> and emitting all of those token types that are just dropped on the floor

I agree that the volume of semantic tokens is potentially a concern. I think 
it's more of a concern in the case of tokens that occur fairly frequently, like 
operator tokens. (This is why, in the review of D136594 
, I suggested only emitting semantic tokens 
for overloaded operators, since it's distinguishing those from built-in 
operators that's the more interesting use case in highlighting operators.) By 
comparison, label tokens would be relatively rare and thus their overhead would 
be quite small.

> Hence my stance here is still towards "we don't need it", unless we have some 
> big editor(s) that can already recognize "label" as a semantic token type

I'm not sure whether you mean LSP-based editors, but if we're counting editors 
that had "label" as a semantic token type pre-LSP, and are now looking to 
maintain that through their switch to LSP, then both Eclipse CDT and (I assume) 
Qt Creator fall into that category.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143260/new/

https://reviews.llvm.org/D143260

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143260: [clangd] Add semantic token for labels

[Christian Kandeler via Phabricator via cfe-commits]

ckandeler added a comment.

In my opinion, it is not possible to have a competitive client if you limit 
yourself to the official LSP feature set; you just need language-specific 
extensions in practice.
And while of course not every silly idea should be blindly accepted, I think 
this "lowest common denominator" approach artificially limits clients' 
potential feature sets and inhibits innovation.
I am of course biased, but it seems to me that when in doubt, client 
requirements should take precedence over server-side purity concerns.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143260/new/

https://reviews.llvm.org/D143260

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143260: [clangd] Add semantic token for labels

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

sorry for long silence.

> But access specifiers are a completely different thing semantically, that's 
> the point: The user does not tell the client: "I want everything  that is 
> followed by a single colon in this color"; that would be silly. They say "I 
> want goto labels in this color", exactly because then they immediately stand 
> out compared to access specifiers.

I am not sure if access specifiers and label declarations occur in the same 
context often enough for this mixing to actually cause trouble TBH.

---

I was mostly being cautious for new semantic highlighting token. I believe 
today we've too low of a bar in clangd's semantic highlighting functionality 
for introducing "custom" token types, which are probably not used by any people 
apart from the ones involved in the introduction of the token (we don't have 
custom themes/scopes even for vscode, we don't even mention them in our 
user-facing documentation).
So I feel like these custom semantic token types are getting us into "death by 
thousand cuts" situation. Each of these changes are small enough on their own, 
but we'll slowly get into a state in which we're spending time both calculating 
and emitting all of those token types that are just dropped on the floor (and 
also sometimes the extra cost to maintain them as language semantics change).

Hence my stance here is still towards "we don't need it", unless we have some 
big editor(s) that can already recognize "label" as a semantic token type to 
provide the functionality for a set of users. that way we can justify of 
maintaining the code and the runtime costs. (or finding a way to make this more 
closely aligned with an existing token type/modifier)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143260/new/

https://reviews.llvm.org/D143260

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143260: [clangd] Add semantic token for labels

[Christian Kandeler via Phabricator via cfe-commits]

ckandeler added a comment.

Hello?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143260/new/

https://reviews.llvm.org/D143260

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143260: [clangd] Add semantic token for labels

[Christian Kandeler via Phabricator via cfe-commits]

ckandeler added a comment.

ping


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143260/new/

https://reviews.llvm.org/D143260

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143260: [clangd] Add semantic token for labels

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

Another potential consideration here is the GNU "labels as values 
" language extension, 
which clang seems to support, and which allows referencing a `LabelDecl` from a 
context other than a goto-statement (and thus less obvious from the lexical 
context only).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143260/new/

https://reviews.llvm.org/D143260

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143260: [clangd] Add semantic token for labels

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

FWIW, I agree that switch labels and goto labels are conceptually quite 
different: the thing before a switch label is an expression, and if it's an 
identifier it references an already-declared entity with its own kind (e.g. 
enumerator), whereas a goto label basically declares a new entity of a special 
kind (which can then be referenced from `goto` statements); having a distint 
color for that kind would make sense to me.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143260/new/

https://reviews.llvm.org/D143260

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143260: [clangd] Add semantic token for labels

[Christian Kandeler via Phabricator via cfe-commits]

ckandeler added a comment.

In D143260#4122523 , @kadircet wrote:

> at hindsight i can't see why `goto X;` and `X:` is not enough for clients to 
> implement this without any need for semantic analysis. are there contexts 
> where this kind of syntactical match is not enough?

I suppose the label *use* could be identified by looking at the previous token, 
but not the label *declaration* (see below).

> moreover there are other label-like constructs that we're not handling, e.g. 
> access specifiers and switch cases.

But access specifiers are a completely different thing semantically, that's the 
point: The user does not tell the client: "I want everything  that is followed 
by a single colon in this color"; that would be silly. They say "I want goto 
labels in this color", exactly because then they immediately stand out compared 
to access specifiers.
switch cases are indeed similar semantically, but the difference is that they 
already have a category assigned: They are either enum values (a semantic token 
type in clangd), macros (ditto) or number literals (likely to be its own 
category in the client's syntax highlighter).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143260/new/

https://reviews.llvm.org/D143260

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143260: [clangd] Add semantic token for labels

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

thanks for the patch, but could you elaborate a little bit on "why this is 
useful for clients".
in theory semantic highlighting tries to provide annotations for tokens that 
are hard to disambiguate by a syntax highlighter due to need for context.
at hindsight i can't see why `goto X;` and `X:` is not enough for clients to 
implement this without any need for semantic analysis. are there contexts where 
this kind of syntactical match is not enough?
moreover there are other label-like constructs that we're not handling, e.g. 
access specifiers and switch cases. any particular reason for not handling them 
as part of "label" highlights if we were to handle label-decls (the argument 
above applies to this case too though, I think these can be inferred without 
any semantic analysis)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143260/new/

https://reviews.llvm.org/D143260

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143260: [clangd] Add semantic token for labels

[Christian Kandeler via Phabricator via cfe-commits]

ckandeler created this revision.
ckandeler added a reviewer: sammccall.
Herald added subscribers: kadircet, arphaman.
Herald added a project: All.
ckandeler requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143260

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -1025,6 +1025,16 @@
 template $Bracket[[<]]C2$Bracket[[<]]int$Bracket[[>]] 
$TemplateParameter_def[[A]]$Bracket[[>]]
 class $Class_def[[B]] {};
   )cpp",
+  // Labels
+  R"cpp(
+bool $Function_def[[funcWithGoto]](bool $Parameter_def[[b]]) {
+  if ($Parameter[[b]])
+goto $Label[[return_true]];
+  return false;
+  $Label_decl[[return_true]]:
+return true;
+}
+  )cpp",
   // no crash
   R"cpp(
 struct $Class_def[[Foo]] {
Index: clang-tools-extra/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/clangd/SemanticHighlighting.h
+++ clang-tools-extra/clangd/SemanticHighlighting.h
@@ -52,6 +52,7 @@
   Modifier,
   Operator,
   Bracket,
+  Label,
 
   // This one is different from the other kinds as it's a line style
   // rather than a token style.
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -154,6 +154,8 @@
 return HighlightingKind::TemplateParameter;
   if (isa(D))
 return HighlightingKind::Concept;
+  if (isa(D))
+return HighlightingKind::Label;
   if (const auto *UUVD = dyn_cast(D)) {
 auto Targets = Resolver->resolveUsingValueDecl(UUVD);
 if (!Targets.empty()) {
@@ -1212,6 +1214,8 @@
 return OS << "Operator";
   case HighlightingKind::Bracket:
 return OS << "Bracket";
+  case HighlightingKind::Label:
+return OS << "Label";
   case HighlightingKind::InactiveCode:
 return OS << "InactiveCode";
   }
@@ -1352,6 +1356,8 @@
 return "operator";
   case HighlightingKind::Bracket:
 return "bracket";
+  case HighlightingKind::Label:
+return "label";
   case HighlightingKind::InactiveCode:
 return "comment";
   }


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -1025,6 +1025,16 @@
 template $Bracket[[<]]C2$Bracket[[<]]int$Bracket[[>]] $TemplateParameter_def[[A]]$Bracket[[>]]
 class $Class_def[[B]] {};
   )cpp",
+  // Labels
+  R"cpp(
+bool $Function_def[[funcWithGoto]](bool $Parameter_def[[b]]) {
+  if ($Parameter[[b]])
+goto $Label[[return_true]];
+  return false;
+  $Label_decl[[return_true]]:
+return true;
+}
+  )cpp",
   // no crash
   R"cpp(
 struct $Class_def[[Foo]] {
Index: clang-tools-extra/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/clangd/SemanticHighlighting.h
+++ clang-tools-extra/clangd/SemanticHighlighting.h
@@ -52,6 +52,7 @@
   Modifier,
   Operator,
   Bracket,
+  Label,
 
   // This one is different from the other kinds as it's a line style
   // rather than a token style.
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -154,6 +154,8 @@
 return HighlightingKind::TemplateParameter;
   if (isa(D))
 return HighlightingKind::Concept;
+  if (isa(D))
+return HighlightingKind::Label;
   if (const auto *UUVD = dyn_cast(D)) {
 auto Targets = Resolver->resolveUsingValueDecl(UUVD);
 if (!Targets.empty()) {
@@ -1212,6 +1214,8 @@
 return OS << "Operator";
   case HighlightingKind::Bracket:
 return OS << "Bracket";
+  case HighlightingKind::Label:
+return OS << "Label";
   case HighlightingKind::InactiveCode:
 return OS << "InactiveCode";
   }
@@ -1352,6 +1356,8 @@
 return "operator";
   case HighlightingKind::Bracket:
 return "bracket";
+  case HighlightingKind::Label:
+return "label";
   case HighlightingKind::InactiveCode:
 return "c