1st str not hilited correctly:

#error "dddd \
    edddd \
    "
#warning This is a short warning
/* <- keyword.control.import */
#endif
 /* <- keyword.control.import */

If it doesn't end on a semicolon (;) and is followed by string which includes semicolon everything past that is treated as part of the string. See (main is highlighted in blue):

MACRO_AT_THE_TOP()

const char *str =";";
void main() {
  return 0;
}

There are file names with invalid characters, such as ':' and ')'

Given the following code:

int main(){
    int a, b;
    fscanf(input, "%d", &b);
    if(~fscanf(user_output, "%d", &a)) {
        // ...
    }
}

The ~fscanf part inconsistently displayed itself as purple, while when using other operators it displays black for operator and then blues for the function name:

int main(){
    int a, b;
    fscanf(input, "%d", &b);
    if(fscanf(user_output, "%d", &a)) {
        // ...
    }
}

int main(){
    int a, b;
    fscanf(input, "%d", &b);
    if(+fscanf(user_output, "%d", &a)) {
        // ...
    }
}

int main(){
    int a, b;
    fscanf(input, "%d", &b);
    if(-fscanf(user_output, "%d", &a)) {
        // ...
    }
}

Even for bitwise XOR operator ^ the behavior stays the same:

int main(){
    int a, b;
    fscanf(input, "%d", &b);
    if(^fscanf(user_output, "%d", &a)) {
        // ...
    }
}

I believe this caused inconsistency and should be fixed in the future.

C++11 added keyword "noexcept" to the standard which was missing in the syntax file yet.

From @gnaggnoyil on February 23, 2016 12:3

This piece of code:

template <typename T>
struct bar{
    int operator()(char x){
        return 0;
    }
};

struct foo:public bar<int>{
    using bar<int>::operator();
};

seems to produce wrong syntax highlighting results for ollowing class/struct declarations/definations and endif macros. On my workspace(VSCode 0.10.8 with Dark+ (default dark) color scheme) it behaves like this:

Other macros including define, include, if and ifdef are not affected though.

Copied from original issue: microsoft/vscode#3315

From @swgillespie on March 10, 2016 18:52

Repro:

Repro'd on 22dd214678739e71bf51fcba7697e98f33ce191d for me. This only repros in C++ mode - C mode correctly ends the string literal in the right place.

Copied from original issue: microsoft/vscode#3976

I've noticed that multiple inheritance in class definitions confuses syntax coloring. Consider:

class ClassA: public BaseClass
{
public:
void memberFunction();

private:
int memberVariable;
};

versus

class ClassB: public BaseOne, public BaseTwo
{
public:
void memberFunction();

private:
int memberVariable;
};

In the second case, "member1" is colored like a variable.

From @vrabcak on March 23, 2016 6:46

• VSCode Version: 0.10.11
• OS Version: Windows 7

Steps to Reproduce:

1. Enter function call fn("{};"); anywhere in a C++ file
2. Syntax higlighting for the rest of the file gets confused - the string is not ended correctly

However string literal in an expression works fine, e.g. a = "{}";

Copied from original issue: microsoft/vscode#4599

As it stands now, types and values from stdbool.h (bool, _Bool, true, and false) are highlit, but not those from stddef.h (except NULL) and stdint.h. As those are very commonly used (often almost entirely replacing normal integer types), not having them highlit commonly results in slightly harder-to-read code. The keywords in question are:

• stddef.h
  • size_t, wchar_t, ptrdiff_t
  • perhaps offsetof
• stdint.h
  • int8_t, int16_t, int32_t, uint8_t, uint16_t, and uint32_t
  • int_least8_t, int_least16_t, int_least32_t, int_least64_t, uint_least8_t, uint_least16_t, uint_least32_t, and uint_least64_t
  • int_fast8_t, int_fast16_t, int_fast32_t, int_fast64_t, uint_fast8_t, uint_fast16_t, uint_fast32_t, and uint_fast64_t
  • intptr_t and uintptr_t
  • intmax_t and uintmax_t

See screenshot (just type that as shown, the 'int' line will be indented incorrectly).

TextMate 2.0-alpha.9393

C++11 added a new raw string literal syntax. The C++ grammar in this bundle doesn't support it:

You can also see this on github.com, which uses this bundle for highlighting C++ code: https://github.com/LegalizeAdulthood/ucpp-json-parser/blob/2bec48aa1edc40b5d1c82531b005818cb7f6dc53/json_test.cpp#L206. The bug was discovered by one of our users.

