Fix un-buildable main: ParameterInfo[]/Type[] mismatch in generator instance stubs (re-enables #723/#737/#738/#739)

[nickna]

What this fixes

origin/main currently does not compile:

Compilation/ILCompiler.AsyncGenerators.cs(376,107): error CS1503: Argument 6: cannot convert from 'System.Reflection.ParameterInfo[]' to 'System.Type[]?'
Compilation/ILCompiler.Generators.cs(557,107): error CS1503: Argument 6: cannot convert from 'System.Reflection.ParameterInfo[]' to 'System.Type[]?'

This is a semantic merge conflict between two independently-correct PRs that were merged without being rebased onto each other:

• Compiled closures: generator-arrow top-level capture, instance/async generator write-capture, async-arrow relay (#732 #724 #725 #716) #769 (e64f3adb, compiled closures Compiled: arrow inside an INSTANCE generator method that writes a captured variable (function DC not wired) #724/Compiled: arrow inside an ASYNC generator body that writes a captured variable (full function-DC fix) #725) added EmitGeneratorFunctionDCInit(…, Type[]? paramTypes) and called it from the generator / async-generator instance stub methods, passing their paramTypes local (then a Type[]).
• Fix async/generator IL & interpreter bugs (#727 #728 #721 #720) #786 (b95b6945, "Fix Compiled mode: async/generator private methods (async #m, *#m) emit invalid IL / unsupported #720: async/generator private methods emit invalid IL") changed that same paramTypes local from the AST-resolved Type[] to methodBuilder.GetParameters() (a ParameterInfo[]) — deliberately, so boxing is decided from the method's actual IL signature (a private method's params are all object slots; boxing an AST-resolved double into an object slot is a StackUnexpected).

Each compiled in isolation; together a ParameterInfo[] flows into a Type[]? parameter → CS1503. (Neither side is #787 — that is simply what surfaced this when I went to verify it.)

The fix

Convert at the two call sites with .Select(p => p.ParameterType).ToArray() — the dominant idiom in this codebase for GetParameters() → Type[] (ILCompiler.Classes.Methods.cs:1250, Static.cs:438, Constructors.cs:363). This preserves #720's "box from the actual IL signature" intent: for a private/all-object or #737-widened-to-object slot, ParameterType is object, so IsValueType is false and nothing is spuriously boxed — exactly matching the field-seeding loop directly above each call.

-            EmitGeneratorFunctionDCInit(il, smBuilder.FunctionDCField, method, funcDCKey, paramOffset: 1, paramTypes);
+            EmitGeneratorFunctionDCInit(il, smBuilder.FunctionDCField, method, funcDCKey, paramOffset: 1,
+                paramTypes.Select(p => p.ParameterType).ToArray());

(I considered widening the helper to ParameterInfo[]? instead, but it genuinely operates on Type — it boxes with the element and checks .IsValueType — and two of its four callers pass null; the call-site conversion is the smaller, more idiomatic change.)

Why this matters / relation to #723 #737 #738 #739

The compiled default/optional-parameter cluster (#705/#723/#737/#738/#739) was implemented and merged in #787, but the later merge above left main un-buildable, so those features could not actually run. With the build repaired I verified all four issues' repros, compiled output matching the interpreter:

• Compiled: class methods (instance + static) ignore default parameter values #723 instance/static method defaults — new C().m(5)→7, C.st(5)→7, string default→xz ✓
• Compiled: value-type default parameters on (virtual) instance & static methods are not applied #737 value-type defaults on instance/static + generator methods, incl. the same-arity override-safety case ✓
• Compiled --ref-asm: value-call ignores a value-type default parameter #738 --compile --ref-asm value-call no longer shifts args (f(4)→7) ✓
• Compiled: direct call to an instance/static method or constructor pads an omitted optional (no-default) param with null, not the undefined sentinel #739 omitted optional reads undefined (typeof→"undefined") ✓

Existing coverage Generator_InstanceMethodCallbackMutatesCapturedParameter — an instance generator method whose arrow mutates a captured value-type parameter, the exact path repaired here — exercises the boxing branch and passes. Full unit suite green (13352 passed, 0 failed, 1 skipped).

Follow-ups filed (pre-existing gaps surfaced while verifying)

• Compiled: base-typed call to a derived override that adds trailing optional params dispatches to the base method (override ignored) #790 — a base-typed call to a derived override that adds trailing optional params dispatches to the base method (a different-arity override is not a CLR vtable override). Affects value- and reference-type defaults and no-default optionals; distinct from the same-arity override group Compiled: default/optional params on class members (#705 #723 #737 #739 #738) #787 handles.
• Compiled: a defaulted generator/async-generator parameter captured by a nested arrow ignores its default on omitted args #792 — a defaulted generator/async-generator parameter that is also captured by a nested arrow ignores its default on omitted args (the default prologue writes the state-machine field, but a captured param's live storage is the function-DC field). Intersection of Compiled: value-type default parameters on (virtual) instance & static methods are not applied #737 and Compiled: arrow inside an INSTANCE generator method that writes a captured variable (function DC not wired) #724/Compiled: arrow inside an ASYNC generator body that writes a captured variable (full function-DC fix) #725; reproduces for free-function generators too, so independent of this build fix.

No new tests added: the break is compile-time (caught by any build) and its runtime path is already covered; the two follow-ups are failing cases tracked as issues.

Fixes #723, #737, #738, #739.

[nickna]

Closing as superseded — a concurrent session fixed the same build break first.

This PR repaired an un-buildable main (CS1503 ×2: ParameterInfo[] → Type[]? in the generator/async-generator instance stubs, from the #769×#786 merge seam) by converting at the two call sites. While it was open, main advanced to e8f39905, where commit 35640416 ("Fix broken build: EmitGeneratorFunctionDCInit param type (ParameterInfo[])") already fixed the identical break via the equivalent opposite approach — widening the helper's parameter to ParameterInfo[]? so the stub's methodBuilder.GetParameters() flows in directly. Both are correct and box from the actual IL signature; theirs landed first.

CI here is red only because the PR is built merged with the now-fixed main, which produces the reverse mismatch (Type[] → ParameterInfo[]?). There is no longer any code change to make.

Verification still stands and was re-run against current main (e8f39905):

• Compiled: class methods (instance + static) ignore default parameter values #723 / Compiled: value-type default parameters on (virtual) instance & static methods are not applied #737 / Compiled --ref-asm: value-call ignores a value-type default parameter #738 (--ref-asm) / Compiled: direct call to an instance/static method or constructor pads an omitted optional (no-default) param with null, not the undefined sentinel #739 — all confirmed working, compiled output matching the interpreter.
• Filed Compiled: base-typed call to a derived override that adds trailing optional params dispatches to the base method (override ignored) #790 (a base-typed call to a derived override that adds trailing optional params dispatches to the base method) and Compiled: a defaulted generator/async-generator parameter captured by a nested arrow ignores its default on omitted args #792 (a defaulted generator/async-generator parameter that is also captured by a nested arrow ignores its default on omitted args) as pre-existing gaps surfaced while verifying — both still reproduce on e8f39905.