C++ syntax highlighting incorrect for variable instance

[sweettyler]

Please see https://github.com/microsoft/vscode/issues/79520 for detail.

[sweettyler]

Same problem even with the latest version 0.25.0-insiders2.

[Colengms]

Hi @sweettyler . I'm unable to reproduce the issue with the information provided. If I add a minimal class to allow the code you posted to the other thread to compile, I get the following:

There must be something about other code being parsed that is leading to an issue. Could you provide a complete repro?

I'd suggest looking previously in the file for error squiggles and resolving them. That might clear up whatever is confusing the parser.

[Colengms]

Actually, based the image you posted, it looks like your code started on line 1 without defining myFile. Are you using a forced include? I would at least expect to see squiggles due to myFile not being defined.

[sweettyler]

Hi @Colengms You are right - if you have defined the class "myFile" then you cannot reproduce what I said. I happened to notice this issue as I first started writing the main() and at that time the class "myFile" was not ready yet. However, my point is, the two variables, "myInput" and "myOuput" should not be highlighted in different colours (not matter the class "myFile" is defined or not).

[Colengms]

I also cannot repro an issue with this as the only content. Rather, I see:

VS Code provides syntactic colorization (TextMate grammar rules). The C/C++ extension adds semantic colorization over that. Semantic colorization is based on having essentially compiled the file to determine context. If the code does not compile, it would be by-design if some semantic colorization were not applied. You might try confirming whether semantic colorization is involved in your repro by disabling it (by setting C_Cpp.enhancedColorization to Disabled). If you are still seeing an issue without semantic colorization enabled, it would be an issue with syntactic colorization, and you might want to pursue that with the issue you have open against VS Code.

[sweettyler]

Hi @Colengms it seems to be related with semantic colorization. If I disable it then "myInput" and "myOuput" are all in white. I still don't have these squiggles, but I think it may appear if I enable or disable some other settings.

[sweettyler]

I also found another small bug, to reproduce it: 1) set "C_Cpp: Enhanced Colorization" to "enabled"; 2) make sure "new_file.cc" doesn't exist; 3) type "code new_test_file.cc" and press "enter"; 3) copy the five lines of my example code to the VScode window, and press "ctrl+s" to save it; 4) notice at this step "myInput" is in white (see attached screenshot); 5) exit VScode; 6) type "code new_file.cc" again and press "enter"; 7) notice this time "myInput" changes to cyan (see attached screenshot);

[sweettyler]

so relaunching VScode makes some difference.

[sean-mcmanus]

Your repro steps match https://github.com/microsoft/vscode-cpptools/issues/4091 so the root cause could be the same, i.e. creating a new file and saving it will cause our underlying document object to have duplicate results, which can be shown via formatting, but it may also break IntelliSense-based stuff (fix should be in our pending 0.25.0 release).

[matter123]

@sean-mcmanus I can reproduce even if I run pkill code (which terminates any Microsoft.VSCode.CPP.* processes) and open a fresh copy of vscode.

[sean-mcmanus]

@matter123 You repro what exactly? The bug I was referring to in https://github.com/microsoft/vscode-cpptools/issues/4109#issuecomment-523194347 could be caused by a TypeScript issue which could repro repeatedly with a new language server process (following the repro steps at https://github.com/microsoft/vscode-cpptools/issues/4109#issuecomment-523185567 ).

[matter123]

that myInput is colored cyan.

In particular, my steps are:

1. Completely close vscode
2. In another editor, save the contents to a new .cpp file
3. run code /path/to/new/file.cpp
4. Observe that myInput becomes colored cyan.

[Colengms]

