@bernd5 We've discussed this and are going to take this change.

We probably need to document a breaking change in https://github.com/dotnet/roslyn/blob/main/docs/compilers/CSharp/Compiler%20Breaking%20Changes%20-%20DotNet%207.md

@dotnet/roslyn-compiler For eyes on this. LDM approved us changing the behavior here as this is the behavior the runtime already changed to in .net core3.0. This is now an impact when we emit interpolated string handlers.

@jcouv Agreed. Does that go in with the PR, or is it a separate process?

@jcouv Agreed. Does that go in with the PR, or is it a separate process?

With this PR

Hopefully final question is: do we need to make a change in VB parsing as well?

My feeling is that vb is likely fine. Since it doesn't support interpolated string handlers right? So it will still emit string. Format and will be ok.

My feeling is that vb is likely fine. Since it doesn't support interpolated string handlers right? So it will still emit string. Format and will be ok.

It doesn't, but it will still parse differently, right? If we're ok with that, then ok. Just wanted a check on whether we think that parsing difference is ok.

@bernd5 looks like there's a couple of nullable issues:

D:\a_work\1\s\src\EditorFeatures\CSharpTest\Classification\SemanticClassifierTests.cs(2609,31): error CS8602: Dereference of a possibly null reference. [D:\a_work\1\s\src\EditorFeatures\CSharpTest\Microsoft.CodeAnalysis.CSharp.EditorFeatures.UnitTests.csproj]
D:\a_work\1\s\src\EditorFeatures\CSharpTest\Classification\SemanticClassifierTests.cs(2623,32): error CS8600: Converting null literal or possible null value to non-nullable type. [D:\a_work\1\s\src\EditorFeatures\CSharpTest\Microsoft.CodeAnalysis.CSharp.EditorFeatures.UnitTests.csproj]

Yes Cyrus removed #nullable disable.
Should we leave it as it was?

Sorry, will fix.

It doesn't, but it will still parse differently, right? If we're ok with that, then ok. Just wanted a check on whether we think that parsing difference is ok.

Before I sign off I'd like @AlekseyTs's thoughts on this as well. Note that this won't change runtime semantics, only the parse tree.

In my eyes VB should be changed, too. But in a separate PR.

I spoke with @AlekseyTs offline about this. We're fine with not changing VB in this PR, and I filed #58043 as a help-wanted issue if someone wants to correct VB parsing in the future.

@RikkiGibson can you look at this community PR as well? It will impact the raw-string-literal work as well, so it would be good to have your eyes on it.

@RikkiGibson @chsienki can you ptal here? thanks!

THanks @bernd5 ! I'll make sure the raw-string-literals work picks this up as well.