Escaped pattern in the summary of GeneratedRegex

[pawchen]

See #88175, the screenshot was showing \. for the IP address regex, which is expected.

But somehow I don't see the same behavior in VS17.8?

Tagging subscribers to this area: @dotnet/area-system-text-regularexpressions
See info in area-owners.md if you want to be subscribed.

Issue Details

---

See #88175, the screenshot was showing \. for the IP address regex, which is expected.

But somehow I don't see the same behavior in VS17.8?

Author:	pawchen
Assignees:	-
Labels:	area-System.Text.RegularExpressions, untriaged
Milestone:	-

[buyaa-n]

I can see the escaped pattern in VS 17.9.0 Preview 1.1 too, though not sure if this is really an issue, it might depend on our VS config.

@stephentoub is this a real issue?

[stephentoub]

is this a real issue?

Yes, it appears to be. We probably shouldn't be using the Literal(...) function, which I expect is what is doing that escaping.

I can't explain why, though, it wasn't escaped from my initial change, which included the use of this function, so it's possible my explanation is incorrect.

[danmoseley]

@pawchen Want to try that change and see whether it fixes it for you? We'd welcome a PR if so

[pawchen]

After checking the source code of ObjectDisplay.FormatLiteral, yes, the Literal(value) helper outputs what value would look like as a C# string, with quote on or off just means you want "\\n" or \\n.

I could open a PR for this change, but please note that I haven't worked on this repo before, and it's likely that I don't have a powerful enough machine to load and build the debug runtime locally. I'll try what GitHub provides.

[pawchen]

Well, surprise number one, it's more involved than I initially thought, we do need some sort of escaping as the pattern could contain:

1. Illegal xml chars, such as 0x00 and 0xFFFF
2. Multiple lines, which break the /// as single line comment
3. Other invisible chars

So my PR handles those using syntaxes that are the same for C# escape and Regex escape. That means the result will be slightly opinionated. For example, both "\n" and @"\n" will match a line feed despite the string value, we will display \n for both cases. For patterns like "0x00", we will display \u0000.

Surprise number two, I underestimated my machine. This weekend I cloned this repo locally, then ran .\build.cmd clr+libs -rc release, the build took only 5.5 minutes LOL I thought it would be 40mins or more! The biggest headache was actually git failing to clone the 1.2G size of this repo over the wire multiple times until it finally succeeded. Impressive!

[pawchen]

Ops, it turns out this is a lot more involved, my current PR is heading towards the wrong direction. I need to reconsider the implementation and send another PR.