Fix: Detect parsability when FromRoute attribute is used

[mitchdenny]

…aming.

Detect parsability even when FromRoute attribute is used to map handler parameters to route parameters.

There was a bug in my recent analyzer change where the following wouldn't produce an error:

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Mvc;
var webApp = WebApplication.Create();
webApp.MapGet("/customers/{cust}", ([FromRoute(Name = "cust")]Customer customer) => {});

public class Customer {}

It should however warn that Customer type is not parsable.

Description

To fix I introduced some logic to resolve the route parameter name if the FromRoute attribute is present. If it is it uses that instead to determine whether to apply the analyzer error. Arguably I could key just off the presence of the [FromRoute] attribute and not drill into the name, but I think we would want to avoid providing this analyzer error in that case and allow another analyzer to warn on a mismatch between route parameters and handler parameters.

Fixes #45581

[JamesNK]

What happens if you do this?

webApp.MapGet("/customers/{cust}", ([FromRoute(Name = "cust")]Customer customer, string cust) => {});

I'm guessing it explodes at runtime. What happens in the parsability analyzer? (we could write an analyzer that detects this situation and warns about it, but it probably wouldn't get much usage)

[JamesNK]

Good find btw. I need to consider using FromRoute.Name in some of the tooling I've written recently.

[mitchdenny]

I'm guessing it explodes at runtime.

Oh interesting. It doesn't throw - it actually works. The route parameter value gets put into the string and TryParse gets called. I'm not entirely sure that this should be considered an error. For example the following is also considered valid:

app.MapGet("/customers/{cust}", ([FromRoute(Name = "cust")] Customer aaa, [FromRoute(Name = "cust")] Customer customer, string cust) => {});

[JamesNK]

I guess there isn't anything wrong with multiple arguments binding to the same route value.

[JamesNK]

LGTM

It would be good to add a unit test of multiple arguments binding to one parameter, just to verify that it doesn't break the analyzer. Maybe a comment to the code as well that it doesn't matter if multiple parameters have the same name.

[JamesNK]

Fixes in various bits of route tooling for this issue: #45720

My PR adds the resolved parameter name to route usage information. I reused and centralized what you did in this PR. It should be possible to simplify this PR by reusing it.

[mitchdenny]

It should be possible to simplify this PR by reusing it.

Will pick this up after the holidays and integrate your changes (assuming they are merged by then).

[mitchdenny]

@JamesNK I integrated your changes into my PR. It involved moving the SymbolExtensions type into a more common location since we use it outside of the pattern analyzer stuff now as well. I also hoisted the ResolveParameterName(...) method into a RouteParameterHelper class so it can be reused (this is because my logic actually loops over the delegate handler parameters - not the route pattern itself).

Wanted to give you a final chance to review before I squash and merge.

[JamesNK]

I made a collection of resolved parameters available from RouteUsageModel:

aspnetcore/src/Framework/AspNetCoreAnalyzers/src/Analyzers/RouteEmbeddedLanguage/Infrastructure/RouteUsageDetector.cs

Lines 25 to 44 in 45fcfb7

	// RouteParameterName can be different from parameter name using FromRouteAttribute. e.g. [FromRoute(Name = "custom_name")]
	internal record struct ParameterSymbol(string RouteParameterName, ISymbol Symbol, ISymbol? TopLevelSymbol = null)
	{
	public bool IsNested => TopLevelSymbol != null;
	}
	internal readonly record struct RouteUsageContext(
	IMethodSymbol? MethodSymbol,
	SyntaxNode? MethodSyntax,
	RouteUsageType UsageType,
	ImmutableArray<ISymbol> Parameters,
	ImmutableArray<ParameterSymbol> ResolvedParameters)
	{
	public RoutePatternOptions RoutePatternOptions => UsageType switch
	{
	RouteUsageType.MvcAction or RouteUsageType.MvcController => RoutePatternOptions.MvcAttributeRoute,
	RouteUsageType.Component => RoutePatternOptions.ComponentsRoute,
	_ => RoutePatternOptions.DefaultRoute,
	};
	}

RouteParameterName uses the attribute to update the route name if needed. Could you pull the information you need from it? e.g. loop through the parameter collection, match on the symbol, then use RouteParameterName

[mitchdenny]

Could you pull the information you need from it? e.g. loop through the parameter collection, match on the symbol, then use RouteParameterName

Are you suggesting something like this:

            var parameterSymbol = routeUsage.UsageContext.ResolvedParameters.FirstOrDefault(p => p.Symbol == (ISymbol)handlerDelegateParameter);
            var routeParameterName = parameterSymbol.RouteParameterName ?? handlerDelegateParameter.Name;

            // Match handler parameter against route parameters. If it is a route parameter it needs to be parsable/bindable in some fashion.
            if (routeUsage.RoutePattern.TryGetRouteParameter(routeParameterName, out var routeParameter))
            {
              ...

If that is the case, it doesn't seem to work. I can never get p.Symbol to match handlerDelegateParameter - which doesn't make sense to me they should be the same object instance right?

... I guess I can just resolve on symbol name in this particular case, but it's troubling that these objects don't ==.