[STJ Source Gen] Propagate type parameter constraints to generic UnsafeAccessor wrapper classes

[steveisok]

Description

Fixes the regression introduced in #124650 where the STJ source generator emits generic wrapper classes for [UnsafeAccessor] methods without propagating the type parameter constraints from the declaring type.

The Problem

When a generic type has constrained type parameters (e.g., PublicKeyCredential<TResponse> where TResponse : notnull, AuthenticatorResponse) and init-only properties, the source generator emits a wrapper class like:

private static class __GenericAccessors_PublicKeyCredential<TResponse>
// Missing: where TResponse : notnull, AuthenticatorResponse
{
    [UnsafeAccessor(UnsafeAccessorKind.Method, Name = "set_Id")]
    private static extern void __set_Id(PublicKeyCredential<TResponse> obj, BufferSource value);
    //                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    //                                  CS0314: TResponse doesn't satisfy constraint
}

This causes CS0314 compilation errors. Reported by @akoeplinger in dotnet/dotnet#5880 (comment) — aspnetcore's IdentityJsonSerializerContext uses PublicKeyCredential<TResponse> where TResponse : notnull, AuthenticatorResponse with init-only properties.

The Fix

Three changes across the source generator:

1. Model (PropertyGenerationSpec): Added DeclaringTypeParameterConstraints property to carry the constraint clauses (e.g., ["where TResponse : notnull, global::Microsoft.AspNetCore.Identity.AuthenticatorResponse"]).

2. Parser: Added GetTypeParameterConstraints() helper that reads ITypeParameterSymbol properties (HasNotNullConstraint, HasValueTypeConstraint, HasReferenceTypeConstraint, HasUnmanagedTypeConstraint, HasConstructorConstraint, ConstraintTypes) and builds the corresponding where clauses.

3. Emitter: Emits the constraint clauses on the generated wrapper class:

private static class __GenericAccessors_PublicKeyCredential<TResponse>
    where TResponse : notnull, global::Microsoft.AspNetCore.Identity.AuthenticatorResponse
{
    // UnsafeAccessor externs now compile correctly
}

cc @eiriktsarpalis @stephentoub

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-text-json
See info in area-owners.md if you want to be subscribed.

[steveisok]

@eiriktsarpalis you beat me to it. Closing in favor of #126507

[Copilot]

Pull request overview

Fixes a regression in the System.Text.Json source generator where generic [UnsafeAccessor] wrapper classes for members on generic declaring types were emitted without propagating the declaring type’s generic type-parameter constraints, leading to compilation errors (e.g., CS0314).

Changes:

• Extend PropertyGenerationSpec to carry declaring type generic constraint clauses.
• Parse ITypeParameterSymbol constraints into where ... clauses during spec creation.
• Emit collected where ... constraints on generated __GenericAccessors_*<...> wrapper classes.

Reviewed changes

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

File	Description
src/libraries/System.Text.Json/gen/Model/PropertyGenerationSpec.cs	Adds a model field to carry declaring-type generic constraint clauses to emission.
src/libraries/System.Text.Json/gen/JsonSourceGenerator.Parser.cs	Builds where clauses from Roslyn type-parameter constraint metadata and stores them on the spec.
src/libraries/System.Text.Json/gen/JsonSourceGenerator.Emitter.cs	Emits the stored generic constraint clauses on the generated generic UnsafeAccessor wrapper class.

[Copilot]

GetTypeParameterConstraints emits "class" whenever HasReferenceTypeConstraint is true, but it doesn’t account for nullable reference type constraints ("class?") via ITypeParameterSymbol.ReferenceTypeConstraintNullableAnnotation. Emitting "class" for an original "class?" constraint is stricter and can cause compilation failures when the declaring type uses nullable reference type constraints. Consider emitting "class?" when the nullable annotation is Annotated (and keeping "class" otherwise).

Suggested change

	(parts ??= new()).Add("class");
	(parts ??= new()).Add(tp.ReferenceTypeConstraintNullableAnnotation == NullableAnnotation.Annotated ? "class?" : "class");

[Copilot]

GetTypeParameterConstraints doesn’t propagate the C# 13 "allows ref struct" constraint (Roslyn ITypeParameterSymbol.AllowsRefLikeType). If a declaring type has this constraint, the generated wrapper class must repeat it; otherwise ref-like type arguments won’t be permitted and the generated code can fail to compile. Consider adding support for this constraint (likely via reflection like other generators in the repo do to keep compatibility across Roslyn versions).

[Copilot]

DeclaringTypeParameterConstraints is built from namedType2.OriginalDefinition.TypeParameters, which only includes type parameters declared on the immediate type (and excludes containing type parameters for nested generic types). For nested generics, this will omit outer constraints and can still produce CS0314/constraint-mismatch errors in the generated _GenericAccessors* wrapper. Consider gathering type parameters (and constraints) from the full containing-type chain (similar to how GetTotalTypeParameterCount handles nested generics).

[Copilot]

This change introduces new emitted syntax (generic wrapper type parameter constraint clauses) but there isn’t a unit/baseline test exercising a constrained generic declaring type (e.g., where T : notnull, SomeBase or class?). Adding a source-gen output test for constrained generic init-only properties would help prevent regressions like #124650 and validate the exact emitted where clauses.