Fix ValidationsGenerator ITypeParameterSymbol handling

[ANcpLua]

Fixes #65418

Summary

The ValidationsGenerator silently skips generic type parameters (ITypeParameterSymbol) and can emit invalid typeof(T) expressions when type parameters leak into ValidatableProperty.Type.

Changes

Source generator — src/Validation/gen/Parsers/ValidationsGenerator.TypesParser.cs

1. ITypeParameterSymbol branch in TryExtractValidatableType — recognizes type parameters and walks their ConstraintTypes to discover concrete validatable types. Adds to visitedTypes before iterating constraints to prevent infinite recursion through circular constraints (e.g., where T : class, IEnumerable<T>).

2. ContainsTypeParameter guards — two guards (record property path + regular property path) that skip properties whose type contains an unresolved type parameter anywhere in the type tree. Without these, the emitter would generate typeof(TSelf) for CRTP patterns like RequestBase<TSelf>.

3. ContainsTypeParameter helper — recursively checks ITypeParameterSymbol, IArrayTypeSymbol, and INamedTypeSymbol.TypeArguments to catch T, T[], List<T>, Dictionary<string, T>, Nullable<T>, etc.

Why all four blocks are one fix

• The ITypeParameterSymbol branch alone (without guards) causes a regression: constraint walking discovers types whose properties contain the type parameter, leading to typeof(TSelf) in emitted code.
• The guards alone (without the branch) would silently drop the properties but never discover the validatable types through constraints.
• The helper is required by the guards.

Test plan

• CanValidateOpenTypeParameterReachableThroughConstraint — repro of the silent-skip bug: the route-handler delegate parameter resolves to an open ITypeParameterSymbol inside a generic endpoint extension MapValidated<T>(...) where T : UserRequest. On main the generator hits the DeclaredAccessibility is not Accessibility.Public guard (NotApplicable for type parameters), TryExtractValidatableType silently returns false, and the resolver never registers UserRequest. The committed snapshot is the expected fixed output; running the test against main produces a snapshot diff showing exactly the 21 missing lines for UserRequest. (Runtime endpoint behavior is identical fixed-vs-unfixed because the framework falls back to reflection-based validation when the static resolver returns false — the snapshot is the deterministic bug witness.)
• CanValidateTypesWithGenericBaseClass — end-to-end regression coverage: CRTP pattern CommandBase<TSelf> where TSelf : CommandBase<TSelf> with concrete derived types validates correctly (class + record paths). Base type properties ([Required]) and derived type properties ([Range]) discovered through CRTP inheritance; runtime endpoint verification confirms validation errors are produced correctly.
• Existing validation tests continue to pass — 30/30 in Microsoft.Extensions.Validation.GeneratorTests, 47/47 in Microsoft.Extensions.Validation.Tests (local).

[dotnet-policy-service]

Thanks for your PR, @@ANcpLua. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[Copilot]

Pull request overview

This PR fixes a critical bug in the ValidationsGenerator source generator where generic type parameters (like TRequest from a generic endpoint extension method) were either silently skipped or caused compilation errors when they leaked into generated typeof() expressions. The fix adds type parameter handling to discover validatable types through constraint types, while preventing type parameters from appearing in emitted code.

Changes:

• Added ITypeParameterSymbol branch in TryExtractValidatableType to walk constraint types and discover validatable types
• Added ContainsTypeParameter guards in both record and regular property extraction paths to prevent emitting typeof(T) expressions
• Added ContainsTypeParameter helper method to recursively detect type parameters in type trees

[ANcpLua]

@ANcpLua please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@dotnet-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@dotnet-policy-service agree

• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@dotnet-policy-service agree company="Microsoft"

Contributor License Agreement

@dotnet-policy-service agree

[ANcpLua]

CI failures are pre-existing infrastructure flakes, unrelated to this change:

• RestartAppShouldNotAffectOtherApps — 36.62% historical failure rate (IIS Express test)
• Cannot create a file when that file already exists — tracked in Known Build Error: error : Cannot create a file when that file already exists. #61178

Happy to re-run if needed.

[azure-pipelines]

Commenter does not have sufficient privileges for PR 65419 in repo dotnet/aspnetcore

[azure-pipelines]

Commenter does not have sufficient privileges for PR 65419 in repo dotnet/aspnetcore

[dotnet-policy-service]

Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime.
To make sure no conflicting changes have occurred, please rerun validation before merging. You can do this by leaving an /azp run comment here (requires commit rights), or by simply closing and reopening.

[Youssef1313]

The added test seems to already be passing without the changes.

@ANcpLua Can you please rebase your branch on latest main, and ensure to create a test case that fails on main to better demonstrate the issue?

[ANcpLua]

@copilot apply changes based on the comments in this thread

[ANcpLua]

