The f should be tagged the same as the l.

This is probably going to take awhile, but it needs to be done in order to prevent introducing new bugs when fixing old ones.

Normally unit tests are not so bad when written beforehand, but when there's already ~3000 lines of untested code its a bit more difficult.

Describe the bug

• OS and Version: Ubuntu 18.04.2 LTS
• VS Code Version: 1.31.1
• Better C++ Syntax Extension Version: 1.4.13
• Other extensions you installed (and if the issue persists after disabling them): C/C++. The issue persists after disabling it.
• A clear and concise description of what the bug is: When adding a space between a class access specifier, such as 'public', and the colon, the access specifier loses its coloring.

To Reproduce

1. Create a new file with extension '.cpp'.
2. Input the code below in the newly created file.

class C
{
  public :
};

3. Try removing the space between 'public' and ':'. The keyword should be colored.

Expected behavior
The keyword shall be colored regardless of space between the keyword and colon.

Screenshots

Additional context
This issue exists with default VS code highlighting as well. I'm not sure if it's syntactically correct, but it compiles on GCC/clang.

Describe the bug

• OS and Version: Ubuntu 18.04.2 LTS
• VS Code Version: 1.31.1
• Better C++ Syntax Extension Version: 1.4.11
• Other extensions you installed (and if the issue persists after disabling them): C/C++. The issue persists after disabling it.
• A clear and concise description of what the bug is: When linebreaking after an inheritance colon, the access specifier, such as 'public', is not colorized.

To Reproduce

1. Create a new file with extension '.cpp'.
2. Input the code below in the newly created file. Note the linebreak after the colon.

class B
{};

class A : 
  public B
{};

3. Try removing the linebreak, writing 'public B' on the same line as 'class A'. The keyword is suddenly colorized.

Expected behavior
The 'public' keyword should be colorized regardless if there is a linebreak or not.

Screenshots

Additional context
This issue exists with default VS code highlighting as well.

See https://en.cppreference.com/w/cpp/language/user_literal

A multiline comment with preceding asterisks on each line highlights weird in VS Code. (See below). I'd like to see the entire comment green in this example, not just everything after the first line. Can this fix be included in the extension?

NOTE: The end */ will be green if it's moved up a line.

atom/language-c#273

const char * a = "foo ??/" ??/??/";