There is currently a known issue ( https://github.com/microsoft/vscode-cpptools/issues/4091 ) with incorrect behavior after having just launched VS with a new file, which is addressed in the next release (pending).

The issue with having only 1 of the 2 variable instances properly colored is by-design, as semantic colorization depends on essentially compiling the file, and the file is not in a compilable state. It can infer to a limited extent, but after failing to parse the first call to myFile() as a function, it ceases to make the same assumption that myFile is a type for the rest of the file.

[sweettyler]

Semantic colorization exists in several editors and IDEs, like Sublime Text 3 and Eclipse. For the example code, both Sublime Text 3 and Eclipse don't behave as same as VScode does. If this is by design, I think at least some fine-tune is needed.

[Colengms]

The Intellisense (and semantic colorization) in the VS Code C/C++ extension is based on code shared from Visual Studio. Visual Studio shows the same result:

I've opened a feedback item for your issue against VS. It is here if you'd like to upvote it.

[sweettyler]

The second reported issue may have nothing to do with #4091 - after I installed the latest cpptool-0.25.0 and could still reproduce the issue.

[sean-mcmanus]

@sweettyler -- yeah, looks like the fix didn't work 100%, see https://github.com/microsoft/vscode/issues/79252#issuecomment-525025641 .

[Colengms]

The secondary issue (no colorization in newly saved file) should be addressed by https://github.com/microsoft/vscode-cpptools/pull/4153 .

[s4ln1x]

Hi, I think I found a C syntax highlighting issue, should I post here the information or should I create another issue?, P.D. I reach this issue from searching in the issues bar.

[Colengms]

Hi @reycobra . It may depend on what is highlighting incorrectly. The C/C++ extension adds semantic colorization, but the basic syntactic colorization is coming from VS Code and the TextMate grammar for C/C++. One way to find out which is involved would be to disable the setting "C_Cpp.EnhancedColorization". If the issue is still present with that disabled, it would seem to be an issue with the TextMate grammar, which I'd suggesting opening an issue for at https://github.com/jeff-hykin/cpp-textmate-grammar . (Jeff contributes this grammar to VS Code). If the issue is not present with that setting disabled, I'd suggest opening an issue here in vscode-cpptools to discuss it.

[s4ln1x]

Hi @Colengms, thanks for answering!!, the issue is still present after I disabled the setting "C_Cpp.EnhancedColorization", so I will check the issues in the repository you suggested me and if nothing similar to what I'm seeing is happening I will open a new issue there. Thanks again!!!

[prabhavagrawal7]

I have some highlighting issues too. Machine type:- M1 mac air 8 GB ram 256 GB SSD.

#include "bits/stdc++.h"
using namespace std;
#define ll long long

// ordered set
// #include <ext/pb_ds/assoc_container.hpp>
// #include <ext/pb_ds/tree_policy.hpp>
// using namespace __gnu_pbds;
// #define ordered_set tree<int, null_type, less<int>, rb_tree_tag, tree_order_statistics_node_update>

// Uncomment them for optimisations
//#pragma GCC optimize("Ofast")
//#pragma GCC target("avx,avx2,fma")

// for segment tree
// #define mid (start+end)/2
// #define lnode (node*2+1)
// #define rnode (node*2+2)
#define popcount(x) __builtin_popcount(x)
#define GET_MACRO(_1, _2, _3, _4, NAME, ...) NAME
#define range(...)                         \
    GET_MACRO(__VA_ARGS__, r4, r3, r2, r1) \
    (__VA_ARGS__)
#define r4(var, start, stop, step) for (ll var = start; step >= 0 ? var < stop : var > stop; var = var + step)
#define r3(var, start, stop) for (ll var = start; var < stop; var++)
#define r2(var, stop) for (ll var = 0; var < stop; var++)
#define r1(stop) for (ll start_from_0 = 0; start_from_0 < stop; start_from_0++)
#define newint(...) \
    ll __VA_ARGS__; \
    take_input(__VA_ARGS__)
#define min(...) min({__VA_ARGS__})
#define max(...) max({__VA_ARGS__})
#define give(...)           \
    {                       \
        print(__VA_ARGS__); \
        return;             \
    }
#define endl "\n"
#define FULL_INF numeric_limits<double>::infinity()
#define INF INT64_MAX
#define INT_INF INT32_MAX
#define ld long double
#define V vector
#define P pair
#define S set
#define MS multiset
#define M map
#define UM unordered_map
#define US unordered_set
#define MM multimap
#define mt make_tuple
#define mp make_pair
#define pb push_back
#define pf push_front
const ll mod = 1000000007;
// const ll mod = 998244353;
#define FAST ios_base::sync_with_stdio(0), cin.tie(0), cout.tie(0);
#define all(a) a.begin(), a.end()
#define db(x) cout << #x << " = " << x << "\n"
string db_bin(ll n)
{
    string ans;
    while (n)
    {
        ans.push_back((n & 1) + '0');
        n >>= 1;
    }
    reverse(all(ans));
    return ans;
}
#define newstring(str) \
    string str;        \
    cin >> str;
#define foreach(a, x) for (auto &&a : x)
const ld pi = acos(-1);
typedef vector<string> vs;
typedef pair<ll, ll> pii;
typedef vector<ll> vi;
typedef map<ll, ll> mii;
typedef set<ll> si;
typedef vector<vector<ll>> vvi;
template <typename... T>
void take_input(T &&...args) { ((cin >> args), ...); }
vi inputvec(ll n, ll start = 0)
{
    vi vec(n);
    range(i, start, n) cin >> vec[i];
    return vec;
}
template <typename T>
bool btn(T a, T b, T c)
{
    if ((a <= b && b <= c) || (a >= b && b >= c))
        return true;
    return false;
}
template <typename T>
ostream &operator<<(ostream &os, const V<T> &v)
{
    for (int i = 0; i < v.size(); ++i)
    {
        os << v[i];
        if (i != v.size() - 1)
            os << " ";
    }
    return os;
}
template <typename _A, typename _B>
ostream &operator<<(ostream &os, const pair<_A, _B> &p)
{
    os << "[" << p.first << ", " << p.second << "]";
    return os;
}
template <typename... T>
void print(T &&...args)
{
    ((cout << args << " "), ...);
    cout << endl;
}
template <typename... T>
void printl(T &&...args) { ((cout << args << " "), ...); }
inline ld TLD(ll n) { return n; }
ll gcd(ll __m, ll __n) { return __n == 0 ? __m : gcd(__n, __m % __n); }
inline ll rs(ll n) { return (n = n % mod) >= 0 ? n : n + mod; }
ll power(ll x, ll y)
{
    ll res = 1;
    while (y)
    {
        if (y & 1LL)
            res = (res * x) % mod;
        y >>= 1;
        x = (x * x) % mod;
    }
    return res % mod;
}

/* -------------------------------------------------------------------------------------------------------------------------------------------------------- */

class rll
{
private:
    ll val = 0;

    rll power(rll x, rll y)
    {
        rll res = 1;
        while (y)
        {
            if (y % 2 == 1)
                res = (res * x) % mod;
            y = y >> 1;
            x = (x * x) % mod;
        }
        return res % mod;
    }

public:
    operator long long() const {return this->val;}
    template <typename T, typename = typename enable_if<is_arithmetic<T>::value, T>::type>
    rll(T val){this->val = val;}
    inline rll operator+(rll a){ a.val = (this->val + a.val)%mod; return a; }
    inline rll operator-(rll a){ a.val = ((this->val - a.val)%mod+mod)%mod; return a; }
    inline rll operator*(rll a){ a.val = (a.val*this->val)%mod; return a; }
    inline rll operator/(rll a){ return power(a, mod - 2) * (*this); }
    inline rll operator%(rll a){ a.val = (this->val % a.val)%mod; return a; }
    inline rll operator>>(rll a){ a.val = (this->val >> a.val)%mod; return a; }

    template <typename T, typename = typename enable_if<is_arithmetic<T>::value, T>::type>
    inline rll operator+(T a){ return *this + rll(a); }
    template <typename T, typename = typename enable_if<is_arithmetic<T>::value, T>::type>
    inline rll operator-(T a){ return *this - rll(a); }
    template <typename T, typename = typename enable_if<is_arithmetic<T>::value, T>::type>
    inline rll operator*(T a){ return *this * rll(a); }
    template <typename T, typename = typename enable_if<is_arithmetic<T>::value, T>::type>
    inline rll operator/(T a){ return *this / rll(a); }
    template <typename T, typename = typename enable_if<is_arithmetic<T>::value, T>::type>
    inline rll operator%(T a){ return *this % rll(a); }
    template <typename T, typename = typename enable_if<is_arithmetic<T>::value, T>::type>
    inline rll operator>>(T a){ return *this >> rll(a); }

    template <typename T, typename = typename enable_if<is_arithmetic<T>::value, T>::type>
    inline rll operator+=(T a){ return *this = *this + rll(a); }
    template <typename T, typename = typename enable_if<is_arithmetic<T>::value, T>::type>
    inline rll operator-=(T a){ return *this = *this - rll(a); }
    template <typename T, typename = typename enable_if<is_arithmetic<T>::value, T>::type>
    inline rll operator*=(T a){ return *this = *this * rll(a); }
    template <typename T, typename = typename enable_if<is_arithmetic<T>::value, T>::type>
    inline rll operator/=(T a){ return *this = *this / rll(a); }

};
rll power(rll x, rll y)
{
    rll res = 1;
    while (y)
    {
        if (y & 1LL)
            res = (res * x);
        y = y / 2;
        x = (x * x);
    }
    return res;
}
int main()
{
    // Uncomment for faster I/O
    // FAST;
    rll a = 30;
    rll b = 2;
    print(power(2, a));
}

[sean-mcmanus]

@prabhavagrawal7 I'm not able to repro the issue. Can you file a new bug with more repro details, such as the output of running C/C++: Log Diagnostics and your C_Cpp.enhancedColorization setting?

[sean-mcmanus]

@prabhavagrawal7 I reproed the issue now -- our IntelliSense parser is returning incorrect semantic tokens, perhaps due to the usage of the templates. I'll move this to a new issue.

[bobbrow]

The feedback ticket tracking the issue originally tracked by this issue was closed without a fix. Unfortunately, this means that a fix will not be coming to VS Code either. A few other potential bugs were mentioned in this issue. If they have not been addressed, please open a new issue and we can take a look.