@Youssef1313 thanks for the review — pushed fdf8bf6 and a58595c to address both points.

1. Linux x64 / Source-Build CS1615

The most recent merge from main pulled in b58523d4c9 (#66373, "Cleanup ValidationsGenerator for better incrementality"), which dropped the ref from TryExtractValidatableType's HashSet<ValidatableType> and List<ITypeSymbol> parameters. The new ITypeParameterSymbol branch in this PR was still passing them with ref, so the post-merge build failed with CS1615 at ValidationsGenerator.TypesParser.cs(92,99) and (92,121). Fixed by dropping the two ref keywords in the new branch.

2. Test that fails on main

You were right that CanValidateTypesWithGenericBaseClass did not exercise the bug — the parameter at the MapPost call site there is the concrete CreateOrderCommand, so the generator only ever sees the closed CommandBase<CreateOrderCommand> and TSelf is bound by the time it reaches the emitter. The new test CanValidateOpenTypeParameterReachableThroughConstraint puts the MapPost call inside a generic endpoint extension:

public static RouteHandlerBuilder MapValidated<T>(this IEndpointRouteBuilder endpoints, string pattern)
    where T : UserRequest
    => endpoints.MapPost(pattern, (T req) => Results.Ok());

The inner MapPost is the call site the generator inspects, and the delegate parameter resolves to an open ITypeParameterSymbol. On main T hits the DeclaredAccessibility is not Accessibility.Public guard (NotApplicable for type parameters), TryExtractValidatableType returns false, and the concrete constraint UserRequest is never discovered — even though it carries [Required] and [Range] attributes. Running the new test against main produces a snapshot diff with exactly the 21 lines that should describe UserRequest missing:

+            if (type == typeof(global::UserRequest))
+            {
+                validatableInfo = new GeneratedValidatableTypeInfo(
+                    type: typeof(global::UserRequest),
+                    members: [
+                        new GeneratedValidatablePropertyInfo(
+                            containingType: typeof(global::UserRequest),
+                            propertyType: typeof(string),
+                            name: "Name",
+                            displayName: "Name"
+                        ),
+                        ... (Age member) ...
+                    ]
+                );
+                return true;
+            }

With the fix the ITypeParameterSymbol branch walks typeParam.ConstraintTypes, recurses into UserRequest, and emits the expected resolver entry. I verified this end-to-end locally by reverting just TypesParser.cs to main, rebuilding, and re-running the test — 0 occurrences of typeof(global::UserRequest) in the received snapshot vs. the 6 occurrences in the verified snapshot.

Runtime endpoint behavior is identical fixed-vs-unfixed because the framework falls back to reflection-based validation when the static resolver returns false, so the snapshot is the only deterministic signal. The runtime VerifyEndpoint assertions in the new test are kept as end-to-end regression coverage for the validation pipeline; the bug witness is the snapshot.

Locally dotnet test against Microsoft.Extensions.Validation.GeneratorTests is 30/30 passed with the fix and 1/30 failed (just this test) against main.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[ANcpLua]

@Youssef1313 rebased onto latest main in 8508a901cb. Upstream commit c472800278 (#66646 — localization support) landed yesterday and rewrote the same TypesParser.cs call sites this PR modifies plus changed the emitter format, so the conflict needed manual resolution:

• ITypeParameterSymbol branch and the new displayAttributeSymbol/displayNameAttributeSymbol lookups auto-merged (separated by the DeclaredAccessibility guard).
• At both record and regular property paths I placed the ContainsTypeParameter early-continue guard before the new GetDisplayInfo calls — a property whose type is an unresolved type parameter is now skipped before computing display info that would only be discarded.
• The two snapshots owned by this PR (CanValidateOpenTypeParameterReachableThroughConstraint, CanValidateTypesWithGenericBaseClass) were regenerated against the new emitter rather than hand-merged. The bug witness is intact: the resolver for CanValidateOpenTypeParameterReachableThroughConstraint still emits typeof(global::UserRequest) and its Name/Age member entries, which is the silent-skip half of ValidationsGenerator crashes on generic type parameters (ITypeParameterSymbol) #65418 — without the ITypeParameterSymbol branch the resolver body for that type is empty.

Local verification on the merged tree: dotnet test src/Validation/test/Microsoft.Extensions.Validation.GeneratorTests reports 45 / 45 passed (Debug, net11.0) — the 28 pre-existing generator tests + the 15 new DisplayName* tests from #66646 + the 2 type-parameter tests added by this PR. Final PR scope vs current origin/main is 4 files, +1046 / -0.

[Youssef1313]

Is this code covered by tests?

[Youssef1313]

Generally looks reasonable, but I'm not sure of a good use case for this. Why would you make it generic and constrained instead of having the parameter as the type you need right away?

[Youssef1313]

The scenarios tested here also look different from what the issue original reports.