-
Notifications
You must be signed in to change notification settings - Fork 10.4k
TryParse support for request delegate source generator #46696
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
Conversation
src/Http/Http.Extensions/gen/StaticRouteHandlerModel/Emitters/EndpointParameterEmitter.cs
Outdated
Show resolved
Hide resolved
ceb0e1d
to
7bd0546
Compare
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.
Looking good so far. What are we waiting for to undraft this? Fixing the indentation? If so, I agree we could probably save this for a follow up PR. Getting string
and nullablity support would be great, but those could probably also be follow-ups if you want.
src/Http/Http.Extensions/gen/StaticRouteHandlerModel/EndpointParameter.cs
Outdated
Show resolved
Hide resolved
@captainsafia and @halter73 ... ready for review. Note that I made some more changes to the ParsabilityHelper that we have from the analyzers to allow me to switch on what kind of parsing method it found. |
src/Http/Http.Extensions/test/RequestDelegateGenerator/RequestDelegateGeneratorTests.cs
Outdated
Show resolved
Hide resolved
src/Http/Http.Extensions/test/RequestDelegateGenerator/RequestDelegateGeneratorTestBase.cs
Outdated
Show resolved
Hide resolved
src/Http/Http.Extensions/gen/StaticRouteHandlerModel/Emitters/EndpointParameterEmitter.cs
Outdated
Show resolved
Hide resolved
src/Http/Http.Extensions/gen/StaticRouteHandlerModel/EndpointParameter.cs
Outdated
Show resolved
Hide resolved
src/Http/Http.Extensions/gen/StaticRouteHandlerModel/EndpointParameter.cs
Outdated
Show resolved
Hide resolved
src/Http/Http.Extensions/gen/StaticRouteHandlerModel/EndpointParameter.cs
Outdated
Show resolved
Hide resolved
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.
LGTM! Some non-blocking things to note:
- Do we support the same DateTime styles options that the RDF currently does? If not, we might want to track this as a follow-up issue.
- I'm not sure what refactoring was tried here but I think some split up will be necessary when #46715 is rebased.
cc: @halter73 for sanity checking the way TryParse
is invoked here
I discussed this a bit with @mitchdenny yesterday. I think we tried to use the "default" NumberStyles where we could because before IParsable support, a lot of the numeric types required passing NumberStyles to TryParse if you also wanted to pass an IFormatProvider which we did for the invariant culture. Now that there's IParsable support, I think we get the same behavior by just calling that. We should verify by looking at the source code. For instance here's the NumberStyles we use for decimal: aspnetcore/src/Shared/ParameterBindingMethodCache.cs Lines 634 to 642 in 33e7a9a
And here's the IParsable implementation which also uses NumberStyles.Number: We should verify this for all the numeric types we special case in ParameterBindingMethodCache.TryGetNumberStylesTryGetMethod like I did for decimal. There aren't that many types we hard-code NumberStyles for in RDF, so it shouldn't be too hard to do manually. But maybe we could update the ParameterBindingMethodCache to prefer the IParsable implementation and see if all the tests still pass (other than some overly specific ones in ParameterBindingMethodCacheTests. We should also add test cases for all the built-in types that we know support TryParse. I see there are some existing theories but they seem to be incomplete. I came up with the original test cases prior to .NET 6 by using reflection to scan the runtime for public TryParse methods. There could even be more now: aspnetcore/src/Http/Http.Extensions/test/RequestDelegateFactoryTests.cs Lines 579 to 609 in 33e7a9a
I think the DateTimeStyles stuff still has impact. We have pretty special logic about adjusting/assuming UTC which I doubt is default. aspnetcore/src/Shared/ParameterBindingMethodCache.cs Lines 136 to 141 in 33e7a9a
We should add the equivalent following test cases for dates to the source generator tests: aspnetcore/src/Http/Http.Extensions/test/RequestDelegateFactoryTests.cs Lines 4253 to 4260 in 33e7a9a
aspnetcore/src/Http/Http.Extensions/test/RequestDelegateFactoryTests.cs Lines 4297 to 4300 in 33e7a9a
aspnetcore/src/Http/Http.Extensions/test/RequestDelegateFactoryTests.cs Lines 4337 to 4338 in 33e7a9a
aspnetcore/src/Http/Http.Extensions/test/RequestDelegateFactoryTests.cs Lines 4375 to 4376 in 33e7a9a
|
src/Http/Http.Extensions/gen/StaticRouteHandlerModel/EndpointParameter.cs
Outdated
Show resolved
Hide resolved
src/Http/Http.Extensions/gen/StaticRouteHandlerModel/EndpointParameter.cs
Outdated
Show resolved
Hide resolved
I just went and compared all the |
Thanks for the test pointers, @halter73. I'll try to get my test consolidation branch in shape so we can take advantage of that... |
👍 In the meantime, I think it should be very quick to add all the types from RDFTests.TryParsableParameters to the new RDGTests.MapAction_SingleNumericParam_StringReturn and similar. We've already defined all the source strings and what they should be parsed to. Doing this would have caught both the Uri issue and the UTC issue with DateTime/DateTimeOffset. |
src/Http/Http.Extensions/gen/StaticRouteHandlerModel/EndpointParameter.cs
Outdated
Show resolved
Hide resolved
We still need to use the DateTimeStyles to |
Done. Found quite a few bugs picking up these test cases. Definitely worth the journey. |
Co-authored-by: Stephen Halter <[email protected]>
…arameter.cs Co-authored-by: Stephen Halter <[email protected]>
7de4bfe
to
8ba7574
Compare
Partially addresses: #46335
This is still a work in progress but I wanted to share the approach early to get feedback. Here I am primarily focused on getting an end to end scenario working (that is being able to call TryParse on a broad selection of types). So far the PR is supporting:
For our contrived test cases it works, but I need to add the following to make it more bulletproof:
Func<string,string,string>
.