clangd SemanticHighlighting: added support for highlighting overloaded operators

[nridge]

Summary

Recently I switched from the default vscode Microsoft C/C++ extension to clangd because of performance reasons.
I found out clangd lacks one of my most liked features from the Microsoft extension: overloaded operators are not highlighted as functions.
This is a very essential semantic indicator, because overloaded operators can have very different functionality.
This patch adds syntax highlighting for the following patterns:

1. operator calls to overloaded operators, e.g.

std::cout << 42; // `<<` is highlighted as if it were a function.
std::string s;
s = "Hello, World!"; // `=` ditto
some_map["key"] = "value"; // `[` and `]`
some_functor(1, 2, 3); // `(` and `)`

2. function calls to overloaded operators in function notation, e.g.

operator<<(std::cout, 42); // `operator<<`
some_ptr->some_field.operator++(); // `operator++`
operator delete[](ptr) // `operator delete[]`

3. any reference to an overloaded operator function, e.g.

const auto &fn = some_struct.operator<<; // `operator<<`

Before:

After:

[iannisdezwart]

Fixed a bug I introduced by removing a null-check. I added the null-check back in again.

[nridge]

Thanks for the patch!

Could you add some tests to clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp as well?

I wrote a bit about how the tests work on Discord, copying for convenience:

In SemanticHighlightingTests.cpp, we have code inputs which are annotated with the highlighting kinds (and in some tests, modifiers) that various tokens should get.
You can build the test suite with ninja ClangdTests
Then you can run an individual test case using a command like ./tools/clang/tools/extra/clangd/unittests/ClangdTests --gtest_filter=SemanticHighlighting.MyTestName

[nridge]

I haven't looked at the patch in detail, but one high level question: have you considered the possibility of adding these highlightings during the findExplicitReferences phase, rather than in CollectExtraHighlightings? (I haven't thought through whether that would work, just wondering if you have. The reason this is worth asking is that if we can get findExplicitReferences to handle overloaded operator calls, other clangd features that use findExplicitReferences would benefit from knowing about such calls as well.)

clang-tools-extra/clangd/SemanticHighlighting.cpp

658

This FIXME was specifically about highlighting mutable reference arguments for overloaded operator calls, so it remains unfixed. (I realize that wasn't super clear.)

[iannisdezwart]

Two changes:

1. Added tests for overloaded operators into SemanticHighlightingTests.
2. Fixed the way tokens are expanded. Previously operator<< would be split into two highlighting tokens: operator and <<. Now it's all one highlighting token. The same is true for all other compound operator keyword statements.

[iannisdezwart]

In D119077#3300271, @nridge wrote:

I haven't looked at the patch in detail, but one high level question: have you considered the possibility of adding these highlightings during the findExplicitReferences phase, rather than in CollectExtraHighlightings? (I haven't thought through whether that would work, just wondering if you have. The reason this is worth asking is that if we can get findExplicitReferences to handle overloaded operator calls, other clangd features that use findExplicitReferences would benefit from knowing about such calls as well.)

I have in fact looked at the possibility of adding the code into findExplicitReferences, but I figured it would be more suitable to add it into CollectExtraHighlightings, because it is easier to distinguish declarations from references. In findExplicitReferences the declaration will be traversed multiple times, so it would be a pain to check if it had already been traversed. I found it was relatively easy to write code that would work in CollectExtraHighlightings, and I also don't know for sure if it's even possible to handle all cases in findExplicitReferences.

Edit: oops, I see I accepted my own revision, uhhhh that was not my intention. How can I undo that?

Also, I think I misunderstood your question, I think putting this code into findExplicitReferences for the non-declaration overloaded operator references would make a lot of sense. It might be a good idea to do this (in an other commit?)

Edit 2: actually now that I think of it, this functionality is already implemented in findExplicitReferences. But for highlighting this causes problems since it only works for a single token, and operator tokens are compound. This is why canHighlightName returns false for overloaded operators, so they will not be highlighted "normally". This patch fixes this by adding code to CollectExtraHighlightings.
In short: findExplicitReferences already contains the functionality you were referring to!

