Fix config binder source gen for a sole read-only collection ctor param

[TemRevil]

Fixes #131320

The configuration binder source generator emitted an uncompilable call to an Initialize method that was never generated, for a parameterized-constructor type whose only member is a non-bindable copy-constructor collection parameter (a positional record with a single IReadOnlyList, IReadOnlyCollection, IReadOnlySet, or IEnumerable parameter and no other bindable property). The reflection binder handles this shape correctly, so this was a parity regression that broke the build instead.

Root cause: BindingHelperInfo.Builder.TryRegisterTransitiveTypesForMethodGen only registered a type for Initialize-method generation inside the HasBindableMembers(objectSpec) check. But constructor parameters are bound in Initialize independently of whether the type has any other bindable property, per the comment already on the ctor-param property loop a few lines above. For a type where the only "property" is a ctor param backed by a non-bindable read-only collection type, HasBindableMembers is false, so Initialize never got registered/emitted, while the emitter's EmitBindingLogic/EmitObjectInit still unconditionally calls InitializeXxx(...) for any ParameterizedConstructor type.

Fix: register the Initialize method (and walk the constructor-parameter properties needed to bind it) whenever the type has a parameterized constructor, regardless of HasBindableMembers. BindCore registration stays gated on HasBindableMembers as before, since that part is unrelated.

Verified by running the incremental generator directly against the repro from the issue:

var config = new ConfigurationBuilder().Build();
Options options = config.Get<Options>();
public record Options(IReadOnlyList<string> Values);

Before this change the generated source calls InitializeOptions but never defines it, reproducing CS0103: The name 'InitializeOptions' does not exist in the current context exactly. After this change the method is generated and binds the parameter correctly. Confirmed for all four affected collection interfaces (IReadOnlyList, IReadOnlyCollection, IReadOnlySet, IEnumerable).

Added SoleReadOnlyCollectionConstructorParameterIsBindable next to the existing ReadOnlyCollectionConstructorParameterIsBindable test, covering the case where the collection parameter is the type's only member (the existing test always paired it with a second, ordinarily-bindable property, so it didn't exercise this gap).

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

[tarekgh]

A few test-hardening notes on the new regression test. The product change itself looks correct and well targeted; these are non-blocking suggestions. One additional stylistic thought: the sibling ReadOnlyCollectionConstructorParameterIsBindable, ComplexReadOnlyListConstructorParameterIsBindable, and this new Sole... test all cover variations of the same shape, so they could eventually be consolidated into a single data-driven theory.

[TemRevil]

Added functional coverage for both gaps, pushed as 16c022b5. SoleReadOnlyCollectionConstructorParameterIsBindable now populates real config, invokes the compiled assembly, and asserts the bound collection contents for all four interface shapes. Added a sibling test, SoleReadOnlyCollectionConstructorParameterOfComplexElementIsBindable, for the complex-element case: record Options(IReadOnlyList<Child> Values) with no other member. The existing ComplexReadOnlyListConstructorParameterIsBindable always pairs the collection with a bindable Name, so it never actually hit this code path.

On whether IEnumerable<string> exercises the fix: it does. I reverted to the parent commit and ran all four shapes through the generator directly. Pre-fix, IEnumerable<string> fails with the identical CS0103: The name 'InitializeOptions' does not exist as the other three, since it also resolves to CollectionInstantiationStrategy.CopyConstructor in the parser (same as IReadOnlyList/IReadOnlyCollection/IReadOnlySet), so IsCollectionAndCannotOverride excludes it from HasBindableMembers the same way. Post-fix, all four compile and bind correctly.

The nested case turned up something real, though not what either of us expected. Binding Outer.Nested (an Inner whose sole member is a read-only collection ctor param) silently produces null instead of the actual value, no exception. Traced it to CoreBindingHelpers.cs's EmitBindImplForMember, the early return around line 961: !HasBindableMembers(complexType) && ... && InstantiationStrategy == ParameterizedConstructor skips emitting the property assignment entirely, even though InitializeInner is generated correctly and CanInstantiate is true for that exact type. git diff confirms that block is untouched by this PR, present verbatim at the parent commit too, so it's a pre-existing gap in the nested/BindCore path rather than something this fix introduced.

Since it's a different root cause in a different file, I didn't fold a fix into this PR without checking first. Happy to open a follow-up issue with the repro, take a shot at fixing it separately, or fold it into this PR if you'd rather keep it together, whichever you prefer.

[tarekgh]

Thanks for the thorough follow-up.

The functional assertions and the complex-element sole-member test look good, and confirming that IEnumerable<string> hits the same pre-fix failure and now exercises the fixed path resolves my earlier concern. Including all four interface shapes as theory cases is exactly what I was after.

On the nested-usage gap: since the null-binding you found for Outer.Nested is a separate, pre-existing bug that this PR does not touch, let us not fold a fix into this one. Please open a dedicated issue with the minimal repro (the record Options(IReadOnlyList<Child> Values) nested under an outer type) and reference it here so we can track it independently. This PR can merge on its own once the nested case is captured in that issue.

Two small things before I sign off:

1. Can you add a short code comment (or test comment) noting that nested binding of these read-only collection members is tracked separately, so the gap is discoverable from the test file?
2. Please make sure the new theory cases are actually running in CI (check the test count in the log), since source-gen tests can silently skip if the baseline is not built.

[TemRevil]

Pushed ab00bf5: each compilation now gets renamed to a unique name right before Emit in LoadAndInvokeMain, so the loads stop colliding.

Couldn't run the real suite locally (Arcade still isn't tractable in this environment), so I reproduced the exact failure standalone instead: two Roslyn compilations sharing the test name, loaded into AssemblyLoadContext.Default, throw the same FileLoadException you saw in CI. With a unique name per load, four in a row succeed cleanly.

Filed #131399 for the nested-binding gap with the repro and root cause, and added a note in GeneratorTests.cs pointing at it.

Will watch the CI run and confirm the theory cases actually execute this time, not just compile.

[TemRevil]

One more thing turned up once CI ran on the last push: LoadAndInvokeMain uses AssemblyLoadContext, but this project also builds against net481, and System.Runtime.Loader doesn't exist there. The test methods are gated to NetCore only, but the compiler still has to make the helper compile on every target framework, so net481 failed with CS0234 regardless of the runtime gate.

Wrapped the using directive and the method body in #if NET / #else, same split the file already uses a bit further up for baseline paths. The #else branch just throws PlatformNotSupportedException since nothing reaches it.

Couldn't run this through Arcade either, so I checked it with a throwaway project instead: same #if NET structure on net10.0 and net481 builds clean, and reverting the guard reproduces the exact CS0234 on net481. Pushed as 438c01d.

[tarekgh]

LGTM, thanks @TemRevil for providing the changes!

[tarekgh]

@rosebyte @svick could you please have a quick look and merge if you don't have more feedback? Thanks!

[TemRevil]

Thanks for shepherding this one through, @tarekgh. Your test-hardening notes made the regression test noticeably better than what I first pushed, and the pointer about the net481 target saved me a round trip.

I enjoyed digging around the configuration binder source generator, so if there's anything else in that area you'd like a hand with, I'm happy to pick one up.