C++ colorization broken by strings with special characters in enums

[BlakeKessler]

I created an enum class in C++, and set the values of the enumerators based by using std::bit_cast on string literals to the underling type of the enum class (admittedly usually a very bad idea to rely on, but I have my reasons). A total of 6 of the string literals I used break VSCode's colorization; all of them involve certain special characters, which I strongly believe to be causal. IntelliSense error reporting is apparently completely unaffected, as it correctly does not find any errors with the relevant code.

The following is a minimal example:

//Plaintext
#include <cstdint>
#include <bit>
using uint32 = uint32_t;

enum class OperatorID : uint32 {
	UNEFFECTED = 0,

	EOS = std::bit_cast<uint32>(";\0\0"),

	COMMA = std::bit_cast<uint32>(",\0\0"),

	LINE_CMNT = std::bit_cast<uint32>("//\0"),
	BLOCK_CMNT_OPEN = std::bit_cast<uint32>("/*\0"),
	BLOCK_CMNT_CLOSE = std::bit_cast<uint32>("*/\0"),

	LIST_CLOSE = std::bit_cast<uint32>("}\0\0"),

	EFFECTED = 1,
};

As is shown by the image, the colorizer appears to be unaware that special characters in strings in the enum are in strings.

• The semicolon and the comma result in the remainder of the strings (including the closing quote) being completely uncolored (there is something a little more complicated going on with these, as the 0 characters would normally be colored in a light green if they appeared immediately after a semicolon).
• The line and block comment tokens act as they would outside of a string. With the example code I show above, this results in the opening parentheses for LINE_CMNT being colored red (because the colorizer thinks that its closing parentheses is commented out), and the opening parentheses for BLOCK_CMNT_OPEN finding the closing parentheses for BLOCK_CMNT_CLOSE. Completely removing the line with BLOCK_CMNT_CLOSE results in the entire rest of the file being colored green (as there is then no block comment closing token) to end the block comment that the colorizer believes exists), and line-commenting it out has no effect (as the only tokens with any effect inside of a block comment are the block comment closing token).
  • NOTE: the above description was created based on an unsaved file. Saving the file resulted in the identifiers that were previously colorized as if they were in comments being colorized correctly, but the operators and numbers being colorized the same as when the file was not saved. I noticed no other changes from saving the file.
• The closing curly bracket act as they would outside of a string. This results in the opening curly bracket for the enum itself matching with that closing curly bracket instead of the one that actually closes the enum definition. This then results in the closing quote on that line not finding its opening quote (causing it to be treated as an opening quote), desynchronizing string colorization for the entire rest of the file (in this case, the entire rest of the file is colored as if it was part of a string literal - adding an opening quote after this point in the file is treated by the colorizer as a closing quote, but the closing curly bracket for the enum's definition is colored red because its opening curly bracket was erroneously matched with the closing curly bracket in the string). The opening parentheses on that line also does not find its closing curly bracket, so is also colored red. The 0 characters on that line are colored as they normally would be (not white like with the semicolon and comma).

I have not tested this in extreme depth, but I hope I found enough to make this error report helpful.

P.S. Not 100% sure this is the right repo to put this error report on. Please direct me to the correct place if it's somewhere else.