[clangd] Add support for semantic token type "operator"

[ckandeler]

Summary

Also add new modifier for differentiating between built-in and user-
provided operators.

[nridge]

For reference, earlier work along these lines which never landed: https://reviews.llvm.org/D119077

[nridge]

A couple of high-level thoughts on this:

1. Based on the discussion in https://github.com/clangd/clangd/issues/1115, I believe highlighting of built-in operators should be out of scope for semantic highlighting, at least in the default mode; client-side highlighting should be sufficient for these, similar to strings and literals.
2. An alternative to assigning (user-provided) operators a new token kind would be to assign them the same token kind as the entity they invoke (i.e. function or method). Both approaches have their advantages:
   • If we use the function/method kinds, then uses of user-provided operators will be highlighted differently from built-in operators even when using a default / standard theme that doesn't know about clangd-specific token types.
   • If we use a dedicated operator kind, users can configure different styles for operators vs. function/methods (and they may want different styles given that syntactically the two look quite different).
     
     One way to get the best of both worlds could be to use the function/method kinds in combination with an operator modifier. That would color overloaded operators out of the box while also allowing users to customize the style based on the presence of the modifier. What do you think about this approach?

[ckandeler]

In D136594#3940143, @nridge wrote:

A couple of high-level thoughts on this:

1. Based on the discussion in https://github.com/clangd/clangd/issues/1115, I believe highlighting of built-in operators should be out of scope for semantic highlighting, at least in the default mode; client-side highlighting should be sufficient for these, similar to strings and literals.
2. An alternative to assigning (user-provided) operators a new token kind would be to assign them the same token kind as the entity they invoke (i.e. function or method). Both approaches have their advantages:
   • If we use the function/method kinds, then uses of user-provided operators will be highlighted differently from built-in operators even when using a default / standard theme that doesn't know about clangd-specific token types.
   • If we use a dedicated operator kind, users can configure different styles for operators vs. function/methods (and they may want different styles given that syntactically the two look quite different).
     
     One way to get the best of both worlds could be to use the function/method kinds in combination with an operator modifier. That would color overloaded operators out of the box while also allowing users to customize the style based on the presence of the modifier. What do you think about this approach?

The problem with "operator" as a modifier is that if and when the augmentsSyntaxTokens feature is implemented, we'll need an operator token kind anyway (and having both seems weird).
The modifier semantics could also be switched around, btw, so that instead of "userProvided" we could have "builtIn" (which might also apply to other token kinds). I don't have a strong opinion on this.
Should I perhaps add the augmentsSyntaxTokens option and rebase this patch to make it its first user?

[sammccall]

In D136594#3940143, @nridge wrote:

I believe highlighting of built-in operators should be out of scope for semantic highlighting, at least in the default mode; client-side highlighting should be sufficient for these, similar to strings and literals.

I'm not sure if "built-in" (as opposed to overloaded) is the right distinction here: whether a == b can be highlighted client-side seems unrelated to whether the type is int or string.
But I agree we only need to provide this (by default) if it's something that can't be determined by lexing.

An (IMO) useful distinction that can't be found by the lexer is the use of * as a declarator (int *x) vs an operator (return *x). These are both potentially "built-in". https://github.com/helix-editor/helix/pull/4278 has a fuller example. (In practice, clients are going to highlight declarator-stars as operators on the client-side, so to make this work we have to highlight them as something else rather than just mark operators. But this patch looks like the right direction).

2. An alternative to assigning (user-provided) operators a new token kind would be to assign them the same token kind as the entity they invoke (i.e. function or method). Both approaches have their advantages:
   • If we use the function/method kinds, then uses of user-provided operators will be highlighted differently from built-in operators even when using a default / standard theme that doesn't know about clangd-specific token types.
   • If we use a dedicated operator kind, users can configure different styles for operators vs. function/methods (and they may want different styles given that syntactically the two look quite different).
     
     One way to get the best of both worlds could be to use the function/method kinds in combination with an operator modifier. That would color overloaded operators out of the box while also allowing users to customize the style based on the presence of the modifier. What do you think about this approach?

I think since LSP specifies an operator SemanticTokenType, we should use it unless there's a *really* strong reason not to.
A well-behaved editor will provide a themeable color for (client-side) highlighting of operators, and also map LSP's operator SemanticTokenType onto that color by default. If we decide to do our own different thing, we'll break that happy path.

clang-tools-extra/clangd/SemanticHighlighting.h

78

Can you give some background here or on the bug tracker about what kind of distinction you're trying to draw here and why it's important?
(Most clients are never going to benefit from nonstandard modifiers so they should be pretty compelling)

78

as well as being jargony, "user-provided" has a specific technical meaning that I don't think you intend here. For example, auto operator<=>(const S&) const = default is not user-provided (defaulted on first declaration). https://eel.is/c++draft/dcl.fct.def.default#5

If we need this and can't get away with reusing defaultLibrary (which would include std::) then maybe we should add something like builtin which seems quite reusable.

78

Since we often can't say whether an operator is user-provided or not (in templates), we should consider what we want the highlighting to be in these cases.
(If templates should be highlighted as built-in, we should prefer a modifier like UserProvided, if they should be highlighted as user-provided, we should prefer a modifier like Builtin)

[ckandeler]

clang-tools-extra/clangd/SemanticHighlighting.h

78

as well as being jargony, "user-provided" has a specific technical meaning that I don't think you intend here. For example, auto operator<=>(const S&) const = default is not user-provided (defaulted on first declaration). https://eel.is/c++draft/dcl.fct.def.default#5

If we need this and can't get away with reusing defaultLibrary (which would include std::) then maybe we should add something like builtin which seems quite reusable.

I use "userProvided" here in the sense of "not built-in" or "overloaded". I do not cling to the term, and have also suggested the opposite default of using "builtin" in another comment.

78

Since we often can't say whether an operator is user-provided or not (in templates), we should consider what we want the highlighting to be in these cases.

True, I have not considered this.

(If templates should be highlighted as built-in, we should prefer a modifier like UserProvided, if they should be highlighted as user-provided, we should prefer a modifier like Builtin)

Intuitively, it seems we should be conservative and not claim the operator is overloaded unless we know it is. So "built-in" might then mean "we can't prove it's not a built-in". It's probably not worth to introduce a modifier CouldBeEitherWay just to explicitly express ambiguity ;)

[nridge]

In D136594#3940482, @sammccall wrote:

I think since LSP specifies an operator SemanticTokenType, we should use it unless there's a *really* strong reason not to.

My bad, I completely overlooked that LSP has a standard token type for this! (I think maybe because I assumed D119077 would have used it had it existed.) In light of that, please disregard my comment about making operator a modifier.

[nridge]

clang-tools-extra/clangd/SemanticHighlighting.h

78

Since we often can't say whether an operator is user-provided or not (in templates), we should consider what we want the highlighting to be in these cases.
(If templates should be highlighted as built-in, we should prefer a modifier like UserProvided, if they should be highlighted as user-provided, we should prefer a modifier like Builtin)

