[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#1655175 <https://reviews.llvm.org/D66990#1655175>, @ilya-biryukov wrote:

> In D66990#1655030 <https://reviews.llvm.org/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 <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)`.
> 
> 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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66990