-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove C# dynamic support from JsonNode #55430
Conversation
Tagging subscribers to this area: @eiriktsarpalis, @layomia Issue DetailsSee discussion at #53195 We can always add it back in v.next, or add a "new (more modern) dynamic" if\when that comes out.
|
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
src/libraries/System.Text.Json/tests/System.Text.Json.Tests/JsonNode/JsonArrayTests.cs
Show resolved
Hide resolved
src/libraries/System.Text.Json/src/System/Text/Json/Nodes/JsonNode.Dynamic.cs
Show resolved
Hide resolved
@@ -14,6 +15,7 @@ protected override void Add(in TElement value, ref ReadStack state) | |||
((TCollection)state.Current.ReturnValue!).Push(value); | |||
} | |||
|
|||
[DynamicDependency(DynamicallyAccessedMemberTypes.PublicParameterlessConstructor, typeof(Stack<>))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we should take this approach. In the PR to support all the collection types in source-gen mode, #55566, these converters are being used by the source generator. That PR modifies them such that they perform no reflection/rooting (in source-gen mode), e.g. this diff.
I believe the plan is to replace the trimming tests that use the pre-existing serializer overloads with new ones that use the source generator instead - #53437. Given this, could we disable the failing Stack test in this PR and replace it after #55566 goes in? cc @eerhardt
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. I'd rather we just delete the trimming test until we have source gen support.
Do we know why this change is causing the test to fail though?
Test failure appears infrastructure-related:
|
Test failures unrelated:
|
Tagging @dotnet/compat for awareness of the breaking change. |
Marking this as breaking since it's a break from previous preview (which is acceptable, but should be messaged). Please fill out the template here: https://github.com/dotnet/docs/issues/new?assignees=&labels=&template=dotnet-breaking-change.md&title= |
Breaking change issue: dotnet/docs#25105 |
See discussion at #53195
We can always add it back in v.next, or add a "new (more modern) dynamic" if\when that comes out.