In my mind, "go-to-definition on this operator symbol will take me to a function declaration/definition" is a good match for "I want this colored differently". (Which would imply treating dependent operator calls where we can't figure out an overloaded operator target even heuristically, as "built-in".)

[ckandeler]

Make highlighting of built-in operators conditional

[ckandeler]

Should I perhaps add the augmentsSyntaxTokens option and rebase this patch to make it its first user?

So I went ahead and did this. Opinions?

[nridge]

In D136594#3940482, @sammccall wrote:

An (IMO) useful distinction that can't be found by the lexer is the use of * as a declarator (int *x) vs an operator (return *x).

I failed to appreciate the implication of this the first time I read it: this is in fact a semantic distinction. Given A * B;, the * could be a declarator or an operator depending on whether A resolves to a type name or a variable name; at the lexer level, it's just tok::star in both cases.

The current patch will produce an operator token in the operator case but not the declarator case, thereby achieving an effect that client-side highlighting couldn't. As such, I guess it does make sense for this to be a semantic token (i.e. produced even with with augmentsSyntaxTokens=true) even in the built-in case?

[nridge]

(I envisioned the implementation of augmentsSyntaxTokens=false to be "loop over the lexer tokens and turn a subset of them into additional tokens to return over LSP". The fact that that would have meant producing an "operator" token even for tok::star which is actually a declarator, is what clued me in to the fact that "operators" are a semantic category.)

[ckandeler]

In D136594#3950334, @nridge wrote:

The current patch will produce an operator token in the operator case but not the declarator case, thereby achieving an effect that client-side highlighting couldn't. As such, I guess it does make sense for this to be a semantic token (i.e. produced even with with augmentsSyntaxTokens=true) even in the built-in case?

You mean just for that one case or in general?

[sammccall]

Regarding AugmentsSyntaxTokens:

• in general this seems like a nice thing to support, though I'm not aware of "big" !AugmentsSyntaxTokens clients so it's not urgent
• I think the right design for that is to (conditionally) run the lexer and mark only tokens that haven't been marked yet. If the lexer doesn't provide enough info, then it's maybe not "syntactic".
• I think it's OK to "accidentally" produce some "syntactic" tokens in semantic-only mode - we shouldn't go out of our way to avoid doing so.

Since &, &&, * aren't always operators, and this is not syntactically distinguishable, I think we should just always emit all operator tokens, even in the standard AugmentsSyntaxTokens mode, and even for tokens that can only be operators. (In practice many other "obvious" operators aren't always either: ~ (destructor), ^ (objc blocks), = (lambda capture), # (directive vs pasting), +- (objc method specifiers)...)

This means AugmentSyntaxTokens doesn't belong in this patch, I think - as Nathan said we want to emit these tokens regardless. (Really sorry for the churn...)

clang-tools-extra/clangd/SemanticHighlighting.h

78

Can you give some background here or on the bug tracker about what kind of distinction you're trying to draw here and why it's important?
(Most clients are never going to benefit from nonstandard modifiers so they should be pretty compelling)

This was one of the biggest questions I had about this patch - just hoping it doesn't get missed.

78

Intuitively, it seems we should be conservative and not claim the operator is overloaded unless we know it is.

This feels a bit circular, if we agree we're not going to introduce a CouldBeEitherWay then why is "built-in" a more conservative claim than "overloaded"?

I'm inclined towards builtin as a modifier because I think for language entities as a whole (types, functions etc, not just operators) it's the exception. It also seems easier to name and define.

In my mind, "go-to-definition on this operator symbol will take me to a function declaration/definition" is a good match for "I want this colored differently".

This mostly makes sense to me, but:

• I don't think we should actually run all the heuristics logic
• if there's probably a definition available but we can't resolve it due to templates, I'd still like to know something's up

I think my internal question is more like "is this a trivial arithmetic shift, or something potentially complicated"? And I think depending on template resolution is "potentially complicated". (Maybe trivial in the end, but so might be an overloaded operator)

[ckandeler]

Added template example.

[ckandeler]

clang-tools-extra/clangd/SemanticHighlighting.h

78

Intuitively, it seems we should be conservative and not claim the operator is overloaded unless we know it is.

This feels a bit circular, if we agree we're not going to introduce a CouldBeEitherWay then why is "built-in" a more conservative claim than "overloaded"?

I'm inclined towards builtin as a modifier because I think for language entities as a whole (types, functions etc, not just operators) it's the exception. It also seems easier to name and define.

In my mind, "go-to-definition on this operator symbol will take me to a function declaration/definition" is a good match for "I want this colored differently".

This mostly makes sense to me, but:

• I don't think we should actually run all the heuristics logic
• if there's probably a definition available but we can't resolve it due to templates, I'd still like to know something's up

I think my internal question is more like "is this a trivial arithmetic shift, or something potentially complicated"? And I think depending on template resolution is "potentially complicated". (Maybe trivial in the end, but so might be an overloaded operator)

The documentation for BinaryOperator says:
/ Within a C++ template, whether BinaryOperator or CXXOperatorCallExpr is
/ used to store an expression "x + y" depends on the subexpressions
/ for x and y. If neither x or y is type-dependent, and the "+"
/ operator resolves to a built-in operation, BinaryOperator will be
/ used to express the computation (x and y may still be
/ value-dependent). If either x or y is type-dependent, or if the
/ "+" resolves to an overloaded operator, CXXOperatorCallExpr will
/ be used to express the computation.
With the patch as-is (possibly with the UserProvided/BuiltIn switch) , this should result exactly in what you want (if I understand you correctly). However, it does not match my observation: I always see the normal operator types. Am I missing something or is the documentation wrong?

[sammccall]

clang-tools-extra/clangd/SemanticHighlighting.h

78

Can you reduce this to an example where clang -fsyntax-only -Xclang -ast-dump doesn't print what you expect?

(if this isn't possible, then it might be a bug in the patch)

[ckandeler]

clang-tools-extra/clangd/SemanticHighlighting.h

78

$ cat test.cpp
template<typename T> class MyTemplate {

void run(typename T::A t1, typename T::A t2) { return t1 == t2; }

}
$ clang -fsyntax-only -Xclang -ast-dump test.cpp

TranslationUnitDecl 0x55986dab0dd8 <<invalid sloc>> <invalid sloc>

-TypedefDecl 0x55986dab1640 <<invalid sloc>> <invalid sloc> implicit int128_t 'int128'

`-BuiltinType 0x55986dab13a0 '__int128'

-TypedefDecl 0x55986dab16b0 <<invalid sloc>> <invalid sloc> implicit uint128_t 'unsigned int128'

`-BuiltinType 0x55986dab13c0 'unsigned __int128'

-TypedefDecl 0x55986dab1a28 <<invalid sloc>> <invalid sloc> implicit NSConstantString 'NSConstantString_tag'

`-RecordType 0x55986dab17a0 '__NSConstantString_tag'

`-CXXRecord 0x55986dab1708 '__NSConstantString_tag'

-TypedefDecl 0x55986dab1ac0 <<invalid sloc>> <invalid sloc> implicit __builtin_ms_va_list 'char *'

`-PointerType 0x55986dab1a80 'char *'

`-BuiltinType 0x55986dab0e80 'char'

-TypedefDecl 0x55986daf65a8 <<invalid sloc>> <invalid sloc> implicit builtin_va_list 'va_list_tag[1]'

`-ConstantArrayType 0x55986daf6550 '__va_list_tag[1]' 1

`-RecordType 0x55986dab1bb0 '__va_list_tag'

`-CXXRecord 0x55986dab1b18 '__va_list_tag'

`-ClassTemplateDecl 0x55986daf6750 <test.cpp:1:1, line:3:1> line:1:28 MyTemplate

|-TemplateTypeParmDecl 0x55986daf6600 <col:10, col:19> col:19 typename depth 0 index 0 T
`-CXXRecordDecl 0x55986daf66c0 <col:22, line:3:1> line:1:28 class MyTemplate definition
  |-DefinitionData empty aggregate standard_layout trivially_copyable pod trivial literal has_constexpr_non_copy_move_ctor can_const_default_init
  | |-DefaultConstructor exists trivial constexpr needs_implicit defaulted_is_constexpr
  | |-CopyConstructor simple trivial has_const_param needs_implicit implicit_has_const_param
  | |-MoveConstructor exists simple trivial needs_implicit
  | |-CopyAssignment simple trivial has_const_param needs_implicit implicit_has_const_param
  | |-MoveAssignment exists simple trivial needs_implicit
  | `-Destructor simple irrelevant trivial needs_implicit
  |-CXXRecordDecl 0x55986daf6990 <col:22, col:28> col:28 implicit class MyTemplate
  `-CXXMethodDecl 0x55986daf6d18 <line:2:5, col:73> col:10 compare 'bool (typename T::A, typename T::A)'
    |-ParmVarDecl 0x55986daf6b10 <col:18, col:32> col:32 referenced t1 'typename T::A'
    |-ParmVarDecl 0x55986daf6bd0 <col:36, col:50> col:50 referenced t2 'typename T::A'
    `-CompoundStmt 0x55986daf6e50 <col:54, col:73>
      `-ReturnStmt 0x55986daf6e40 <col:56, col:69>
        `-BinaryOperator 0x55986daf6e20 <col:63, col:69> '<dependent type>' '=='
          |-DeclRefExpr 0x55986daf6de0 <col:63> 'typename T::A' lvalue ParmVar 0x55986daf6b10 't1' 'typename T::A'
          `-DeclRefExpr 0x55986daf6e00 <col:69> 'typename T::A' lvalue ParmVar 0x55986daf6bd0 't2' 'typename T::A'

[ckandeler]

Using operators on expressions with dependent types now considered "complex",

[ckandeler]

Now seems to do what we want. Should I switch the modifier around?

[ckandeler]

ping

[sammccall]

For my part, I still need to understand why we want the builtin/UserModified modifier. (The operator highlight kind seems obvious to me).

From earlier comments:

Can you give some background here or on the bug tracker about what kind of distinction you're trying to draw here and why it's important?
(Most clients are never going to benefit from nonstandard modifiers so they should be pretty compelling)

This was one of the biggest questions I had about this patch - just hoping it doesn't get missed.

clang-tools-extra/clangd/SemanticHighlighting.h

78

The documentation for BinaryOperator says:

It indeed looks like the documentation is wrong :-( Based on that, your implementation looks right to me.

[ckandeler]

In 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.

[nridge]

In D136594#3973908, @ckandeler wrote:

In 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. ints.

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 semantic 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 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 tokens/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.)

[nridge]

While we're waiting for Sam to weigh in on the modifier question, a couple of comments about the details of the patch:

• Does the implementation handle explicit operator calls, e.g. a.operator+(b)? If so, it would be nice to add some test coverage.
• I see the patch handles new and delete expression but I couldn't spot any test cases for them, could you add some? (Apologies if I've overlooked it.)

[ckandeler]

Added more test cases.

[ckandeler]

In D136594#3987852, @nridge wrote:

• Does the implementation handle explicit operator calls, e.g. a.operator+(b)? If so, it would be nice to add some test coverage.

It does now.

[sammccall]

Thanks for the explanation! It makes sense. And given this motivation I don't think inverting to "builtin" is a good idea.
The impact is a bit limited because it's not a standard modifier, but it doesn't add much complexity, so LGTM.

I think the naming is an issue: "user-provided" is an unusual term with a very specific and unusual meaning for functions. I'd prefer the more generic "user-defined", if you don't mind changing it. (Also not perfect, but I can't think of a really good name).

Something related that might be interesting (and visible in more editors): highlighting the non-operator uses of * or other tokens. (This patch largely won't affect them, as they'll probably be client-side highlighted as operators if we don't say anything). Filed https://github.com/clangd/clangd/issues/1421. (Unfortunately I'm not really able to do clangd feature work these days)

[ckandeler]

Renamed modifier.

[nridge]

Thanks, Christian, for your work on this!

[hokein]

This patch causes a clangd crash on dependent code (e.g. running on ASTMatchers.h), fixed in https://github.com/llvm/llvm-project/commit/bcb457c68e20120f0bdd0a59e4b4ce90b8121310.

[ckandeler]

In D136594#3991530, @hokein wrote:

This patch causes a clangd crash on dependent code (e.g. running on ASTMatchers.h), fixed in https://github.com/llvm/llvm-project/commit/bcb457c68e20120f0bdd0a59e4b4ce90b8121310.

Thanks.

clang-tools-extra/clangd/SemanticHighlighting.h

enum class HighlightingKind {
   Type,
   Unknown,
   Namespace,
   TemplateParameter,
   Concept,
   Primitive,
   Macro,
   Modifier,
+  Operator,
 
   // This one is different from the other kinds as it's a line style
   // rather than a token style.
   InactiveCode,
 
   LastKind = InactiveCode
 };
 
 llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, HighlightingKind K);
 
 enum class HighlightingModifier {
   Declaration,
   Definition,
   Deprecated,
   Deduced,
   Readonly,
   Static,
   Abstract,
   Virtual,
   DependentName,
   DefaultLibrary,
   UsedAsMutableReference,
   UsedAsMutablePointer,
   ConstructorOrDestructor,
+  UserDefined,
 
   FunctionScope,
   ClassScope,
   FileScope,
   GlobalScope,
 
   LastModifier = GlobalScope
 };

clang-tools-extra/clangd/SemanticHighlighting.cpp

public:
   bool VisitPredefinedExpr(PredefinedExpr *E) {
     H.addToken(E->getLocation(), HighlightingKind::LocalVariable)
         .addModifier(HighlightingModifier::Static)
         .addModifier(HighlightingModifier::Readonly)
         .addModifier(HighlightingModifier::FunctionScope);
     return true;
   }
 
+  bool VisitFunctionDecl(FunctionDecl *D) {
+    if (D->isOverloadedOperator()) {
+      const auto addOpDeclToken = [&](SourceLocation Loc) {
+        auto &Token = H.addToken(Loc, HighlightingKind::Operator)
+                          .addModifier(HighlightingModifier::Declaration);
+        if (D->isThisDeclarationADefinition())
+          Token.addModifier(HighlightingModifier::Definition);
+      };
+      const auto Range = D->getNameInfo().getCXXOperatorNameRange();
+      addOpDeclToken(Range.getBegin());
+      const auto Kind = D->getOverloadedOperator();
+      if (Kind == OO_Call || Kind == OO_Subscript)
+        addOpDeclToken(Range.getEnd());
+    }
+    return true;
+  }
+
+  bool VisitCXXOperatorCallExpr(CXXOperatorCallExpr *E) {
+    const auto addOpToken = [&](SourceLocation Loc) {
+      H.addToken(Loc, HighlightingKind::Operator)
+          .addModifier(HighlightingModifier::UserDefined);
+    };
+    addOpToken(E->getOperatorLoc());
+    const auto Kind = E->getOperator();
+    if (Kind == OO_Call || Kind == OO_Subscript) {
+      if (auto *Callee = E->getCallee())
+        addOpToken(Callee->getBeginLoc());
+    }
+    return true;
+  }
+
+  bool VisitUnaryOperator(UnaryOperator *Op) {
+    auto &Token = H.addToken(Op->getOperatorLoc(), HighlightingKind::Operator);
+    if (Op->getSubExpr()->isTypeDependent())
+      Token.addModifier(HighlightingModifier::UserDefined);
+    return true;
+  }
+
+  bool VisitBinaryOperator(BinaryOperator *Op) {
+    auto &Token = H.addToken(Op->getOperatorLoc(), HighlightingKind::Operator);
+    if (Op->getLHS()->isTypeDependent() || Op->getRHS()->isTypeDependent())
+      Token.addModifier(HighlightingModifier::UserDefined);
+    return true;
+  }
+
+  bool VisitConditionalOperator(ConditionalOperator *Op) {
+    H.addToken(Op->getQuestionLoc(), HighlightingKind::Operator);
+    H.addToken(Op->getColonLoc(), HighlightingKind::Operator);
+    return true;
+  }
+
+  bool VisitCXXNewExpr(CXXNewExpr *E) {
+    auto &Token = H.addToken(E->getBeginLoc(), HighlightingKind::Operator);
+    if (isa<CXXMethodDecl>(E->getOperatorNew()))
+      Token.addModifier(HighlightingModifier::UserDefined);
+    return true;
+  }
+
+  bool VisitCXXDeleteExpr(CXXDeleteExpr *E) {
+    auto &Token = H.addToken(E->getBeginLoc(), HighlightingKind::Operator);
+    if (isa<CXXMethodDecl>(E->getOperatorDelete()))
+      Token.addModifier(HighlightingModifier::UserDefined);
+    return true;
+  }
+
   bool VisitCallExpr(CallExpr *E) {
     // Highlighting parameters passed by non-const reference does not really
     // make sense for literals...
     if (isa<UserDefinedLiteral>(E))
       return true;
 
     // FIXME: consider highlighting parameters of some other overloaded
     // operators as well
if (auto *TI = D->getNameInfo().getNamedTypeInfo()) {
         H.addExtraModifier(Loc, HighlightingModifier::Definition);
     }
     return true;
   }
 
   bool VisitCXXMemberCallExpr(CXXMemberCallExpr *CE) {
     // getMethodDecl can return nullptr with member pointers, e.g.
     // `(foo.*pointer_to_member_fun)(arg);`
-    if (isa_and_present<CXXDestructorDecl>(CE->getMethodDecl())) {
+    if (auto *D = CE->getMethodDecl()) {
+      if (isa<CXXDestructorDecl>(D)) {
         if (auto *ME = dyn_cast<MemberExpr>(CE->getCallee())) {
           if (auto *TI = ME->getMemberNameInfo().getNamedTypeInfo()) {
             H.addExtraModifier(TI->getTypeLoc().getBeginLoc(),
                                HighlightingModifier::ConstructorOrDestructor);
           }
         }
+      } else if (D->isOverloadedOperator()) {
+        if (auto *ME = dyn_cast<MemberExpr>(CE->getCallee()))
+          H.addToken(
+               ME->getMemberNameInfo().getCXXOperatorNameRange().getBegin(),
+               HighlightingKind::Operator)
+              .addModifier(HighlightingModifier::UserDefined);
+      }
     }
     return true;
   }
 
   bool VisitDeclaratorDecl(DeclaratorDecl *D) {
     auto *AT = D->getType()->getContainedAutoType();
     if (!AT)
       return true;
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, HighlightingKind K) {
   case HighlightingKind::Concept:
     return OS << "Concept";
   case HighlightingKind::Primitive:
     return OS << "Primitive";
   case HighlightingKind::Macro:
     return OS << "Macro";
   case HighlightingKind::Modifier:
     return OS << "Modifier";
+  case HighlightingKind::Operator:
+    return OS << "Operator";
   case HighlightingKind::InactiveCode:
     return OS << "InactiveCode";
   }
   llvm_unreachable("invalid HighlightingKind");
 }
 llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, HighlightingModifier K) {
   switch (K) {
   case HighlightingModifier::Declaration:
llvm::StringRef toSemanticTokenType(HighlightingKind Kind) {
   case HighlightingKind::Concept:
     return "concept"; // nonstandard
   case HighlightingKind::Primitive:
     return "type";
   case HighlightingKind::Macro:
     return "macro";
   case HighlightingKind::Modifier:
     return "modifier";
+  case HighlightingKind::Operator:
+    return "operator";
   case HighlightingKind::InactiveCode:
     return "comment";
   }
   llvm_unreachable("unhandled HighlightingKind");
 }
 
 llvm::StringRef toSemanticTokenModifier(HighlightingModifier Modifier) {
   switch (Modifier) {
llvm::StringRef toSemanticTokenModifier(HighlightingModifier Modifier) {
   case HighlightingModifier::DefaultLibrary:
     return "defaultLibrary";
   case HighlightingModifier::UsedAsMutableReference:
     return "usedAsMutableReference"; // nonstandard
   case HighlightingModifier::UsedAsMutablePointer:
     return "usedAsMutablePointer"; // nonstandard
   case HighlightingModifier::ConstructorOrDestructor:
     return "constructorOrDestructor"; // nonstandard
+  case HighlightingModifier::UserDefined:
+    return "userDefined"; // nonstandard
   case HighlightingModifier::FunctionScope:
     return "functionScope"; // nonstandard
   case HighlightingModifier::ClassScope:
     return "classScope"; // nonstandard
   case HighlightingModifier::FileScope:
     return "fileScope"; // nonstandard
   case HighlightingModifier::GlobalScope:
     return "globalScope"; // nonstandard

clang-tools-extra/clangd/test/initialize-params.test

 # CHECK-NEXT:            "static",
 # CHECK-NEXT:            "abstract",
 # CHECK-NEXT:            "virtual",
 # CHECK-NEXT:            "dependentName",
 # CHECK-NEXT:            "defaultLibrary",
 # CHECK-NEXT:            "usedAsMutableReference",
 # CHECK-NEXT:            "usedAsMutablePointer",
 # CHECK-NEXT:            "constructorOrDestructor",
+# CHECK-NEXT:            "userDefined",
 # CHECK-NEXT:            "functionScope",
 # CHECK-NEXT:            "classScope",
 # CHECK-NEXT:            "fileScope",
 # CHECK-NEXT:            "globalScope"
 # CHECK-NEXT:          ],
 # CHECK-NEXT:          "tokenTypes": [
 # CHECK-NEXT:            "variable",
 # CHECK:               ]

clang-tools-extra/clangd/test/semantic-tokens.test

 # CHECK-NEXT:  "jsonrpc": "2.0",
 # CHECK-NEXT:  "result": {
 # CHECK-NEXT:    "data": [
 #                  First line, char 5, variable, declaration+globalScope
 # CHECK-NEXT:      0,
 # CHECK-NEXT:      4,
 # CHECK-NEXT:      1,
 # CHECK-NEXT:      0,
-# CHECK-NEXT:      65539
+# CHECK-NEXT:      131075
 # CHECK-NEXT:    ],
 # CHECK-NEXT:    "resultId": "1"
 # CHECK-NEXT:  }
 ---
 {"jsonrpc":"2.0","method":"textDocument/didChange","params":{
   "textDocument": {"uri":"test:///foo.cpp","version":2},
   "contentChanges":[{"text":"int x = 2;\nint y = 3;"}]
 }}

 # CHECK-NEXT:    "edits": [
 # CHECK-NEXT:      {
 # CHECK-NEXT:        "data": [
 #                      Next line, char 5, variable, declaration+globalScope
 # CHECK-NEXT:          1,
 # CHECK-NEXT:          4,
 # CHECK-NEXT:          1,
 # CHECK-NEXT:          0,
-# CHECK-NEXT:          65539
+# CHECK-NEXT:          131075
 # CHECK-NEXT:        ],
 #                    Inserted at position 1
 # CHECK-NEXT:        "deleteCount": 0,
 # CHECK-NEXT:        "start": 5
 # CHECK-NEXT:      }
 # CHECK-NEXT:    ],
 # CHECK-NEXT:    "resultId": "2"
 # CHECK-NEXT:  }
 ---
 # Incremental token request with incorrect baseline => full tokens list.
 {"jsonrpc":"2.0","id":2,"method":"textDocument/semanticTokens/full/delta","params":{
   "textDocument": {"uri":"test:///foo.cpp"},
   "previousResultId": "bogus"
 }}
 # CHECK:       "id": 2,
 # CHECK-NEXT:  "jsonrpc": "2.0",
 # CHECK-NEXT:  "result": {
 # CHECK-NEXT:    "data": [
 # CHECK-NEXT:      0,
 # CHECK-NEXT:      4,
 # CHECK-NEXT:      1,
 # CHECK-NEXT:      0,
-# CHECK-NEXT:      65539,
+# CHECK-NEXT:      131075,
 # CHECK-NEXT:      1,
 # CHECK-NEXT:      4,
 # CHECK-NEXT:      1,
 # CHECK-NEXT:      0,
-# CHECK-NEXT:      65539
+# CHECK-NEXT:      131075
 # CHECK-NEXT:    ],
 # CHECK-NEXT:    "resultId": "3"
 # CHECK-NEXT:  }
 ---
 {"jsonrpc":"2.0","id":3,"method":"shutdown"}
 ---
 {"jsonrpc":"2.0","method":"exit"}

clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

const char *TestCases[] = {
       struct $Class_def[[AS]] {
         double $Field_decl[[SomeMember]];
       };
       struct {
       } $Variable_def[[S]];
       void $Function_def[[foo]](int $Parameter_def[[A]], $Class[[AS]] $Parameter_def[[As]]) {
         $Primitive_deduced_defaultLibrary[[auto]] $LocalVariable_def[[VeryLongVariableName]] = 12312;
         $Class[[AS]]     $LocalVariable_def[[AA]];
-        $Primitive_deduced_defaultLibrary[[auto]] $LocalVariable_def[[L]] = $LocalVariable[[AA]].$Field[[SomeMember]] + $Parameter[[A]];
+        $Primitive_deduced_defaultLibrary[[auto]] $LocalVariable_def[[L]] = $LocalVariable[[AA]].$Field[[SomeMember]] $Operator[[+]] $Parameter[[A]];
         auto $LocalVariable_def[[FN]] = [ $LocalVariable[[AA]]](int $Parameter_def[[A]]) -> void {};
-        $LocalVariable[[FN]](12312);
+        $LocalVariable[[FN]]$Operator_userDefined[[(]]12312$Operator_userDefined[[)]];
       }
     )cpp",
       R"cpp(
       void $Function_decl[[foo]](int);
       void $Function_decl[[Gah]]();
       void $Function_def[[foo]]() {
         auto $LocalVariable_def[[Bou]] = $Function[[Gah]];
       }
)cpp",
       struct $Class_def[[C]] : $Namespace[[abc]]::$Class[[A]]<$TemplateParameter[[T]]> {
         typename $TemplateParameter[[T]]::$Type_dependentName[[A]]* $Field_decl[[D]];
       };
       $Namespace[[abc]]::$Class[[A]]<int> $Variable_def[[AA]];
       typedef $Namespace[[abc]]::$Class[[A]]<int> $Class_decl[[AAA]];
       struct $Class_def[[B]] {
         $Class_decl_constrDestr[[B]]();
         ~$Class_decl_constrDestr[[B]]();
-        void operator<<($Class[[B]]);
+        void operator$Operator_decl[[<<]]($Class[[B]]);
         $Class[[AAA]] $Field_decl[[AA]];
       };
       $Class[[B]]::$Class_def_constrDestr[[B]]() {}
       $Class[[B]]::~$Class_def_constrDestr[[B]]() {}
       void $Function_def[[f]] () {
         $Class[[B]] $LocalVariable_def[[BB]] = $Class[[B]]();
         $LocalVariable[[BB]].~$Class_constrDestr[[B]]();
         $Class[[B]]();
)cpp",
         double $Field_decl[[C]];
       };
       struct $Class_def[[A]] {
         double $Field_decl[[B]];
         $Class[[D]] $Field_decl[[E]];
         static double $StaticField_decl_static[[S]];
         static void $StaticMethod_def_static[[bar]]() {}
         void $Method_def[[foo]]() {
-          $Field[[B]] = 123;
-          this->$Field[[B]] = 156;
+          $Field[[B]] $Operator[[=]] 123;
+          this->$Field[[B]] $Operator[[=]] 156;
           this->$Method[[foo]]();
           $Method[[foo]]();
           $StaticMethod_static[[bar]]();
-          $StaticField_static[[S]] = 90.1;
+          $StaticField_static[[S]] $Operator[[=]] 90.1;
         }
       };
       void $Function_def[[foo]]() {
         $Class[[A]] $LocalVariable_def[[AA]];
-        $LocalVariable[[AA]].$Field[[B]] += 2;
+        $LocalVariable[[AA]].$Field[[B]] $Operator[[+=]] 2;
         $LocalVariable[[AA]].$Method[[foo]]();
         $LocalVariable[[AA]].$Field[[E]].$Field[[C]];
-        $Class[[A]]::$StaticField_static[[S]] = 90;
+        $Class[[A]]::$StaticField_static[[S]] $Operator[[=]] 90;
       }
     )cpp",
       R"cpp(
       struct $Class_def[[AA]] {
         int $Field_decl[[A]];
       };
       int $Variable_def[[B]];
       $Class[[AA]] $Variable_def[[A]]{$Variable[[B]]};
)cpp",
         $Class[[Foo]] *$LocalVariable_def[[FP]] = ($Class[[Foo]]*)$LocalVariable[[B]];
         int $LocalVariable_def[[I]] = (int)$LocalVariable[[B]];
       }
     )cpp",
       R"cpp(
       struct $Class_def[[B]] {};
       struct $Class_def[[A]] {
         $Class[[B]] $Field_decl[[BB]];
-        $Class[[A]] &operator=($Class[[A]] &&$Parameter_def[[O]]);
+        $Class[[A]] &operator$Operator_decl[[=]]($Class[[A]] &&$Parameter_def[[O]]);
       };
 
-      $Class[[A]] &$Class[[A]]::operator=($Class[[A]] &&$Parameter_def[[O]]) = default;
+      $Class[[A]] &$Class[[A]]::operator$Operator_def[[=]]($Class[[A]] &&$Parameter_def[[O]]) = default;
     )cpp",
       R"cpp(
       enum $Enum_decl[[En]] {
         $EnumConstant_decl_readonly[[EC]],
       };
       class $Class_def[[Foo]] {};
       class $Class_def[[Bar]] {
       public:
)cpp",
       R"cpp(
       enum $Enum_decl[[E]] {
         $EnumConstant_decl_readonly[[E]],
       };
       class $Class_def[[Foo]] {};
       $Enum_deduced[[auto]] $Variable_def[[AE]] = $Enum[[E]]::$EnumConstant_readonly[[E]];
       $Class_deduced[[auto]] $Variable_def[[AF]] = $Class[[Foo]]();
       $Class_deduced[[decltype]](auto) $Variable_def[[AF2]] = $Class[[Foo]]();
-      $Class_deduced[[auto]] *$Variable_def[[AFP]] = &$Variable[[AF]];
+      $Class_deduced[[auto]] *$Variable_def[[AFP]] = $Operator[[&]]$Variable[[AF]];
       $Enum_deduced[[auto]] &$Variable_def[[AER]] = $Variable[[AE]];
-      $Primitive_deduced_defaultLibrary[[auto]] $Variable_def[[Form]] = 10.2 + 2 * 4;
+      $Primitive_deduced_defaultLibrary[[auto]] $Variable_def[[Form]] = 10.2 $Operator[[+]] 2 $Operator[[*]] 4;
       $Primitive_deduced_defaultLibrary[[decltype]]($Variable[[Form]]) $Variable_def[[F]] = 10;
       auto $Variable_def[[Fun]] = []()->void{};
     )cpp",
       R"cpp(
       class $Class_def[[G]] {};
       template<$Class[[G]] *$TemplateParameter_def_readonly[[U]]>
       class $Class_def[[GP]] {};
       template<$Class[[G]] &$TemplateParameter_def_readonly[[U]]>
       class $Class_def[[GR]] {};
       template<int *$TemplateParameter_def_readonly[[U]]>
       class $Class_def[[IP]] {
         void $Method_def[[f]]() {
-          *$TemplateParameter_readonly[[U]] += 5;
+          $Operator[[*]]$TemplateParameter_readonly[[U]] $Operator[[+=]] 5;
         }
       };
       template<unsigned $TemplateParameter_def_readonly[[U]] = 2>
       class $Class_def[[Foo]] {
         void $Method_def[[f]]() {
           for(int $LocalVariable_def[[I]] = 0;
-            $LocalVariable[[I]] < $TemplateParameter_readonly[[U]];) {}
+            $LocalVariable[[I]] $Operator[[<]] $TemplateParameter_readonly[[U]];) {}
         }
       };
 
       $Class[[G]] $Variable_def[[L]];
       void $Function_def[[f]]() {
         $Class[[Foo]]<123> $LocalVariable_def[[F]];
-        $Class[[GP]]<&$Variable[[L]]> $LocalVariable_def[[LL]];
+        $Class[[GP]]<$Operator[[&]]$Variable[[L]]> $LocalVariable_def[[LL]];
         $Class[[GR]]<$Variable[[L]]> $LocalVariable_def[[LLL]];
       }
     )cpp",
       R"cpp(
       template<typename $TemplateParameter_def[[T]],
         void ($TemplateParameter[[T]]::*$TemplateParameter_def_readonly[[method]])(int)>
       struct $Class_def[[G]] {
         void $Method_def[[foo]](
             $TemplateParameter[[T]] *$Parameter_def[[O]]) {
-          ($Parameter[[O]]->*$TemplateParameter_readonly[[method]])(10);
+          ($Parameter[[O]]$Operator_userDefined[[->*]]$TemplateParameter_readonly[[method]])(10);
+
         }
       };
       struct $Class_def[[F]] {
         void $Method_decl[[f]](int);
       };
       template<void (*$TemplateParameter_def_readonly[[Func]])()>
       struct $Class_def[[A]] {
         void $Method_def[[f]]() {
-          (*$TemplateParameter_readonly[[Func]])();
+          ($Operator[[*]]$TemplateParameter_readonly[[Func]])();
         }
       };
 
       void $Function_def[[foo]]() {
         $Class[[F]] $LocalVariable_def[[FF]];
-        $Class[[G]]<$Class[[F]], &$Class[[F]]::$Method[[f]]> $LocalVariable_def[[GG]];
-        $LocalVariable[[GG]].$Method[[foo]](&$LocalVariable_usedAsMutablePointer[[FF]]);
+        $Class[[G]]<$Class[[F]], $Operator[[&]]$Class[[F]]::$Method[[f]]> $LocalVariable_def[[GG]];
+        $LocalVariable[[GG]].$Method[[foo]]($Operator[[&]]$LocalVariable_usedAsMutablePointer[[FF]]);
         $Class[[A]]<$Function[[foo]]> $LocalVariable_def[[AA]];
       }
     )cpp",
       // Tokens that share a source range but have conflicting Kinds are not
       // highlighted.
       R"cpp(
       #define $Macro_decl[[DEF_MULTIPLE]](X) namespace X { class X { int X; }; }
       #define $Macro_decl[[DEF_CLASS]](T) class T {};
)cpp",
       #define $Macro_decl[[INC_VAR]](X) X += 2
       void $Function_def[[foo]]() {
         $Macro[[DEF_VAR]]($LocalVariable_def[[X]],  123);
         $Macro[[DEF_VAR_REV]](908, $LocalVariable_def[[XY]]);
         int $Macro[[CPY]]( $LocalVariable_def[[XX]] );
         $Macro[[DEF_VAR_TYPE]]($Class[[A]], $LocalVariable_def[[AA]]);
         double $Macro[[SOME_NAME]];
         int $Macro[[SOME_NAME_SET]];
-        $LocalVariable[[variable]] = 20.1;
+        $LocalVariable[[variable]] $Operator[[=]] 20.1;
         $Macro[[MACRO_CONCAT]](var, 2, float);
         $Macro[[DEF_VAR_T]]($Class[[A]], $Macro[[CPY]](
               $Macro[[CPY]]($LocalVariable_def[[Nested]])),
             $Macro[[CPY]]($Class[[A]]()));
         $Macro[[INC_VAR]]($LocalVariable[[variable]]);
       }
       void $Macro[[SOME_NAME]]();
       $Macro[[DEF_VAR]]($Variable_def[[MMMMM]], 567);
       $Macro[[DEF_VAR_REV]](756, $Variable_def[[AB]]);
 
       #define $Macro_decl[[CALL_FN]](F) F();
       #define $Macro_decl[[DEF_FN]](F) void F ()
       $Macro[[DEF_FN]]($Function_def[[g]]) {
         $Macro[[CALL_FN]]($Function[[foo]]);
       }
     )cpp",
       R"cpp(
       #define $Macro_decl[[fail]](expr) expr
       #define $Macro_decl[[assert]](COND) if (!(COND)) { fail("assertion failed" #COND); }
       // Preamble ends.
       int $Variable_def[[x]];
       int $Variable_def[[y]];
       int $Function_decl[[f]]();
       void $Function_def[[foo]]() {
-        $Macro[[assert]]($Variable[[x]] != $Variable[[y]]);
-        $Macro[[assert]]($Variable[[x]] != $Function[[f]]());
+        $Macro[[assert]]($Variable[[x]] $Operator[[!=]] $Variable[[y]]);
+        $Macro[[assert]]($Variable[[x]] $Operator[[!=]] $Function[[f]]());
       }
     )cpp",
       // highlighting all macro references
       R"cpp(
       #ifndef $Macro[[name]]
       #define $Macro_decl[[name]]
       #endif
 
)cpp",
       $Class[[S]] $Variable_def[[Global]][2] = {$Class[[S]](), $Class[[S]]()};
       auto [$Variable_decl[[G1]], $Variable_decl[[G2]]] = $Variable[[Global]];
       void $Function_def[[f]]($Class[[S]] $Parameter_def[[P]]) {
         int $LocalVariable_def[[A]][2] = {1,2};
         auto [$LocalVariable_decl[[B1]], $LocalVariable_decl[[B2]]] = $LocalVariable[[A]];
         auto [$LocalVariable_decl[[G1]], $LocalVariable_decl[[G2]]] = $Variable[[Global]];
         $Class_deduced[[auto]] [$LocalVariable_decl[[P1]], $LocalVariable_decl[[P2]]] = $Parameter[[P]];
         // Highlights references to BindingDecls.
-        $LocalVariable[[B1]]++;
+        $LocalVariable[[B1]]$Operator[[++]];
       }
     )cpp",
       R"cpp(
       template<class $TemplateParameter_def[[T]]>
       class $Class_def[[A]] {
         using $TemplateParameter_decl[[TemplateParam1]] = $TemplateParameter[[T]];
         typedef $TemplateParameter[[T]] $TemplateParameter_decl[[TemplateParam2]];
         using $Primitive_decl[[IntType]] = int;
)cpp",
         @property(readonly, class) $Class[[Foo]] *$Field_decl_readonly_static[[sharedInstance]];
         @end
         @implementation $Class_def[[Foo]]
         @synthesize someProperty = _someProperty;
         - (int)$Method_def[[otherMethod]] {
           return 0;
         }
         - (int)$Method_def[[doSomething]] {
-          $Class[[Foo]].$Field_static[[sharedInstance]].$Field[[someProperty]] = 1;
-          self.$Field[[someProperty]] = self.$Field[[someProperty]] + self.$Field[[otherMethod]] + 1;
-          self->$Field[[_someProperty]] = $Field[[_someProperty]] + 1;
+          $Class[[Foo]].$Field_static[[sharedInstance]].$Field[[someProperty]] $Operator[[=]] 1;
+          self.$Field[[someProperty]] $Operator[[=]] self.$Field[[someProperty]] $Operator[[+]] self.$Field[[otherMethod]] $Operator[[+]] 1;
+          self->$Field[[_someProperty]] $Operator[[=]] $Field[[_someProperty]] $Operator[[+]] 1;
         }
         @end
       )cpp",
       // Member imported from dependent base
       R"cpp(
         template <typename> struct $Class_def[[Base]] {
           int $Field_decl[[member]];
         };
         template <typename $TemplateParameter_def[[T]]>
         struct $Class_def[[Derived]] : $Class[[Base]]<$TemplateParameter[[T]]> {
           using $Class[[Base]]<$TemplateParameter[[T]]>::$Field_dependentName[[member]];
 
           void $Method_def[[method]]() {
             (void)$Field_dependentName[[member]];
           }
         };
       )cpp",
       // Modifier for variables passed as non-const references
       R"cpp(
         struct $Class_def[[ClassWithOp]] {
-            void operator()(int);
-            void operator()(int, int &);
-            void operator()(int, int, const int &);
-            int &operator[](int &);
-            int operator[](int) const;
+            void operator$Operator_decl[[(]]$Operator_decl[[)]](int);
+            void operator$Operator_decl[[(]]$Operator_decl[[)]](int, int &);
+            void operator$Operator_decl[[(]]$Operator_decl[[)]](int, int, const int &);
+            int &operator$Operator_decl[[[]]$Operator_decl[[]]](int &);
+            int operator$Operator_decl[[[]]$Operator_decl[[]]](int) const;
         };
         struct $Class_def[[ClassWithStaticMember]] {
             static inline int $StaticField_def_static[[j]] = 0;
         };
         struct $Class_def[[ClassWithRefMembers]] {
           $Class_def_constrDestr[[ClassWithRefMembers]](int $Parameter_def[[i]])
             : $Field[[i1]]($Parameter[[i]]),
               $Field_readonly[[i2]]($Parameter[[i]]),
)cpp",
 
                            $LocalVariable_usedAsMutableReference[[ptr]],
                            $LocalVariable_readonly_usedAsMutableReference[[constPtr]],
                            $LocalVariable_readonly[[constPtr]],
 
                            $LocalVariable_usedAsMutablePointer[[array]], $LocalVariable_usedAsMutableReference[[array]],
                            $LocalVariable[[array]]
                            );
-          [](int){}($LocalVariable[[val]]);
-          [](int&){}($LocalVariable_usedAsMutableReference[[val]]);
-          [](const int&){}($LocalVariable[[val]]);
+          [](int){}$Operator_userDefined[[(]]$LocalVariable[[val]]$Operator_userDefined[[)]];
+          [](int&){}$Operator_userDefined[[(]]$LocalVariable_usedAsMutableReference[[val]]$Operator_userDefined[[)]];
+          [](const int&){}$Operator_userDefined[[(]]$LocalVariable[[val]]$Operator_userDefined[[)]];
           $Class[[ClassWithOp]] $LocalVariable_def[[c]];
           const $Class[[ClassWithOp]] $LocalVariable_def_readonly[[c2]];
-          $LocalVariable[[c]]($LocalVariable[[val]]);
-          $LocalVariable[[c]](0, $LocalVariable_usedAsMutableReference[[val]]);
-          $LocalVariable[[c]](0, 0, $LocalVariable[[val]]);
-          $LocalVariable[[c]][$LocalVariable_usedAsMutableReference[[val]]];
-          $LocalVariable_readonly[[c2]][$LocalVariable[[val]]];
+          $LocalVariable[[c]]$Operator_userDefined[[(]]$LocalVariable[[val]]$Operator_userDefined[[)]];
+          $LocalVariable[[c]]$Operator_userDefined[[(]]0, $LocalVariable_usedAsMutableReference[[val]]$Operator_userDefined[[)]];
+          $LocalVariable[[c]]$Operator_userDefined[[(]]0, 0, $LocalVariable[[val]]$Operator_userDefined[[)]];
+          $LocalVariable[[c]]$Operator_userDefined[[[]]$LocalVariable_usedAsMutableReference[[val]]$Operator_userDefined[[]]];
+          $LocalVariable_readonly[[c2]]$Operator_userDefined[[[]]$LocalVariable[[val]]$Operator_userDefined[[]]];
         }
         struct $Class_def[[S]] {
           $Class_def_constrDestr[[S]](int&) {
             $Class[[S]] $LocalVariable_def[[s1]]($Field_usedAsMutableReference[[field]]);
             $Class[[S]] $LocalVariable_def[[s2]]($LocalVariable[[s1]].$Field_usedAsMutableReference[[field]]);
 
             $Class[[S]] $LocalVariable_def[[s3]]($StaticField_static_usedAsMutableReference[[staticField]]);
             $Class[[S]] $LocalVariable_def[[s4]]($Class[[S]]::$StaticField_static_usedAsMutableReference[[staticField]]);
           }
           int $Field_decl[[field]];
           static int $StaticField_decl_static[[staticField]];
         };
         template <typename $TemplateParameter_def[[X]]>
         void $Function_def[[foo]]($TemplateParameter[[X]]& $Parameter_def[[x]]) {
           // We do not support dependent types, so this one should *not* get the modifier.
           $Function[[foo]]($Parameter[[x]]);
         }
       )cpp",
       // init-captures
       R"cpp(
         void $Function_def[[foo]]() {
           int $LocalVariable_def[[a]], $LocalVariable_def[[b]];
           [ $LocalVariable_def[[c]] = $LocalVariable[[a]],
-            $LocalVariable_def[[d]]($LocalVariable[[b]]) ]() {}();
+            $LocalVariable_def[[d]]($LocalVariable[[b]]) ]() {}$Operator_userDefined[[(]]$Operator_userDefined[[)]];
         }
       )cpp",
       // Enum base specifier
       R"cpp(
         using $Primitive_decl[[MyTypedef]] = int;
         enum $Enum_decl[[MyEnum]] : $Primitive[[MyTypedef]] {};
       )cpp",
       // Enum base specifier
)cpp",
       )cpp",
       // Issue 1222: readonly modifier for generic parameter
       R"cpp(
         template <typename $TemplateParameter_def[[T]]>
         auto $Function_def[[foo]](const $TemplateParameter[[T]] $Parameter_def_readonly[[template_type]], 
                                   const $TemplateParameter[[auto]] $Parameter_def_readonly[[auto_type]], 
                                   const int $Parameter_def_readonly[[explicit_type]]) {
             return $Parameter_readonly[[template_type]] 
-                 + $Parameter_readonly[[auto_type]] 
-                 + $Parameter_readonly[[explicit_type]];
+                 $Operator_userDefined[[+]] $Parameter_readonly[[auto_type]]
+                 $Operator_userDefined[[+]] $Parameter_readonly[[explicit_type]];
         }
       )cpp",
       // Explicit template specialization
       R"cpp(
         struct $Class_def[[Base]]{};
         template <typename $TemplateParameter_def[[T]]>
         struct $Class_def[[S]] : public $Class[[Base]] {};
         template <>
         struct $Class_def[[S]]<void> : public $Class[[Base]] {};
 
         template <typename $TemplateParameter_def[[T]]>
         $TemplateParameter[[T]] $Variable_def[[x]] = {};
         template <>
         int $Variable_def[[x]]<int> = (int)sizeof($Class[[Base]]);
       )cpp",
+      // operator calls in template
+      R"cpp(
+        template<typename $TemplateParameter_def[[T]]> class $Class_def[[C]] {
+            bool $Method_def[[compare]]($TemplateParameter[[T]] $Parameter_def[[t1]], $TemplateParameter[[T]] $Parameter_def[[t2]]) { return $Parameter[[t1]] $Operator_userDefined[[==]] $Parameter[[t2]]; }
+            $TemplateParameter[[T]] $Method_def[[deref]]($TemplateParameter[[T]] *$Parameter_def[[t]]) { return $Operator_userDefined[[*]]$Parameter[[t]]; }
+        };
+      )cpp",
+      // new and delete
+      R"cpp(
+        struct $Class_def[[S]] { int *$Field_decl[[a]]; };
+        void $Function_def[[f]]() {
+          $Class[[S]] *$LocalVariable_def[[s]] = $Operator[[new]] $Class[[S]];
+          $LocalVariable[[s]]->$Field[[a]] $Operator[[=]] $Operator[[new]] int[10];
+          $Operator[[delete]][] $LocalVariable[[s]]->$Field[[a]];
+          $Operator[[delete]] $LocalVariable[[s]];
+        }
+      )cpp",
+      // explicit operator invocation
+      R"cpp(
+        struct $Class_def[[S]] {
+            $Class[[S]] operator$Operator_decl[[+]](const $Class[[S]] &$Parameter_def_readonly[[other]]);
+        };
+        void $Function_def[[f]]() {
+            $Class[[S]] $LocalVariable_def[[s]];
+            $Class[[S]] $LocalVariable_def[[s2]] = $LocalVariable[[s]].operator$Operator_userDefined[[+]]($LocalVariable[[s]]);
+        }
+      )cpp",
       // no crash
       R"cpp(
         struct $Class_def[[Foo]] {
           void $Method_decl[[foo]]();
         };
 
         void $Function_def[[s]]($Class[[Foo]] $Parameter_def[[f]]) {
-          auto $LocalVariable_def[[k]] = &$Class[[Foo]]::$Method[[foo]];
-          ($Parameter[[f]].*$LocalVariable[[k]])(); // no crash on VisitCXXMemberCallExpr
+          auto $LocalVariable_def[[k]] = $Operator[[&]]$Class[[Foo]]::$Method[[foo]];
+          ($Parameter[[f]]$Operator[[.*]]$LocalVariable[[k]])(); // no crash on VisitCXXMemberCallExpr
         }
       )cpp"};
   for (const auto &TestCase : TestCases)
     // Mask off scope modifiers to keep the tests manageable.
     // They're tested separately.
     checkHighlightings(TestCase, {}, ~ScopeModifierMask);
 
   checkHighlightings(R"cpp(
sizeof...($TemplateParameter[[Elements]]);
 
   checkHighlightings(R"cpp(
     #include "SYSObject.h"
     @interface $Class_defaultLibrary[[SYSObject]] ($Namespace_def[[UserCategory]])
     @property(nonatomic, readonly) int $Field_decl_readonly[[user_property]];
     @end
     int $Function_def[[somethingUsingSystemSymbols]]() {
       $Class_defaultLibrary[[SYSObject]] *$LocalVariable_def[[obj]] = [$Class_defaultLibrary[[SYSObject]] $StaticMethod_static_defaultLibrary[[new]]];
-      return $LocalVariable[[obj]].$Field_defaultLibrary[[value]] + $LocalVariable[[obj]].$Field_readonly[[user_property]];
+      return $LocalVariable[[obj]].$Field_defaultLibrary[[value]] $Operator[[+]] $LocalVariable[[obj]].$Field_readonly[[user_property]];
     }
   )cpp",
                      {{"SystemSDK/SYSObject.h", R"cpp(
     @interface SYSObject
     @property(nonatomic, assign) int value;
     + (instancetype)new;
     @end
   )cpp"}},