IDE response to raw string literals

[allisonchou]

Fixed the following bugs:

• Spaces added between curly brackets in raw interpolated strings (e.g. { x } should be {x})
• Missing completion in raw interpolated strings
• Incorrect behavior in string split handler

Added tests for:

• Completion
• Quick info
• String split command handler
• Formatting (basic case)
• Syntactic classifier (basic case)

TO-DO:

• Testing multi-braced raw interpolated strings, e.g. $$"""{{x}}""". This is difficult with the current test infrastructure since $$ is often considered the cursor position.
• Fix buggy syntactic classifier for multi-braced interpolated strings
• More formatting tests
• Handle string split command handler edge case

Relatest to test plan #55306

[CyrusNajmabadi]

hrmmmmmmm something seems fishy here. we likely want to talk about what's going on here and if it's necessary. i'm guessing we can answer this question without having to stringigy the token. note: the existing code seems uber suspect to me as well :)

[CyrusNajmabadi]

overall seems fine. tests plz :)

[Youssef1313]

I think we'd need another conditional branch for MultiLineRawStringLiteral and SingleLineRawStringLiteral here as well and coordinate the F1 keyword to be used with dotnet/docs team.

if (token.IsKind(SyntaxKind.MultiLineRawStringLiteral) || token.IsKind(SyntaxKind.SingleLineRawStringLiteral))
{
    text = "RawStringLiteral_CSharpKeyword"; // or """_CSharpKeyword
    return true;
}

[Youssef1313]

Consider refactoring this long list of syntax kinds into an extension in https://github.com/dotnet/roslyn/blob/main/src/Compilers/CSharp/Portable/CSharpExtensions.cs

[CyrusNajmabadi]

note: tehse tokens kinds are gone now. sorry!

[CyrusNajmabadi]

test name seems wrong...

[sharwell]

It looks like the intender is applying one too many spaces for interpolated raw strings.

[sharwell]

Suggested change

	// case 1: $"""$$
	// """
	// case 2: $"""
	// text$$
	// """
	// case 1: $"""$$
	// """
	// case 2: $"""
	// text$$
	// """

[CyrusNajmabadi]

the indenter isn't setting where the delimiter goes here. Instead, it's stating where the caret should go when enter is typed above teh delimeter. In that case, the caret is indented the same amount as the final string.

[CyrusNajmabadi]

Merging in. Note that we still need tests around indentation and splitting of raw strings. I will add those myself in a followup.

The comment isn't stating that we will indent the end quote that much, just that we'll align the caret with the indentation of the end quote.