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)?
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).
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 distinct color for that kind would make sense to me.
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).