Fix C# back-compat service method overloads for reserved param names; skip overload when previous method ends in CancellationToken

[Copilot]

Back-compat overloads generated for service methods (added in 72a95c2) produced uncompilable C# when previous parameters had raw input names that are not valid C# identifiers (e.g. OData query parameters such as $select, $top, $skip, $count). They also could not be emitted correctly when the previous method ended in a CancellationToken parameter — making CT optional introduces a CS0121 ambiguity at basic call sites with the new method, and making CT required violates the SDK guideline that CancellationToken parameters must be optional.

Changes

• ClientProvider.BuildBackCompatOverloadForNewOptionalParameters — emit named-argument labels using the C# variable name (select:, top:) rather than the raw input name ($select:, $top:). Match previous→current parameters by ToVariableName() so renames that differ only by reserved characters still align.
• ClientProvider.ProcessBackCompatForNewOptionalParameters — skip generating the back-compat overload entirely when the previous method's trailing parameter is a CancellationToken. In that case the library author must address the gap via custom code or by updating the spec.
• Tests — updated the four existing back-compat baselines to reflect the skip behavior (their previous methods all ended in CancellationToken). The previously added BackCompatibility_NewOptionalParameterWithReservedName test was removed because its scenario also ends in CancellationToken and is now skipped.

Example (reserved-name fix, applies when an overload IS emitted)

Before:

[EditorBrowsable(EditorBrowsableState.Never)]
public virtual AsyncPageable<SearchIndexResponse> GetIndexesWithSelectedPropertiesAsync(
    IEnumerable<string> @select, CancellationToken cancellationToken)
{
    return this.GetIndexesWithSelectedPropertiesAsync(
        $select: default, $top: default, $skip: default, $count: default,
        cancellationToken: cancellationToken);
}

After:

[EditorBrowsable(EditorBrowsableState.Never)]
public virtual AsyncPageable<SearchIndexResponse> GetIndexesWithSelectedPropertiesAsync(
    IEnumerable<string> @select, CancellationToken cancellationToken)
{
    return this.GetIndexesWithSelectedPropertiesAsync(
        select: default, top: default, skip: default, count: default,
        cancellationToken: cancellationToken);
}

Note

For the original OData scenario (previous method ends in CancellationToken), no back-compat overload is now emitted at all, so the buggy generated C# can no longer occur. The reserved-name fix in BuildBackCompatOverloadForNewOptionalParameters is retained as defensive correctness for any future scenario where a back-compat overload is still emitted.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@typespec/http-client-csharp@10642

commit: 712dd5a

[jorgerangel-msft]

Can we also please get a regen preview? It might also be worth running the debug profile script against Azure/azure-sdk-for-net#59156 to verify the changes

[jorgerangel-msft]

nit: do we need such a long explanation? The log message seems self explanatory 😃

[jorgerangel-msft]

should we ignore nullability as well?

[jorgerangel-msft]

Copilot had added tests for this, then undid them. It would be great if we can add those back in or add new unit tests exercising this scenario