Create default arguments during binding

[RikkiGibson]

Closes #17243
Closes #47352

This PR has been organized to try and improve reviewability.

• The first commit moves some methods from LocalRewriter_Call to Binder_Invocation
• The second commit modifies the implementation to make everything work.

[333fred]

Done review pass (commit 2)

[RikkiGibson]

Thanks for the feedback @333fred.

[cston]

BindIndexerDefaultArguments [](start = 27, length = 27)

Does this have any effect?

[RikkiGibson]

Yes. In some scenarios, we can call an indexer whose parameters are all optional by omitting the element access syntax entirely. Here's a test that demonstrates this:

roslyn/src/Compilers/CSharp/Test/Emit/Attributes/AttributeTests_CallerInfoAttributes.cs

Lines 3080 to 3139 in 98cbb71

	[WorkItem(1006447, "http://vstfdevdiv:8080/DevDiv2/DevDiv/_workitems/edit/1006447")]
	[Fact]
	public void Bug1006447_1()
	{
	const string vbSource =
	@"Imports System
	Imports System.Runtime.CompilerServices
	Imports System.Runtime.InteropServices
	Imports System.Text
	<ComImport>
	<Guid(""1F9C3731-6AA1-498A-AFA0-359828FCF0CE"")>
	Public Interface I
	Property X(Optional i as Integer = 0, <CallerFilePath> Optional s As String = Nothing) As StringBuilder
	End Interface
	Public Class A
	Implements I
	Public Property X(Optional i as Integer = 0, Optional s As String = Nothing) As StringBuilder Implements I.X
	Get
	Console.WriteLine(""Get X(""""{0}"""")"", s)
	Return New StringBuilder
	End Get
	Set(value As StringBuilder)
	Console.WriteLine(""Set X(""""{0}"""")"", s)
	End Set
	End Property
	End Class";
	var vbReference = BasicCompilationUtils.CompileToMetadata(vbSource, references: new[] { MscorlibRef_v4_0_30316_17626, SystemCoreRef });
	const string csSource =
	@"using System;
	class C
	{
	I P = new A();
	static void Main()
	{
	new C().P.X = null;
	new C().P.X[1] = null;
	new C { P = { X = null } };
	new C { P = { X = { Length = 0 } } };
	}
	}
	";
	var compilation = CreateCompilationWithMscorlib45(
	new[] { SyntaxFactory.ParseSyntaxTree(csSource, path: @"C:\filename", encoding: Encoding.UTF8) },
	new[] { SystemCoreRef, vbReference },
	TestOptions.ReleaseExe);
	CompileAndVerify(compilation, expectedOutput:
	@"Set X(""C:\filename"")
	Set X(""C:\filename"")
	Set X(""C:\filename"")
	Get X(""C:\filename"")
	");
	}

[cston]

Debug.Assert [](start = 20, length = 12)

Consider moving assert after if so it's executed always.

[RikkiGibson]

@cston @333fred I believe I have addressed all your feedback. Please take another look.

[333fred]

I think this could technically change observable behavior for nullability warnings or IOperation results, but I think that's fine.

[RikkiGibson]

If we decide to start giving nullability warnings for default arguments then we might want to add a nullable suppression to this node, but we'll cross that bridge if we come to it

[333fred]

Done review pass (commit 4). Just a couple of minor comments left.

[333fred]

LGTM (commit 6)

[jaredpar]

We need to pick a much higher number here. It is more than reasonable for a thread to hang for 5 secnds in CI

[RikkiGibson]

Looks like integration tests use 1 minute to wait for things to complete in some places. I'll go with that as a starting point

roslyn/src/VisualStudio/IntegrationTest/TestUtilities/Helper.cs

Line 20 in 4262935

public static readonly TimeSpan HangMitigatingTimeout = TimeSpan.FromMinutes(1);

[jaredpar]

Feel like ForceComplete should change to assert that this part has completed. That is the pattern we usually have elsewhere.

[RikkiGibson]

I didn't find examples of asserting that parts are completed instead of spin-waiting for them to complete when looking through the overrides of Symbol.ForceComplete. Could you provide an example of what you had in mind?

[RikkiGibson]

Should use callerSourceLocation here instead of GetCallerLocation here