-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Add initial parameter support to RequestDelegateGenerator #46407
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
|
||
if (!operation.TryGetRouteHandlerPattern(out var routeToken)) | ||
{ | ||
Diagnostics.Add(DiagnosticDescriptors.UnableToResolveRoutePattern); |
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 inclined to have each component of the model maintain its own diagnostics. As we build up the diagnostics we emit, it'll make it easier to warn for specific scenarios that might not be immediately accessible at the top-level.
For example, let's say that we find a TryParse
method on a parameter that doesn't have the correct signature. It would be easier to read and track if we were to capture that diagnostic when we're constructing the parameter instead of bubbling it up and capturing them all at the top.
The downside is it does make the code to aggregate them all when we emit a little honky but that seems worth it for the benefits of having diagnostics localized to where they would be thrown (similar to an exception).
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 think it would be better to give EndpointParameter a backreference to Endpoints.Diagnostics if we want to capture the diagnostic while constructing the parameter. I just didn't like greedily creating a list for each small component even though it's not that expensive. The aggregation and repeated declarations were kind of verbose too as you say.
src/Http/Http.Extensions/test/Microsoft.AspNetCore.Http.Extensions.Tests.csproj
Outdated
Show resolved
Hide resolved
src/Http/Http.Extensions/gen/StaticRouteHandlerModel/EndpointParameter.cs
Show resolved
Hide resolved
@halter73 Thoughts on rebasing this and taking it out of draft? |
I'm doing that now. |
Was going to ask the same thing as I'm keen to riff off this but didn't want to get 3 layers deep in merge conflicts ;) |
- The only supported EndpointParameterSources are initially "SpecialTypes" like HttpRequest and CancellationToken. # Conflicts: # src/Http/Http.Extensions/gen/RequestDelegateGenerator.cs # src/Http/Http.Extensions/gen/StaticRouteHandlerModel/Endpoint.cs # src/Http/Http.Extensions/gen/StaticRouteHandlerModel/EndpointResponse.cs # src/Http/Http.Extensions/gen/StaticRouteHandlerModel/StaticRouteHandlerModel.Emitter.cs # src/Http/Http.Extensions/test/RequestDelegateGenerator/RequestDelegateGeneratorTestBase.cs
772352f
to
63bc01f
Compare
@@ -68,7 +65,7 @@ public static string EmitRequestHandler(this Endpoint endpoint) | |||
{{handlerSignature}} | |||
{ | |||
{{setContentType}} | |||
{{resultAssignment}}{{awaitHandler}}handler(); | |||
{{resultAssignment}}{{awaitHandler}}handler({{endpoint.EmitArgumentList()}}); |
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.
Probably something that will need to change when I start working on the parsing, because this list of arguments will need to be mapped to a set of local variables which are injected beforehand to store the results of the appropriate TryParse(...)
operation.
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.
This looks good to me. I think it is something that would be good to get in and start iterating on.
src/Http/Http.Extensions/gen/StaticRouteHandlerModel/EndpointResponse.cs
Outdated
Show resolved
Hide resolved
src/Http/Http.Extensions/gen/StaticRouteHandlerModel/InvocationOperationExtensions.cs
Outdated
Show resolved
Hide resolved
@@ -7,19 +7,39 @@ internal static class WellKnownTypeData | |||
{ | |||
public enum WellKnownType |
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.
Internal?
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 made the other classes internal even though I don't think it matters much in a source generator/analzyer. This one I didn't bother with since it's inside of internal static class WellKnownTypeData
, and I want to move this to the top level in another PR anyway.
} | ||
} | ||
|
||
// TODO: Handle special form types like IFormFileCollection that need special body-reading logic. |
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.
Just for curiosity, what is your idea about form types? Probably you'll need to track them to call ReadFormAsync
somewhere, right?
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.
Yeah. It will be similar to JSON bodies, BindAsync, and even TryParse handling.
There's definitely follow up work, but I think this is in a good state to merge. Can someone please approve this PR? |
src/Http/Http.Extensions/gen/StaticRouteHandlerModel/Endpoint.cs
Outdated
Show resolved
Hide resolved
I noticed a bug when testing with the MinimalSample where we were using the StartLinePosition instead of EndLinePostion. This could lead to KeyNotFoundException's at startup like the following.
I added the fix along with a regression test to this already-approved PR with |
Partially address #46275