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

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

In D66990#1654312 <https://reviews.llvm.org/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 <https://github.com/cquery-project/vscode-cquery/blob/4aac325dcf0735aa5d5f98960f28d6af6ca83d50/src/extension.ts#L84> 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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66990