Add refactoring to convert normal (or verbatim) strings to raw strings.

[CyrusNajmabadi]

Looks like this:

Workign on the interpolated form now.

Relates to test plan #55306

[davidwengier]

This seems like a very Windows-centric assumption. What characters does IsNewLine match? Because, and maybe I missed them, but I didn't see tests for other newline characters like \n and \r on their own.

I think this needs a (may change semantics) (or some other wording) note, because this converts specifically defined newline character sequences into whatever the current machine/git repo/etc. happens to be configured to use. If a user checks out a git repo on a mac, runs this refactoring on VS Mac, this could break things.

Unless I'm wrong and the new raw strings exclusively encode \r\n into the value? If so, then I guess this is okay, but would be good to confirm that IsNewLine doesn't match anything other than that.

[CyrusNajmabadi]

So this is a good point. For clarity, whatever newline sequence you wrote, we will embed into your converted string. This means from the language/compiler perspective, on that machine, the literal has the exact meaning as before (no semantics change).

Where it gets subtle though is the absolutely insane behavior of git where it may take a file and just change newlines even that are language relevant when sent to another machine.

In this case, the refactoring is in line with the lang and compiler. However, it is git that ends up causing issues here as it thinks it is sensible to touch programming lines that relate to content.

--

Note that this is a refactoring though. It is opted into the user, presumably because they actually think this is better. And it will be very clear that a single line became multi-line. So i think the user can be trusted to decide if that is acceptable for them given their git config.

[davidwengier]

For clarity, whatever newline sequence you wrote, we will embed into your converted string. This means from the language/compiler perspective, on that machine, the literal has the exact meaning as before (no semantics change).

Read the code now, and yes, I can see that. I think thats probably good, and perhaps even the saviour of it. If I was on a system that used LF, and converted a string that had CRLF, I would expect the IDE would somehow alert me to the fact that I had mixed line endings, and I could easily Ctrl+Z.