nridge added a comment. In D136594#3973908 <https://reviews.llvm.org/D136594#3973908>, @ckandeler wrote:
> In D136594#3973812 <https://reviews.llvm.org/D136594#3973812>, @sammccall > wrote: > >> For my part, I still need to understand why we want the >> `builtin`/`UserModified` modifier. (The `operator` highlight kind seems >> obvious to me). > > We make this distinction in our client. The reasoning is explained here: > https://codereview.qt-project.org/c/qt-creator/qt-creator/+/220587 > I think Nathan made the same point earlier, i.e. it's helpful to see that an > operator is (potentially) overloaded and you could follow the symbol. Yeah, basically, if I'm looking at `a + b`, and the `+` is actually a syntactically disguised function call, I'd like to know about it, i.e. I'd like to be able to make my editor color //that// `+` differently than the case where `a` and `b` are e.g. `int`s. I do think that there are two potential routes to get there: 1. Only produce a semantic token in the `UserProvided` case. The `Builtin` case doesn't get an `operator` semantic token at all, hence there's no need for a modifier. As a user, I configure my editor to color all `operator` tokens prominently. 2. Produce a semantic token in both the `Builtin` and `UserProvided` cases, but with the modifier to distinguish between them (i.e. the current patch). As a user, I configure my editor to color `operator` tokens with the `UserProvided` modifier prominently. The advantage of (2) over (1) is that built-in operators get a semantic token to distinguish them from declarators (i.e. what Sam brought up in this comment <https://reviews.llvm.org/D136594#3940482> starting at "An (IMO) useful distinction that can't be found by the lexer ..."). The advantage of (1) over (2) is that the primary intended effect (overloaded operators are highlighted prominently) can be achieved with less configuration (no custom modifier). If we care more about how things look out of the box (i.e. with a theme that provides colors only for the operators/modifiers in the LSP spec), perhaps we should prefer (1) over (2), in spite of the declarator/operator issue? I don't have a strong preference between these options. (But I do have a strong preference for being able to make overloaded operators look different from built-in operators, whether that difference is modifier vs. no modifier, or semantic token vs. no semantic token at all.) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D136594/new/ https://reviews.llvm.org/D136594 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
