nridge added a comment. I'm happy to review the implementation, but I would first appreciate some guidance from @sammccall or @kadircet about whether we should add these semantic token kinds in the first place.
They would be a non-standard extension to the LSP token kinds, so I think the use case for them should be fairly compelling. It's true that there is an ambiguity between `<` and `>` as operators, vs. template arg/param list delimiters, but, at least in terms of user understanding of code, my sense is that the highlighting of the **preceding** token should be sufficient to disambiguate -- i.e. it would be some sort of type name in the template case, vs. a variable / literal / punctuation ending an expression in the operator case. > This is needed for clients that would like to visualize matching opening and > closing angle brackets, which can be valuable in non-trivial template > declarations or instantiations. For this use case, could an editor make use of the recently added operator tokens (https://reviews.llvm.org/D136594) instead, inferring that a `<` token which does not have an `operator` semantic token is a template delimiter? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D139926/new/ https://reviews.llvm.org/D139926 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
