[release/11.0] Don't report unsupported types for never bound properties - #132783
Open
github-actions[bot] wants to merge 1 commit into
Open
[release/11.0] Don't report unsupported types for never bound properties#132783github-actions[bot] wants to merge 1 commit into
github-actions[bot] wants to merge 1 commit into
Conversation
Fixes #132377. ## Problem The configuration binder source generator reports `SYSLIB1101` ("Property 'X' on type 'Y' is not supported.") and `SYSLIB1100` at the `Bind`/`Get` call site for properties the generated binder never binds: - properties annotated with `[ConfigurationIgnore]` - properties with no public accessor ## Root cause `CreateObjectSpec` queued every property's type via `EnqueueTransitiveType`, passing the `PropertyNotSupported` descriptor, before `isIgnored` was computed and without consulting accessibility. When that type was later found unbindable, the attached diagnostic info was reported against the property. Both checks were only honoured later, at emit time, in `TypeIndex.ShouldBindTo`. ## Fix Build the `PropertySpec` first, then enqueue its type only when the property can take part in binding. A property backing a constructor parameter is still registered, since those are bound regardless of the accessibility of the property describing them. `ShouldBindTo` now short-circuits on the ignore flag and accessibility before resolving the type spec, because excluded types are no longer in the index. --------- Co-authored-by: rosebyte <jaroslav.ruzicka@hotmail.com>
|
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. |
Contributor
|
Tagging subscribers to this area: @dotnet/area-extensions-configuration |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #132455 to release/11.0
/cc @rosebyte
Customer Impact
Customers using Configuration Binder source generation in .NET 11 can receive false
SYSLIB1100orSYSLIB1101diagnostics when a configuration type contains a property that cannot participate in binding, including a property marked[ConfigurationIgnore]or one without a public accessor. This can fail builds that treat warnings as errors, even though the generated binder behaves correctly at run time. This was reported in #132377.Regression
The source generator has always evaluated unsupported property types before filtering properties that cannot participate in binding. The
[ConfigurationIgnore]case has existed since the attribute was introduced in #126396 as new .NET 11 functionality.Testing
Source-generation tests cover private, internal, protected, and
[ConfigurationIgnore]properties. Additional tests verify that unsupported types still produce diagnostics when reached through a bindable property or constructor parameter. The original change in #132455 passed its required checks before being merged intomain.Risk
Low. The change is limited to source-generator type indexing and diagnostic eligibility. Run-time binding behaviour and public APIs are unchanged. The filtering follows the existing binding rules, while tests ensure diagnostics remain for types that are actually reachable by generated binding.