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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
