Fallback to treating as object if not collection#106378
Conversation
The reflection binder will fallback if a type does not meet collection heuristics, but the source generator did not.
...crosoft.Extensions.Configuration.Binder/tests/Common/ConfigurationBinderTests.TestClasses.cs
Show resolved
Hide resolved
| spec = CreateCollectionSpec(typeParseInfo); | ||
|
|
||
| // fallback to treating as an object, if we can create it | ||
| if (spec is UnsupportedTypeSpec && type is INamedTypeSymbol && !type.IsAbstract) |
There was a problem hiding this comment.
What types of inputs are deemed to be collections but then return UnsupportedTypeSpec? Could these checks be integrated in the IsCollection predicate instead?
There was a problem hiding this comment.
I considered that -- it's all of the checks here:
IMO pulling those out into the checking method would create two codepaths we have to keep in sync, since many of these checks would need to be duplicated when examining the type and deciding how it would bind.
There was a problem hiding this comment.
Could they be merged into a single Try- method that just outs a valid model? Just a suggestion, I realize we have a deadline today and time is short.
There was a problem hiding this comment.
It's actually a bit more nuanced than just returning false here. Much of the time we want the diagnostics info from this. The fallback turns out to be a bit simpler than this.
It's if we didn't find a way to bind as a collection, and the type can be created and does not implement ICollection<> nor IDictionary<,> than treat as an object.
|
So this has some slightly unusual behavior. The unsupported types test changed as follows.
A derived While this is unusual I'm not sure if we care. Probably the most undesirable part of this is that it used to emit: And now it emits: This is different than the reflection binder. The reflection binder only falls back to object binding if the type does not implement IDictionary<> or ICollection<>. I'll update that fallback logic to be consistent. |
This matches what the refelction binder does, and fixes the baseline diffs (and diagnostics changes) we were seeing for unsupported collection types.
|
Ok, I fixed that and it addressed the diff in baselines/diagnostics. This is ready for a re-review. |
...raries/Microsoft.Extensions.Configuration.Binder/gen/ConfigurationBindingGenerator.Parser.cs
Outdated
Show resolved
Hide resolved
...raries/Microsoft.Extensions.Configuration.Binder/gen/ConfigurationBindingGenerator.Parser.cs
Show resolved
Hide resolved
...raries/Microsoft.Extensions.Configuration.Binder/gen/ConfigurationBindingGenerator.Parser.cs
Show resolved
Hide resolved
|
/backport to release/9.0-rc1 |
|
Started backporting to release/9.0-rc1: https://github.com/dotnet/runtime/actions/runs/10412560148 |
Fixes #96652
The reflection binder will fallback if a type does not meet collection heuristics, but the source generator did not.