[http-client-csharp] Operator dedup treats T and T? return types as identical, dropping nullable conversion operators

[JoshLove-msft]

Summary

#10639 added operator deduplication between generated and customization partials in MethodSignatureBase.SignatureComparer. For conversion operators it skips the Name comparison and relies on modifiers + return type + parameter types to identify duplicates. The return-type check uses CSharpType.AreNamesEqual, which does not consider nullability. As a result, a generated implicit operator T?(string) is incorrectly treated as a duplicate of a customization-defined implicit operator T(string) (or vice versa) and gets stripped.

Repro

In Azure.AI.Language.QuestionAnswering.Authoring the customization partial src/ImportContentType.cs defines:

csharp public static implicit operator ImportContentType(string value) => new ImportContentType(value);

The generator-side partial emits both:

csharp public static implicit operator ImportContentType(string value) => new ImportContentType(value); public static implicit operator ImportContentType?(string value) => value == null ? null : new ImportContentType(value);

After #10639, both generated operators are deduped (including the nullable variant), the generated partial becomes empty and the file is dropped. See azure-sdk-for-net PR #59283 — the bump to 1.0.0-alpha.20260515.2 deletes sdk/cognitivelanguage/Azure.AI.Language.QuestionAnswering.Authoring/src/Generated/Models/ImportContentType.cs entirely, removing the public implicit operator ImportContentType?(string) from the SDK surface.

Root cause

In packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator/src/Primitives/MethodSignatureBase.cs (operator branch of MethodSignatureBaseEqualityComparer.Equals):

csharp if (x.ReturnType != null && y.ReturnType != null) { if (!x.ReturnType.AreNamesEqual(y.ReturnType)) { return false; } }

CSharpType.AreNamesEqual only compares Name/FullyQualifiedName and the generic Arguments list. The CSharpType constructor explicitly unwraps Nullable<T> for value types and stores nullability on a separate IsNullable flag, so ImportContentType and ImportContentType? both end up with Name == "ImportContentType" and zero Arguments. AreNamesEqual returns true for the pair, and the dedup comparer treats the conversion operators as the same.

Expected behavior

A conversion operator returning T and one returning T? are different operators in C# (different signatures), and the comparer should treat them as such.

Suggested fix

In the operator branch of MethodSignatureBaseEqualityComparer.Equals, also compare ReturnType.IsNullable (or use CSharpType.Equals directly, which already considers nullability), e.g.:

csharp if (x.ReturnType != null && y.ReturnType != null) { if (!x.ReturnType.AreNamesEqual(y.ReturnType) || x.ReturnType.IsNullable != y.ReturnType.IsNullable) { return false; } }

Should also add a regression test to MethodSignatureComparerTests covering implicit operator T(string) vs implicit operator T?(string) (not equal).

[github-actions]

🎯 Issue Triage

The MethodSignatureBaseEqualityComparer introduced in #10639 incorrectly treats implicit operator T(string) and implicit operator T?(string) as duplicates because CSharpType.AreNamesEqual ignores the IsNullable flag, causing the nullable conversion operator to be dropped from generated output.

Category: Bug
Area: emitter:client:csharp

🔍 Analysis

• Root cause: In MethodSignatureBase.cs, the operator branch of MethodSignatureBaseEqualityComparer.Equals uses CSharpType.AreNamesEqual for return-type comparison, which only checks Name/FullyQualifiedName and generic Arguments. Since the CSharpType constructor unwraps Nullable<T> and stores nullability in a separate IsNullable flag, T and T? produce the same Name and both have zero Arguments, so AreNamesEqual returns true for the pair.
• Impact: Any SDK type that has both a non-nullable and nullable implicit conversion operator from the same source type (e.g., ImportContentType in Azure.AI.Language.QuestionAnswering.Authoring) will lose the nullable variant, potentially removing public API surface from the SDK.
• Suggested fix: In the operator branch, additionally compare ReturnType.IsNullable, or switch to CSharpType.Equals which already accounts for nullability.
• Regression test: Add a test in MethodSignatureComparerTests asserting implicit operator T(string) and implicit operator T?(string) are not equal.
• Introduced by: [http-client-csharp] Dedup operators between generated and customization partials #10639

📝 Suggested next steps

• In MethodSignatureBase.cs, update the operator return-type comparison to also check IsNullable (or use CSharpType.Equals).
• Add a regression test in MethodSignatureComparerTests for nullable vs. non-nullable return types.
• Verify fix against Azure.AI.Language.QuestionAnswering.Authoring (azure-sdk-for-net PR #59283).

Generated by Agentic Triage