(C++) Incorrect highlight of raw string literals
See original GitHub issueIncorrect highlight of raw string literals
A raw string literal will cause any code following it to be highlighted as a string.
Expected behavior
// just to show the error
vector<string> s({R"(JKhf2n"v; 0>qwv>q " JKhf2n"l0 "v42HHf&g )","4U \"N *+ "});
int other_code; // just to show the error
Issue Analytics
- State:
- Created a year ago
- Comments:10 (7 by maintainers)
Top Results From Across the Web
microsoft/vscode-python - Wrong raw string literal highlighting
Backslashes are highlighted as escape characters when a raw string wrapped with lower case r"" but not upper case R"" .
Read more >Scintilla / Bugs / #1668 Incorrect highlighting of raw string literals
It does seem to detect raw string literals correctly, in that if they aren't closed properly the remainder of the file's displayed text...
Read more >What is the rationale for parenthesis in C++11's raw string ...
The purpose of the parentheses is to allow you to specify a custom delimiter: R"foo(Hello World)foo" // the string "Hello World".
Read more >Raw string literal and regex parsing seem incorrect : CPP-31299
Raw string literal and regex parsing seem incorrect ... I got red waves under the backslashes and the end of the line is...
Read more >C# 11 Preview Updates - Raw string literals, UTF-8 and more!
Any number of double quotes less than the number that opened the raw string literal are treated as content. So, in the common...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
This was purposely changed already in 58d911325a2157f6f31c741cd9b24630bf9275c9 so I’d prefer to find a way to keep the highlighting to the end of the file… would adding an exceptional variant here for strings with no “magic label” solve the problem?
What if we just added
"
to the negated match (whether it’s technically valid or not)? Which would prevent the label from gobbling up the earlier"
chars?