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