Honor exact C# names over back-compat naming - #11663
Honor exact C# names over back-compat naming#11663Jorge Rangel (jorgerangel-msft) with Copilot wants to merge 4 commits into
Conversation
|
Azure Pipelines: Successfully started running 1 pipeline(s). 1 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
Co-authored-by: jorgerangel-msft <102122018+jorgerangel-msft@users.noreply.github.com>
microsoft-github-policy-service
Bot
added
the
emitter:client:csharp
| @@ -186,6 +186,11 @@ public static void RestorePreviousParameterNames( | |||
| for (int i = 0; i < currentParameters.Count; i++) | |||
There was a problem hiding this comment.
Copilot did we validate all the back compat integrations that handle renames are covered? In example, in TypeProvider we have several back compat functionality
There was a problem hiding this comment.
Yes. I audited the rename paths: base TypeProvider and ModelFactoryProvider both use the guarded RestorePreviousParameterNames, while RestClient uses its separately guarded UpdateParameterNameWithBackCompat. Other back-compat helpers reorder existing parameters or intentionally preserve names on prior-signature overloads. Commit 9cb77d7 adds generated-output coverage for the base TypeProvider path.
There was a problem hiding this comment.
Copilot what about naming in the back compat handling for enums (FixedEnumProvider, ExtensibleEnumProvider) ?
There was a problem hiding this comment.
Good catch — enums had the same gap. GetGeneratedValueName skipped normalization for exact names, but GetBackCompatibleName could still swap in the last-contract spelling (underscore/casing differences), reverting the override. GetBackCompatibleName now takes isExactName and returns the generated name verbatim; both FixedEnumProvider (member names and the custom-member last-contract lookup) and ExtensibleEnumProvider pass the value's IsExactName. Enum type names were already handled in EnumProvider.BuildName. Added BuildEnumType_ExactValueNameTakesPrecedenceOverLastContract (fixed + extensible, TestData-based) which fails without the fix. Also closed the equivalent gap in ModelProvider.RestorePreviousConstructorParameterNames with a matching regression test.
commit: |
Co-authored-by: jorgerangel-msft <102122018+jorgerangel-msft@users.noreply.github.com>
| /// </summary> | ||
| public InputParameter? InputParameter { get; private set; } | ||
|
|
||
| internal bool IsExactName => |
There was a problem hiding this comment.
Copilot I think this should only be set in the 2 ctors for parameterprovider based on the value from the inputparam OR the property
There was a problem hiding this comment.
Done — IsExactName is now a stored private init property set in both constructors: from inputParameter.IsExactName in the InputParameter ctor, and from inputParameter?.IsExactName == true || property?.InputProperty?.IsExactName == true in the general ctor (propagated in BuildInputVariant/WithRef).
| @@ -186,6 +186,11 @@ public static void RestorePreviousParameterNames( | |||
| for (int i = 0; i < currentParameters.Count; i++) | |||
There was a problem hiding this comment.
Copilot what about naming in the back compat handling for enums (FixedEnumProvider, ExtensibleEnumProvider) ?
There was a problem hiding this comment.
Pull request overview
Ensures exact C# parameter names take precedence over names restored from previous contracts.
Changes:
- Skips back-compat renaming for exact service and property-derived parameters.
- Prevents duplicate model factory compatibility overloads.
- Adds regression tests for RestClient and model factory paths.
Reviewed changes
Copilot reviewed 13 out of 13 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
.../test/Providers/TypeProviderTests.cs |
Tests exact-name precedence. |
.../BuildMethodsForBackCompatibilityExactNameTakesPrecedence(Last)/TestClient.cs |
Defines the prior contract fixture. |
.../BuildMethodsForBackCompatibilityExactNameTakesPrecedence.cs |
Captures expected exact-name output. |
.../BackCompatibility_ExactPropertyNameTakesPrecedence(Last)/SampleNamespaceModelFactory.cs |
Defines the prior model factory contract. |
.../BackCompatibility_ExactPropertyNameTakesPrecedence.cs |
Captures expected model factory output. |
.../ModelFactoryProviderTests.cs |
Tests mixed exact and restored property names. |
.../Utilities/BackCompatHelper.cs |
Excludes exact parameters from name restoration. |
.../Providers/ParameterProvider.cs |
Exposes exact-name metadata for parameters. |
.../Providers/ModelFactoryProvider.cs |
Treats exact-name differences as compatible. |
.../ExactParameterNameTakesPrecedenceOverLastContractView(Last)/TestClient.cs |
Defines the prior RestClient contract. |
.../ExactParameterNameTakesPrecedenceOverLastContractView.cs |
Captures expected RestClient output. |
.../RestClientProviderTests.cs |
Adds RestClient naming regression coverage. |
.../RestClientProvider.cs |
Prevents last-contract names overriding exact names. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| internal bool IsExactName => | ||
| InputParameter?.IsExactName == true || | ||
| Property?.InputProperty?.IsExactName == true; |
There was a problem hiding this comment.
Addressed in 6ba30b81: constructor back-compat now skips restoration for exact parameters, with TestData-backed generated-output coverage in BackCompat_ConstructorParameterExactNameNotRenamed. The focused regression and Cop checks pass.
Co-authored-by: jorgerangel-msft <102122018+jorgerangel-msft@users.noreply.github.com>
Names explicitly configured with
exactcould be replaced by names restored from the previous contract. This made advanced client naming overrides ineffective when back compatibility was enabled.Naming precedence
Model factories
Coverage
The generated C# parameter remains
api_key, even when the previous contract used another name.