According to the standard identifiers are allowed to contain universal-character-names ([lex.name]/1).
Universal-character-names are of the the pattern /\\u[0-9a-fA-F]{4}/ or /\\U[0-9a-fA-F{8}/. When these characters are inserted into a place where identifiers are expected highlighting breaks.

generate_c.rb is not able to generate syntaxes/c.tmLanguage.json as It appears to be a stub and c_grammar is not a Grammar object. Additionally generate_c.rb is missing several referenced variables:

• function_definition_pattern
• probably_a_parameter_2_groups
• operator_overload_4_groups
• variable_name_without_bounds
• non_primitive_types
• primitive_types

This issue precludes fixing issues in the C grammar.

Example code:

class foo : bar {};
class foo : public bar {};

One line 1 bar has the scope meta.class-struct-block.cpp source.cpp.
One line 2 bar has the scope entity.name.type.inherited.cpp meta.class-struct-block.cpp source.cpp.
The scope for bar on each line should be identical.
This is not a regression, and the issue existed prior to #49.

Functions that start with delete or namespace are not colored as functions, and the keyword portion is colored as a keyword.

Additionally, functions whose names are identifiers with special meaning are again not colored as functions.

See photo.

This issue is not present in the default c/cpp grammar

Thanks

Originally From atom/language-c#127
and microsoft/vscode-cpptools#2498

atom/language-c#267

#pragma once

#include <type_traits>

#define IsPointDef(...) \
    template<> \
    struct IsPoint<__VA_ARGS__> \
        {\
        static const bool isPoint = true;\
                }

#define ArrayBasedPointDef(T) \
    IsPointDef(T); \
    template<> \
    struct IsArrayBasedPoint<T>:public std::true_type \
        {};



#define XYBasedPointDef(T) \
    IsPointDef(T); \
    template<> \
    struct IsXYBasedPoint<T>:public std::true_type \
{};

#define TypeTAndUIsPoint \
    template<typename T, typename U, class = typename std::enable_if<IsPoint<T>::isPoint>::type, class = typename std::enable_if<IsPoint<U>::isPoint>::type>

namespace Navigation
{
    namespace Utils
    {
        template<typename T>
        struct IsPoint
        {
            static const bool isPoint = false;
        };

        template<typename T>
        struct IsArrayBasedPoint
        {
            static const bool value = false;
        };

        template<typename T>
        struct IsXYBasedPoint
        {
            static const bool value = false;
        };

    }
}

syntax highlighting breaks after [ ] [ ]
it works only in ( )
it works again after first {

If a template has two 2 < (including the one after template than most syntax highlighting is disabled for the rest of the file.

The rest of the file has the TM scope of template.definition. It looks like the issue first appeared in 1.4.0 ( 1.3.3 does not exhibit this issue).

For debugging

namespace test {
	template <class T>
	struct test {
		template <class U = std::vector<int>>
		bool operator()(U k) {}
	};
	struct test2 {
		bool operator()() = delete;
	};
} // namespace test

// no syntax highlighting
class test2 {};

When decltype() is used in a function scope. The delctype keyword and anything after it has no syntax highlighting. The entire line has the textmate scope of meta.function-call. This issue is not present in the default grammar.

Better C++ Syntax	Default

atom/language-c#118

Sadly this is just outside of the capabilities of TextMate grammars (as noted on the original issue)

atom/language-c#159

/**/ #define a cout << "this works :/\n";

atom/language-c#307

Conversion operators for user-defined or qualified fundamental types are not colored correctly.
See:

TM Grammer inspection of a incorrectly colored operator

TM Grammer inspection of a correctly colored operator

atom/language-c#197

Example code:

namespace {
	using A = decltype(5);
	decltype(5) B = A();
}

This effects decltype, static_assert, template deduction guides (migh not be incorrect however), some macros.
This is because the namespace pattern includes :constructors before $base.

Removing :constructors seems to have almost no negative side effects. (One exception is test::test(){} is not tagged as a constructor, it is also not tagged outside of a namespace currently as well, so a better solution should be found). I cannot think of why constructors should be treated differently inside/outside a namespace.

From @Yanpas on February 15, 2019 14:11

• VSCode Version: 1.31.1
• OS Version: linux

Steps to Reproduce:

1. Insert:

bool aaaa(const char */* comment */) { return true; }

Result:

No matter if you have any c/c++ extensions installed

Does this issue occur when all extensions are disabled?: Yes/No

Copied from original issue: microsoft/vscode#68784

See: https://google.github.io/styleguide/cppguide.html#Constant_Names

VSCode support this if not using this extension

From: #45
Effects: C, C++

In the declaration enum bar b;, bar has incorrect highlighting. bar has the scope of source.{c,cpp}, it should have the scope entity.name.type.{c,cpp} source.{c,cpp}

Image:

Example:

enum bar b;
int foo() {
    enum bar b;
}

atom/language-c#81
atom/language-c#169

class ClassA {    
};

class ClassE final : public ClassA {
};

namespace foo {
    class ClassF {
    };

    class ClassG {
    };
}

class ClassH : public foo::ClassF, public foo::ClassG {
};

>> keyword.operator.bitwise.shift.cpp

I think vsc team should solve this, maybe.

set:

then

This issue is fixed for C++, but it hasn't been ported to C yet
atom/language-c#222
atom/language-c#70

The postWakeup should not be highlighted with the same highlight as member variables. It's very distracting to not be consistent about this.

atom/language-c#269
atom/language-c#290
atom/language-c#280

Almost all of these involve code that is highlighted differently because of preprocessor statements.
Most of them are impossible because the TextMate parser needs to find the end of something, but the preprocessor makes it possible for there to be two ends, and TextMate can't handle conditional endings.

However, one improvement that probably can be made, is that the macros should not include any of the TextMate range patterns. This is because if they do, they can screw up the entire rest of the file.

a-f have different color than 0-9, don't think that's intended.

For a class or struct name, guarantee consistency in the whole file.
My vscode define a struct such as in a .cpp file:

I hope the node and MAX can have the same color in the main function.
Can I have some ways to solve this?

This extension

VSCode default

This is a minor issue, but +, * and & all lost its color when using this extension, ideally they should be highlighted with a different color than int.

Currently there is no special coloring for these keywords: https://en.cppreference.com/w/cpp/language/operator_alternative

and, and_eq, bitand, bitor, compl etc.

Similar to #37 after a C++ attribute [[fallthrough]],[[nodiscard]], etc. Syntax highlighting breaks until {.

Example

switch(test) {
	case 1:
	break;
	case 2: [[fallthrough]];
	case 3: break; // no syntax highlighting
}
void func1();
[[noreturn]] void func2(/*syntax highlighting*/); // no syntax highlighting
struct st { // syntax highlighting works now
};
void func3();

Image:

atom/language-c#129

struct foo {
    int (*bar)();
};

union baz {
    int (*quz)();
};

int (*bar) is tagged as a constructor

The grammar causes visual studio code to have a type error in the form of [renderer1] [error] Cannot create property 'id' on string 't': TypeError: Cannot create property 'id' on string 't' git-bisect has determined that the offending commit is 216543b. The issue is found in VSCode 1.32 and insiders as well as the standalone https://github.com/Microsoft/vscode-textmate/ package. The type error seems to have little if any impact on the actual application of scopes, It does however seem to occasionally cause the theme to not be applied.

example:

namespace test {
	class test {
		test(){};
	};
} // namespace test

atom/language-c#236
For example:

std::string string1{"test"};

Example code

int main() {
      if constexpr(std::is_signed_v<char>>) { // no syntax highlighting
      }
}

The entirety of constexpr(std::is_signed_v<char>>) { // no syntax highlighting has the scope of meta.function-call.

Additionally, the developer tools console has the error [2] - Grammar is in an endless loop - Grammar pushed the same rule without advancing.

Neither the begin or end of the range pattern for "c_function_call" consume any characters. Per microsoft/vscode-textmate#12 VSCode has limited support for zero width range matches.

vector <int> v_name (3);
v_name is highlighted as function

atom/language-c#282

atom/language-c#230
atom/language-c#73

This is going to take awhile, but it shouldn't be to complicated. The work for iostream has already been started.

Variables are not being tokenized in global or local scope. This is an issue with C syntax but possibly exists in C++ as well.

Describe the bug

• OS and Version: Ubuntu 18.04.2 LTS
• VS Code Version: 1.32.3
• Better C++ Syntax Extension Version: 1.6.5
• Other extensions you installed (and if the issue persists after disabling them): C/C++. The issue persists after disabling it.
• A clear and concise description of what the bug is: The keywords 'new' and 'delete' are not colorized at all.

To Reproduce

1. Create a new file with extension '.cpp'.
2. Input the code below in the newly created file.

int main()
{
    int* i = new int;
    delete i;
}

Expected behavior
'new' and 'delete' should be colorized.

Additional context
May be true for other keywords as well.

Function parameters lost color

This highlighting is incorrect, and having the 2 different ways of highlighting on the same token is very distracting.

From #45
Effects: C

The code fragment struct f foo has incorrect highlighting. f has the scope source.c when it should have entity.name.type.c source.c

Image:

Example:

struct f foo;
int func() {
    struct f foo;
}