I am experiencing a syntax highlighting issue in Visual Studio Code when explicitly specifying the return type for a C++ lambda function. When I include the return type in my lambda function, the colors of the words in my code editor change to a default color scheme. However, if I remove the return type and leave it as an auto-deduced return type, the words are colored correctly. It compiles correctly, is only a highlighting issue.
Note 1: I’m using the Microsoft C/C++ extension (which is already updated).
This is how it looks when return type is explictly specified:
Highlighting issue
This is how it looks when it’s auto-deduced.
No error when it’s auto-deduced
I tried adding "C_Cpp.intelliSenseEngine": "Tag Parser" in my settings.json but didn’t work (the error is worst actually).
Changing the intellisense engine
Note 2: I already have added the "C_Cpp.default.cppStandard": "c++17" in my settings.json.
The entire code I’m testing is:
#include<bits/stdc++.h>
using namespace std;
int main () {
auto fun = [](int param_1, int param_2)->bool{
int sum = param_1 + param_2;
if(sum > 10){
sum -= 10;
}
return sum == 0;
};
return 0;
}
I’m using the Better C++ Syntax extension.
2
Answers
This is a known issue. See https://github.com/jeff-hykin/better-cpp-syntax/issues/405. There are a couple of things you can do:
TL;DR: use the Minimal C++ Syntax extension instead of Better C++ Syntax. It does not have this problem.
C++ has a complicated grammar, and lends itself to certain approaches to syntax highlighting better than others.
Some C++ tokens — such as keywords, comments, most punctuation, and literals (including string, character, and numeric literals) — can be recognized using fairly straightforward textual analysis techniques. Let’s call highlighting these tokens lexical highlighting.
Other C++ tokens, such as identifiers, can have different roles which we want highlighted differently (e.g. variable vs. function vs. type name), but these differences can only be accurately identified using a full semantic understanding of the code (which requires, among other things, parsing #included header files so we know what kind of entities the names referenced from those files denote). Let’s call highlighting these tokens semantic highlighting.
Lexical highlighting is well-suited to client-side (using "client" here from the point of view of the Language Server Protocol) approaches, such as TextMate grammars in the case of VSCode.
Semantic highlighting can only be done accurately by a language server which has built a semantic model of the code, and the Language Server Protocol provides a mechanism (textDocument/semanticTokens) for a language server to perform semantic highlighting.
So, the best highlighting results for C++ are obtained by combining:
Better C++ Syntax tries to employ the tools of lexical highlighting (TextMate grammars) to perform both lexical highlighting and a heuristic attempt at highlighting identifiers (what would normally be done by semantic highlighting). The results are very much mixed (again, semantic highlighting cannot be done accurately in general without a full semantic model), and in the process of trying to provide such heuristic results for identifiers, it sometimes messes up even basic lexical highlighting. In my opinion, this is a misguided approach; it’s perhaps useful in environments where you don’t have access to semantic highlighting, but if you do then Better C++ Syntax just steps on its toes.