[iannisdezwart]

Fixed formatting & reverted a deleted FIXME comment.

[iannisdezwart]

Would be nice if this can further be reviewed and commited to the repo!

[nridge]

Still haven't had a chance to take a super detailed look, but a few high-level thoughts:

1. The AST nodes that reference operator names should store source ranges associated with the operator names, such that we shouldn't need to do token-by-token manipulation. For example, functionDecl->getNameInfo().getCXXOperatorNameRange().
2. I think I appreciate now the issue with findExplicitReferences(): it gives us ReferenceLoc objects, which store a single SourceLocation but do not retain the AST node containing the reference (thereby not allowing us to access the source range of the reference easily). We've run into this before (here), and contemplated modifying ReferenceLoc to retain the AST node containing the reference, but decided against it, so I guess we should stick to that. That said... would it make sense to handle the single-token cases with findExplicitReferences()? Or would that just end up splitting the logic / duplicating code more?

[nridge]

In D119077#3337107, @nridge wrote:

1. The AST nodes that reference operator names should store source ranges associated with the operator names, such that we shouldn't need to do token-by-token manipulation. For example, functionDecl->getNameInfo().getCXXOperatorNameRange().

Fleshing this out a bit more:

• For FunctionDecl, getNameInfo().getCXXOperatorNameRange() is almost the right thing, but it excludes the operator keyword itself. We know getLocation() was giving us the location of the operator keyword, so we can construct the source range we want as SourceRange(getLocation(), getNameInfo().getCXXOperatorNameRange().getEnd()).
• For DeclRefExpr, we can do the same thing, using DeclRefExpr::getNameInfo().
• For MemberExpr, same thing using MemberExpr::getMemberNameInfo() (and getMemberLoc() as the start of the range).
• For CXXOperatorCallExpr, it seems to only handle single-token cases so we should be good to continue using just getOperatorLoc()

I believe that should allow us to avoid token manipulation altogether.

2. [...] would it make sense to handle the single-token cases with findExplicitReferences()? Or would that just end up splitting the logic / duplicating code more?

Thinking more about this, I don't think it would make sense. For example, it's not the case that all references to overloaded operators could be handled by findExplicitReferences() (there are multi-token reference cases like explicit operator calls). So, let's just keep using CollectExtraHighlightings for all cases here.

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

815

I'm going to suggest that we exercise a few more implicit-call cases:

• single-token, e.g. foo << 1
• operator(), e.g. foo()
• operator[], e.g. foo[1]

(Very interestingly, in the implicit () and [] cases, the opening one seems to be colored by VisitDeclRefExpr but the closing one by VisitCXXOperatorCallExpr. Not quite sure why that is.)

[iannisdezwart]

Thank you for the comment, it's very helpful.

I didn't know exactly how to get all operator token locations and getCXXOperatorNameRange().
This is going to be extremely helpful and will clean up the code to make it more readable.
Thank you for the detailed list of how to get the full operator name token location for each specific token type.

About your comment on the implicit calls to operator[] and operator(),
this was also a workaround. Do you have any idea how to get both parentheses from a single DeclRefExpr?
I researched this, but haven't yet found the answer.

I will try incorporating these changes today or tomorrow, if I can find time.

[nridge]

In D119077#3339812, @iannisdezwart wrote:

About your comment on the implicit calls to operator[] and operator(),
this was also a workaround. Do you have any idea how to get both parentheses from a single DeclRefExpr?
I researched this, but haven't yet found the answer.

Looking at the AST for some example code like this:

struct S {
  void operator()(int);
};

int main() {
  S s;
  s(2);
}

the AST for the line with the implicit call looks like this:

`-CXXOperatorCallExpr 0x9f9ec0 <line:7:3, col:6> 'void' '()'
  |-ImplicitCastExpr 0x9f9ea8 <col:4, col:6> 'void (*)(int)' <FunctionToPointerDecay>
  | `-DeclRefExpr 0x9f9e58 <col:4, col:6> 'void (int)' lvalue CXXMethod 0x9f9588 'operator()' 'void (int)'
  |-DeclRefExpr 0x9f9e18 <col:3> 'S' lvalue Var 0x9f97c0 's' 'S'
  `-IntegerLiteral 0x9f9e38 <col:5> 'int' 2

Note the CXXOperatorCallExpr spand the s(2) (columns 3 through 6), and DeclRefExpr for the call operator spans the (2) (columns 4 through 6).

The current impl uses DeclRefExpr::getLocation() to grab the (, and CXXOperatorCallExpr::getOperatorLoc() to grab the ). The latter works because getOperatorLoc() is documented to behave this way:

/// When \c getOperator()==OO_Call, this is the location of the right
/// parentheses; when \c getOperator()==OO_Subscript, this is the location
/// of the right bracket.

I've proposed that we switch to using DeclRefExpr::getNameInfo().getCXXOperatorNameRange() as the range to highlight. It now occurs to me that for implicit ( ) and [ ], this is likely to return a range that includes the arguments as well, which we don't want. So, we may need to check implicit vs. explicit, and for implicit highlight the start and end tokens separately. Two potential ways for how to do that:

1. Highlight DeclRefExpr::getLocation(). Check if DeclRefExpr::getEndLoc() is different, and if so highlight that too.
2. Same as the current patch, continue visiting CXXOperatorCallExpr, highlight CXXOperatorCallExpr::getOperatorLoc(), and for ( and [ also highlight DeclRefExpr::getLocation().

[nridge]

One final note: many of the methods I've suggested produce a SourceRange, and we'll need to convert it to Range. I think it should be fine to convert the begin and end SourceLocations separately using getRangeForSourceLocation(), which will give you two Ranges B and E, sanity-check that B <= E, and take (B.begin(), E.end()) as the final range.

That's all I've got for now. I may have follow-up suggestions about code organization / reuse (e.g. factoring out the modifier-setting code), but that will be easier to reason about once the changes discussed so far have been made.

Thanks again for your efforts on this!

[nridge]

@iannisdezwart Hi :) Do you plan to continue to work on this? It seems like we're most of the way there!

[nridge]

Abandoning in favour of D136594

clang-tools-extra/clangd/SemanticHighlighting.cpp

 #include "SourceCode.h"
 #include "support/Logger.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/AST/DeclTemplate.h"
 #include "clang/AST/DeclarationName.h"
+#include "clang/AST/Expr.h"
 #include "clang/AST/ExprCXX.h"
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/AST/Type.h"
 #include "clang/AST/TypeLoc.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
+#include "clang/Basic/TokenKinds.h"
 #include "clang/Tooling/Syntax/Tokens.h"
 #include "llvm/ADT/None.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/Base64.h"
 #include "llvm/Support/Casting.h"
 #include <algorithm>
 
std::vector<HighlightingToken> collect(ParsedAST &AST) && {
     }
     // Copy tokens after the last inactive line
     for (; It != NonConflicting.end(); ++It)
       WithInactiveLines.push_back(std::move(*It));
     return WithInactiveLines;
   }
 
   const HeuristicResolver *getResolver() const { return Resolver; }
+  const SourceManager &getSourceMgr() const { return SourceMgr; }
+  const syntax::TokenBuffer &getTB() const { return TB; }
 
-private:
   llvm::Optional<Range> getRangeForSourceLocation(SourceLocation Loc) {
     Loc = getHighlightableSpellingToken(Loc, SourceMgr);
     if (Loc.isInvalid())
       return llvm::None;
 
     const auto *Tok = TB.spelledTokenAt(Loc);
     assert(Tok);
 
     return halfOpenToRange(SourceMgr,
                            Tok->range(SourceMgr).toCharRange(SourceMgr));
   }
 
+private:
   const syntax::TokenBuffer &TB;
   const SourceManager &SourceMgr;
   const LangOptions &LangOpts;
   std::vector<HighlightingToken> Tokens;
   std::map<Range, llvm::SmallVector<HighlightingModifier, 1>> ExtraModifiers;
   const HeuristicResolver *Resolver = nullptr;
   // returned from addToken(InvalidLoc)
   HighlightingToken InvalidHighlightingToken;
public:
 
   bool VisitCXXConstructExpr(CXXConstructExpr *E) {
     highlightMutableReferenceArguments(E->getConstructor(),
                                        {E->getArgs(), E->getNumArgs()});
 
     return true;
   }
 
+  // Returns the token immediately after a given location.
+  // FIXME: Is this really the best way to do this?
+  const syntax::Token *nextToken(SourceLocation Loc) {
+    if (Loc.isInvalid())
+      return nullptr;
+
+    return llvm::partition_point(
+        H.getTB().spelledTokens(H.getSourceMgr().getFileID(Loc)),
+        [&](const syntax::Token &T) { return T.location() <= Loc; });
+  }
+
+  // Expands the range for a HighlightingToken to another SourceLocation.
+  void expandToken(Range &Range, SourceLocation Loc) {
+    if (Loc.isInvalid())
+      return;
+    Range.end = H.getRangeForSourceLocation(Loc)->end;
+  }
+
+  // For an overloaded operator `operator<<(...)`, we want to the highlighting
+  // to also include the `<<` part. If we don't do this, only the `operator`
+  // part will be correctly highlighted.
+  void expandOverloadedOperator(SourceLocation Loc, Range &OpRange) {
+    const auto *NextTok = nextToken(Loc);
+    if (!NextTok)
+      return;
+
+    expandToken(OpRange, NextTok->location());
+
+    // If this operator is `[` or `(`, we also want to highlight the matching
+    // `]` or `)`.
+    if (NextTok->kind() == tok::l_paren || NextTok->kind() == tok::l_square) {
+      const auto *ParenEndTok = nextToken(NextTok->location());
+      if (ParenEndTok)
+        expandToken(OpRange, ParenEndTok->location()); // `]` or `)`.
+    }
+
+    // If this operator is `new[]` or `delete[]`,
+    // we also want to highlight the `[]` part.
+    else if (NextTok->kind() == tok::kw_new ||
+             NextTok->kind() == tok::kw_delete) {
+      NextTok = nextToken(NextTok->location());
+      if (!NextTok || NextTok->kind() != tok::l_square)
+        return;
+      expandToken(OpRange, NextTok->location()); // `[`.
+      const auto *ParenEndTok = nextToken(NextTok->location());
+      if (ParenEndTok)
+        expandToken(OpRange, ParenEndTok->location()); // `]`.
+    }
+  }
+
+  void highlightOperatorCallExpr(SourceLocation Loc, FunctionDecl *FD) {
+    auto HighlightingKind = kindForDecl(FD, H.getResolver());
+    if (!HighlightingKind)
+      return;
+
+    auto &Tok = H.addToken(Loc, *HighlightingKind);
+    if (auto Mod = scopeModifier(FD))
+      Tok.addModifier(*Mod);
+    if (isConst(FD))
+      Tok.addModifier(HighlightingModifier::Readonly);
+    if (isStatic(FD))
+      Tok.addModifier(HighlightingModifier::Static);
+    if (isAbstract(FD))
+      Tok.addModifier(HighlightingModifier::Abstract);
+    if (isVirtual(FD))
+      Tok.addModifier(HighlightingModifier::Virtual);
+    if (isDependent(FD))
+      Tok.addModifier(HighlightingModifier::DependentName);
+    if (isDefaultLibrary(FD))
+      Tok.addModifier(HighlightingModifier::DefaultLibrary);
+    if (FD->isDeprecated())
+      Tok.addModifier(HighlightingModifier::Deprecated);
+  }
+
+  // Highlight called overloaded operators.
+  // E.g. `<<` in `std::cout << "foo"`.
+  bool VisitCXXOperatorCallExpr(CXXOperatorCallExpr *O) {
+    // Highlight calls to overloaded operators as function-like types.
+    auto *FD = dyn_cast_or_null<FunctionDecl>(O->getCalleeDecl());
+    if (!FD)
+      return true;
+
+    auto HighlightingKind = kindForDecl(FD, H.getResolver());
+    if (!HighlightingKind)
+      return true;
+
+    auto Loc = O->getOperatorLoc();
+    if (Loc.isMacroID())
+      return true;
+
+    highlightOperatorCallExpr(Loc, FD);
+    return true;
+  }
+
+  bool VisitFunctionDecl(FunctionDecl *FD) {
+    if (FD->isOverloadedOperator()) {
+      auto HighlightingKind = kindForDecl(FD, H.getResolver());
+      if (!HighlightingKind)
+        return true;
+
+      auto Loc = FD->getLocation();
+      if (Loc.isInvalid() || Loc.isMacroID())
+        return true;
+
+      Range OpRange = *H.getRangeForSourceLocation(Loc);
+
+      // Also highlight the operator token as part of the function name.
+      // E.g. `<<` in `operator<<`.
+      expandOverloadedOperator(Loc, OpRange);
+
+      auto &Kind = *HighlightingKind;
+      auto &OpKeywTok = H.addToken(OpRange, Kind);
+      OpKeywTok.addModifier(HighlightingModifier::Declaration);
+    }
+
+    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 ...here it would make sense though.
     if (isa<CXXOperatorCallExpr>(E))
       return true;
 
     highlightMutableReferenceArguments(
         dyn_cast_or_null<FunctionDecl>(E->getCalleeDecl()),
         {E->getArgs(), E->getNumArgs()});
 
     return true;
if (auto *ProtoType = FD->getType()->getAs<FunctionProtoType>()) {
               H.addExtraModifier(*Location,
                                  HighlightingModifier::UsedAsMutableReference);
           }
         }
       }
     }
   }
 
+  bool VisitDeclRefExpr(DeclRefExpr *DRE) {
+    if (auto *FD = dyn_cast<FunctionDecl>(DRE->getDecl())) {
+      if (FD->isOverloadedOperator()) {
+        auto Loc = DRE->getLocation();
+        if (Loc.isMacroID())
+          return true;
+
+        const auto *Tok = H.getTB().spelledTokenAt(Loc);
+        if (!Tok)
+          return true;
+
+        if (Tok->kind() == tok::kw_operator) {
+          // Highlight the operator token as part of the function name.
+          // E.g. `<<` in `operator<<`.
+          highlightOverloadedOperatorFunctionNotation(FD, Loc);
+        } else if (Tok->kind() == tok::l_square ||
+                   Tok->kind() == tok::l_paren) {
+          // Highlight the `[` or `(` token that `VisitCXXOperatorCallExpr`
+          // did not highlight.
+          highlightOperatorCallExpr(Loc, FD);
+        }
+      }
+    }
+
+    return true;
+  }
+
+  bool VisitMemberExpr(MemberExpr *ME) {
+    if (auto *FD = dyn_cast<FunctionDecl>(ME->getMemberDecl())) {
+      if (FD->isOverloadedOperator()) {
+        auto Loc = ME->getMemberLoc();
+        if (Loc.isMacroID())
+          return true;
+
+        const auto *Tok = H.getTB().spelledTokenAt(Loc);
+        if (Tok && Tok->kind() == tok::kw_operator) {
+          // Highlight the operator token as part of the function name.
+          // E.g. `<<` in `operator<<`.
+          highlightOverloadedOperatorFunctionNotation(FD, Loc);
+        }
+      }
+    }
+
+    return true;
+  }
+
+  // Handle operator calls in function notation such as `operator<<(...)`.
+  void highlightOverloadedOperatorFunctionNotation(FunctionDecl *FD,
+                                                   SourceLocation Loc) {
+    auto HighlightingKind = kindForDecl(FD, H.getResolver());
+    if (!HighlightingKind || Loc.isInvalid())
+      return;
+
+    Range OpRange = *H.getRangeForSourceLocation(Loc);
+
+    if (!HighlightingKind || Loc.isInvalid())
+      return;
+    // Also highlight the operator token as part of the function name.
+    // E.g. `<<` in `operator<<`.
+    expandOverloadedOperator(Loc, OpRange);
+
+    auto &OpKeywTok = H.addToken(OpRange, *HighlightingKind);
+    if (auto Mod = scopeModifier(FD))
+      OpKeywTok.addModifier(*Mod);
+    if (isConst(FD))
+      OpKeywTok.addModifier(HighlightingModifier::Readonly);
+    if (isStatic(FD))
+      OpKeywTok.addModifier(HighlightingModifier::Static);
+    if (isAbstract(FD))
+      OpKeywTok.addModifier(HighlightingModifier::Abstract);
+    if (isVirtual(FD))
+      OpKeywTok.addModifier(HighlightingModifier::Virtual);
+    if (isDependent(FD))
+      OpKeywTok.addModifier(HighlightingModifier::DependentName);
+    if (isDefaultLibrary(FD))
+      OpKeywTok.addModifier(HighlightingModifier::DefaultLibrary);
+    if (FD->isDeprecated())
+      OpKeywTok.addModifier(HighlightingModifier::Deprecated);
+  }
+
   bool VisitDecltypeTypeLoc(DecltypeTypeLoc L) {
     if (auto K = kindForType(L.getTypePtr(), H.getResolver())) {
       auto &Tok = H.addToken(L.getBeginLoc(), *K)
                       .addModifier(HighlightingModifier::Deduced);
       if (auto Mod = scopeModifier(L.getTypePtr()))
         Tok.addModifier(*Mod);
       if (isDefaultLibrary(L.getTypePtr()))
         Tok.addModifier(HighlightingModifier::DefaultLibrary);

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

const char *TestCases[] = {
       };
       struct {
       } $Variable_decl[[S]];
       void $Function_decl[[foo]](int $Parameter_decl[[A]], $Class[[AS]] $Parameter_decl[[As]]) {
         $Primitive_deduced_defaultLibrary[[auto]] $LocalVariable_decl[[VeryLongVariableName]] = 12312;
         $Class[[AS]]     $LocalVariable_decl[[AA]];
         $Primitive_deduced_defaultLibrary[[auto]] $LocalVariable_decl[[L]] = $LocalVariable[[AA]].$Field[[SomeMember]] + $Parameter[[A]];
         auto $LocalVariable_decl[[FN]] = [ $LocalVariable[[AA]]](int $Parameter_decl[[A]]) -> void {};
-        $LocalVariable[[FN]](12312);
+        $LocalVariable[[FN]]$Method_readonly[[(]]12312$Method_readonly[[)]];
       }
     )cpp",
       R"cpp(
       void $Function_decl[[foo]](int);
       void $Function_decl[[Gah]]();
       void $Function_decl[[foo]]() {
         auto $LocalVariable_decl[[Bou]] = $Function[[Gah]];
       }
)cpp",
       struct $Class_decl[[C]] : $Namespace[[abc]]::$Class[[A]]<$TemplateParameter[[T]]> {
         typename $TemplateParameter[[T]]::$Type_dependentName[[A]]* $Field_decl[[D]];
       };
       $Namespace[[abc]]::$Class[[A]]<int> $Variable_decl[[AA]];
       typedef $Namespace[[abc]]::$Class[[A]]<int> $Class_decl[[AAA]];
       struct $Class_decl[[B]] {
         $Class_decl[[B]]();
         ~$Class[[B]](); // FIXME: inconsistent with constructor
-        void operator<<($Class[[B]]);
+        void $Method_decl[[operator<<]]($Class[[B]]);
         $Class[[AAA]] $Field_decl[[AA]];
       };
       $Class[[B]]::$Class_decl[[B]]() {}
       $Class[[B]]::~$Class[[B]]() {} // FIXME: inconsistent with constructor
       void $Function_decl[[f]] () {
         $Class[[B]] $LocalVariable_decl[[BB]] = $Class[[B]]();
         $LocalVariable[[BB]].~$Class[[B]]();
         $Class[[B]]();
)cpp",
         $Class[[Foo]] *$LocalVariable_decl[[FP]] = ($Class[[Foo]]*)$LocalVariable[[B]];
         int $LocalVariable_decl[[I]] = (int)$LocalVariable[[B]];
       }
     )cpp",
       R"cpp(
       struct $Class_decl[[B]] {};
       struct $Class_decl[[A]] {
         $Class[[B]] $Field_decl[[BB]];
-        $Class[[A]] &operator=($Class[[A]] &&$Parameter_decl[[O]]);
+        $Class[[A]] &$Method_decl[[operator=]]($Class[[A]] &&$Parameter_decl[[O]]);
       };
 
-      $Class[[A]] &$Class[[A]]::operator=($Class[[A]] &&$Parameter_decl[[O]]) = default;
+      $Class[[A]] &$Class[[A]]::$Method_decl[[operator=]]($Class[[A]] &&$Parameter_decl[[O]]) = default;
     )cpp",
       R"cpp(
       enum $Enum_decl[[En]] {
         $EnumConstant_decl_readonly[[EC]],
       };
       class $Class_decl[[Foo]] {};
       class $Class_decl[[Bar]] {
       public:
)cpp",
           $Function[[foo]]($Parameter[[x]]); 
         }
       )cpp",
       // init-captures
       R"cpp(
         void $Function_decl[[foo]]() {
           int $LocalVariable_decl[[a]], $LocalVariable_decl[[b]];
           [ $LocalVariable_decl[[c]] = $LocalVariable[[a]],
-            $LocalVariable_decl[[d]]($LocalVariable[[b]]) ]() {}();
+            $LocalVariable_decl[[d]]($LocalVariable[[b]]) ]() {}$Method_readonly[[(]]$Method_readonly[[)]];
         }
       )cpp",
       // Enum base specifier
       R"cpp(
         using $Primitive_decl[[MyTypedef]] = int;
         enum $Enum_decl[[MyEnum]] : $Primitive[[MyTypedef]] {};
       )cpp",
       // Enum base specifier
       R"cpp(
         typedef int $Primitive_decl[[MyTypedef]];
         enum $Enum_decl[[MyEnum]] : $Primitive[[MyTypedef]] {};
       )cpp",
+      // Overloaded operators
+      R"cpp(
+        struct $Class_decl[[Foo]] {
+          bool $Method_decl[[operator()]]() { return true; }
+          void $Method_decl[[operator<<]](int $Parameter_decl[[K]]) {}
+          operator bool() {} // FIXME: consider how this should be highlighted.
+        };
+
+        namespace $Namespace_decl[[namesp]] {
+          void $Function_decl[[operator--]]($Class[[Foo]] $Parameter_decl[[F]])
+          {}
+        };
+
+        auto $Variable_decl[[a]] =
+          &$Namespace[[namesp]]::$Function[[operator--]];
+
+        void $Function_decl[[operator++]]($Class[[Foo]] &$Parameter_decl[[F]])
+        {}
+
+        int $Function_decl[[main]]() {
+          $Class[[Foo]] $LocalVariable_decl[[foo]];
+          $LocalVariable[[foo]].$Method[[operator()]]();
+          $LocalVariable[[foo]].$Method[[operator<<]](1);
+
+          $Function[[operator++]]($LocalVariable_usedAsMutableReference[[foo]]);
+          $Function[[operator delete[]]]($Function[[operator new[]]](1));
+        }
+      )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(
     class $Class_decl[[A]] {