Consider the following C++ snippets, respectively from an Unreal Engine C++ repo and a Flax Engine C++ repo (another C++ 3D engine):

// Harrison McGuire
// UE4 Version 4.20.2
// https://github.com/Harrison1/unrealcpp
// https://severallevels.io
// https://harrisonmcguire.com

#pragma once

#include "Camera/CameraShake.h"
#include "MyCameraShake.generated.h"

UCLASS()
class UNREALCPP_API UMyCameraShake: public UCameraShake {
	GENERATED_BODY()
	
	public:
		// Sets default values for this actor's properties
		UMyCameraShake();
	
};

// Copyright © 2022 PrecisionRender. All rights reserved.

#pragma once

#include "Engine/Scripting/Script.h"
#include "Engine/Core/Common.h"

class CharacterController;

API_CLASS() class GAME_API CharacterControllerPro: public Script {
    API_AUTO_SERIALIZATION();
    DECLARE_SCRIPTING_TYPE(CharacterControllerPro);


    public:
        API_ENUM()
        enum class MovementModes {
            Stopped,
            Walking,
            Running,
            Crouching
        };
// ...

From: https://github.com/Harrison1/unrealcpp/blob/master/CameraShake/MyCameraShake.h and https://github.com/PrecisionRender/CharacterControllerPro/blob/main/CharacterControllerProCPP/CharacterControllerPro.h.

As you can see, the keywords class and public are not highlighted, likely because they follow the macros UCLASS() and API_CLASS(), respectively (newlines make no difference). Oddly, the keywords that follow API_ENUM() seem to be highlighted just fine.

struct test {

    test(int x, int d, std::string dave) :
        _x(x),
        _d(d),
        _dave(dave)
    {

    }

    int _x;
    int _d;
    std::string _dave;
};

struct test2 {

    test2(int x, int d, std::string dave) :
        _x(x)
    ,   _d(d)
    ,   _dave(dave)
    {

    }

    int _x;
    int _d;
    std::string _dave;
};

I believe that github uses this repository for its syntax highlighter. Looking above, both pieces of code are the same but show different highlighting. test2 is the broken highlighted version

Example:

# define SIMDTBX_INTEL_GCC_VERSION \

(**GNUC**_10000 +**GNUC_MINOR**_100 + **GNUC_PATCHLEVEL**)

The line starting with "#define" (1st line) is highlighted but not the continuation line (2nd line). That's with Textmate version 2.0 (9090).

In a c or c++ file with a comment at the top of the file the indent after #include #define etc goes wrong. e.g this simple file will the trigger the problem:

/*
 * fs.ch
 */
#include "test.h"

A new line created after "test.h" will be indented. Without the comment in the header it works fine.

This simple line doesn't work properly:

#define foo bar()

The scope of what follows on the next line is still meta.preprocessor.macro.c and meta.function.c.

Any update of this bundle to support new keywords such as nullptr constexpr?

After #endif, comments are not recognized as such:

#if FOO
#endif /* FOO */
#if BAR
#endif // BAR

See here.

The member significand is highlighted in red, while all other members are white. I have searched for matching keywords that might color it this way, but to no avail.

Targets for goto should get unindented to the same indentation level as the current function's braces, but they are ignored.

Further, when manually unindenting goto targets, the lines that follow insist on matching the new indentation level.

There's a little known feature of GCC (and clang) called Computed Includes which is basically a way to use a #define or -D or macro value as the #include argument rather than directly using a fixed string. The manual doesn't show the best examples, but the way this tends to be used is without a closing > or basically: #include <MALLOC_H. It's quirky, but legit. Unfortunately the highlighter expects that closing > (and probably closing ") so the result is an overrun like this.

From @pgrit on March 8, 2016 12:59

The syntax highlighting for C++ is broken in Version 0.10.10. The results differ depending on the color scheme.

Tested on Windows 10 and CentOS 7

Dark+:

Dark:

Copied from original issue: microsoft/vscode#3840

From @gnaggnoyil on February 23, 2016 11:46

I am using currently the latest VSCode version(0.10.8) with 'Dark+ (default dark)' color scheme and the piece of C++ code in the picture below produces wrong syntax highlighting results for following class/struct declarations/definations and endif macros(define, include, if and ifdef macros are not affected though).

Changing foo::bar to somthing that does not use '::' will make all the wrong syntax highlighting results normal again.

Copied from original issue: microsoft/vscode#3309

From @jepessen on November 21, 2015 8:52

When I write a raw string in c++11 that span among many lines, it's not highlighted properly.

What I see:

As you can see, raw string has not the string uniform color.

Copied from original issue: microsoft/vscode#399

Here is the file. There are two percent signs with red background, which is not correct:

https://github.com/dezelin/flang/blob/feature_ocaml_lexer/ocaml-llvm/include/ocamllexer.h

This is the same problem that has been reported here jeff-hykin/better-cpp-syntax#311.

From @mattlanser on March 20, 2016 20:9

• VSCode Version: 0.10.11
• OS Version: Ubuntu 15.10 (64-bit)

Steps to Reproduce:

1. Enter
   asm("movw $0x38, %ax; ltr %ax");

Example:

Copied from original issue: microsoft/vscode#4477

Sorry for the cruddy title, I don't really know the root cause so I made a best effort guess. Feel free to edit it.

The following valid C++ code completely breaks highlighting, namely for the strings:

auto cli = (
	option("--help").set(show_help)
		% "Show this help message",
	(option("-J", "--threads") & value("num_threads", num_threads))
		% "The number of threads to use (default 0, meaning 'auto')",
	value("db_dir").set(dbdir).required(true).blocking(true)
		% "The database directory location",
	any_other(invalid_params)
);

The classes and keywords following the ":" in a class definition never seem to be highlighted. In this example, the "public" should be a keyword and the "BaseClass" should be a type.

class Foo: public BaseClass
{
};

From @rielz on December 27, 2015 16:58

The C++11 specifiers final and override are missing in the C++ syntax file.
They are context specific keywords, so they must not always be classified as a keyword.

Ironically they are present in the C syntax file with some checks for the correct context.
This check fails for some cases though. These three are currently missing in Code:

class deriv final : base {
    void meth1() final;
    void meth2() override;
}

• final and override in class declarations
• final classes ... GitHub seems to be missing that one too 😄

Copied from original issue: microsoft/vscode#1669

Hi there,

Since the bundle update of May 5, it appears that the names of some functions calls are being highlighted in red. See picture:

If I replace the bundle with the previous version from the commit from last year (39898a8), the red highlight disappears.

Perhaps the gl functions are not in the 10.15 SDK?

There are a few bugs in the parsing of this bit of C code:

You can also see this bug on github.com, which uses this bundle for highlighting C code, here: https://github.com/GNOME/clutter/blob/ddda4aec18359aa6bcdff218133c079d4733f155/clutter/clutter-blur-effect.c#L74. This bug was reported to us by one of our users.

TextMate auto-indents C and C++ in an unexpected way. To be specific, I would like to get:

This (1):

switch (x) {
    case 3:
        sdrhit;
    case 4:
        dfsdkfsd;
}

Or this (2):

switch (x) {
case 3:
    sdrhit;
case 4:
    dfsdkfsd;
}

Unfortunately, instead, I get this:

switch (x) {
    case 3:
    sdrhit;
    case 4:
    dfsdkfsd;
}

I figured out how to do this, and here are the necessary edits to the C indent rules:

{   increaseIndentPattern = '(?x)
        ^ .* \{ [^}"'']* $
    |   ^ \s* (public|private|protected): \s* $
    |   ^ \s* @(public|private|protected) \s* $
    |   ^ \s* \{ \} $
    |   ^ \s* (case\b .+ |default):     # NEW!
    ';
    decreaseIndentPattern = '(?x)
        ^ \s* ( (?! \S.* /[*] ) .* [*]/ \s* )? \}
    |   ^ \s* (public|private|protected): \s* $
    |   ^ \s* @(public|private|protected) \s* $
    |   (case\b .+ |default): \s* (/[/*] .*)? $     # NEW!
    ';
    indentNextLinePattern = '(?x)^
        (?! .* [;:{},] \s*                  # do not indent when line ends with ;, :, {, }, or comma
            ( // .* | /[*] .* [*]/ \s* )? $ #  …account for potential trailing comment
        |   @(public|private|protected)     # do not indent after obj-c data access keywords
        )
        .                                  # the negative look-ahead above means we don’t care about what we match here
    ';
    unIndentedLinePattern = '^\s*((/\*|\*/|//|template\b.*?>(?!\(.*\))|@protocol|@optional|@interface(?!.*\{)|@implementation|@end).*)?$';
    zeroIndentPattern = '^\s*#';
}

Even if the devs don't want to make this the default, anyone else encountering this problem could refer to this bug report if they want to change it themselves.

Hi!
If you invoke the "Go to symbol" menu (cmd + shift+ t) in the following C standalone code, you'll see that all the parsing stops after the first #endif. That is, the function any_function() is not listed in the "Go to symbol" menu.

#include "stdio.h"

#define PREPROCESSOR_FLAG

int main (int argc, char const *argv[])
{

  short regular_flag = 1;

  #ifdef PREPROCESSOR_FLAG
  if (regular_flag) {
  #endif
    printf ("Hello world!\n");
  #ifdef PREPROCESSOR_FLAG
  }
  #endif  

  return 0;
}

int any_function () {
  return 0;
}

The issue goes away if I comment out the line inside the first #ifdef block, that is if (regular_flag) {. By doing so however the code does not compile anymore.

I run Textmate 2.0-beta.7.1 on a Retina MacBook Pro with Mac Os X 10.10.2 (Yosemite).

Thank you for your attention!
Cheers,
Guido

From @obhi-d on September 2, 2018 10:8

• VSCode Version: 1.26.1
• OS Version: Ubuntu 18.04

Hello everyone,
I notice that class name with attributes preceding it are not highlighted when declared.
As you can see in this image, the EXPORT keyword is presumed to be the class name by syntax highlighter.

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

Copied from original issue: microsoft/vscode#57771

as seen here: https://github.com/alexfru/SmallerC/blob/master/v0100/include/stdio.h#L104, it's marked red.
Also, as a general note, I made a long time ago a test case for syntax highlighters for C, it's available here: https://gist.github.com/kspalaiologos/3fb07555e68ec39e543e89dcc247676c
It will help to iron most issues, as they seem to be present.

Hi,
Before I start, HIP is an interface for running GPU code on both AMD and NVIDIA GPUs developed by AMD. Here is a sample file I am trying to add HIP support for sublime through this repository because it uses .cpp extension. Will that be ok?

For example:

printf("%.0f", 1.99); // this comment is one color
printf("%f", .1234567") // this comment is in a different color

From @milesxu on March 12, 2016 7:20

When I use vscode to browse the db_bench.cc in the source code of rocksdb, I found the syntax highlighting of C++ is incorrect. Illustrated below:
screenshot of syntax highlighting in vscode,

whereas, the same content displayed in atom

The colors used in atom editor is much richer, and it will not misinterpret keywords in strings such as if or for.
Environment:
ArchLinux 4.4.5 64bit
vscode 0.10.10
atom 1.5.3

Copied from original issue: microsoft/vscode#4061

See video, as soon as I type the 'e' in else, the whole line gets indented out:

https://dl.dropbox.com/u/6879/weirdelse.mov

Admittedly a very minor point and I can certainly live without this, but a hex literal, e.g. 0x1.1e7f4707fc4dcp-9 doesn't seem to be handled properly in the syntax highlighting.

From microsoft/vscode#756:

If a function's parameter is a reference to an array of constants, the data type will be recognized as a function declaration:

If a reference to an array of constants is defined in a block, the data type will not be highlighted:

If a reference to an array (not constant) is defined in a block, the data type will be recognized as a function call:

I found an error in the code highlighting.

#ifdef __cplusplus
extern "C" {
#endif

The endif is not properly set to red color.

#if ((XTIMER_HZ % 15625) == 0)
#error "Unsupported hardware timer frequency (XTIMER_HZ), missing XTIMER_SHIFT \
in board.h? See xtimer.h documentation for more info"
#else
#error "Unknown hardware timer frequency (XTIMER_HZ), check board.h and/or add \
an implementation in sys/include/xtimer/tick_conversion.h"
#endif
#endif

And also in this code the two directives are not correctly set to red.

C++20 has a few new keywords definitely coming: co_await, co_return, co_yield, requires, consteval, constinit, concept, char8_t, import, module

See also the vim syntax file

See screenshot in http://www.twitter.com/DrPizza/status/852290952488243202

On GitHub.com, C++ code is incorrectly highlighted after a line that contains a // comment.

Example code demonstrating the problem:

const byte hello = 1;  // This is a comment
const byte world = 2;  // `const` should be highlighted, but it is not

const byte foo = 3; /* This problem does not occur with multiline comments. */
/* Multiple
lines */
const byte bar = 4;

// This comment breaks highlighting as well.
const byte a = 5;
const byte b = 6;

// This also breaks highlighting in other ways
int main() {}

int test() {}

// Even this breaks
x_y();

y_z();

// Another example
a_z(); a_z();

Reporting here because of instructions in this repo.

Or directly here:

#include<iostream>

vs

#include <iostream>

However when editing the file, the highlighting is correct (probably because of ACE mode):

_{Moved from here}