Open EFanZh opened 10 years ago
Great catch. Not quite sure how to fix it, yet, as it would require checking if the previous classification span was a preprocessor directive, and want to make sure the check doesn't impact performance negatively.
I guess this is the same type error but in F#/C#. The \123 is colored incorrectly.
let newLines = System.IO.File.ReadAllLines(@"c:\users\12345678\desktopsmall-new.txt") |> Array.toList
@fdncred I did not know F# supported @ strings, so that's definitely a bug. I'll fix that one.
However, I would not expect this to be an issue in C#, are you seeing it happening there as well?
You are correct, sir. This error does not show up in C#.
There seems to be a bug when interpolated and verbatim symbols are both used for the same string in C#. Although the character after the backslash is not escaped, the coloring suggests it is:
private string Test1 => $@"{foo}\bar";
In this screenshot, Test1 is incorrectly colored, but Test2 and Test3 are correct.
Visual Studio 2017 v15.2 (26430.12) Viasfora v3.5.139
@chasingcode Created a separate issue to track this one. Thanks for reporting, interpolated strings give me headaches!
Thank you for the quick response and making such a helpful extension! It's much appreciated
@tomasr - Are you still working on proper highlighting for include files in C++? It's pretty annoying.
Raw string literals that span multiple lines in C++11 are not just not highlighted correctly, but seem to break the brace matching logic so
{
auto s = R"( some string with "quotes" using raw string literals )";
...
will show correctly but
{
auto s = R"( some string with "quotes"
and newlines
using raw string literals )";
...
will try to match the close brace of the literal with the curly brace of the enclosing block and so highlight it as incorrect (and mess up the colouring of matched braces etc thereafter)
For example, in the following code:
"\d" isn't an escape sequence.
Also, the raw string literals are not handled correctly, like this: