fix(http-client-csharp): use generator return type in partial method customization#11059
Closed
JoshLove-msft wants to merge 4 commits into
Closed
Conversation
CreatePartialMethodFromCustomSignature passed the custom signature's parameters as the generator parameters, so the generated partial implementation's signature referenced different parameter declarations than its body and XML docs. The writer's name de-duplication then appended a numeric suffix (e.g. input0) to the signature parameters, producing code that does not compile. Pass the generated method's parameters as the generator parameters so the signature, body, and XML docs share the same parameter declarations. Also document that types generated into the same assembly must be fully qualified with global:: in a partial method declaration. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… customization When a partial method declaration customizes a generated method and its return type references a type generated into the same assembly, the type is unresolved when the declaration is read (Roslyn error type with no namespace), producing malformed 'global::.TypeName' output. BuildPartialSignature now accepts the generator's resolved return type, and TypeProvider.CreatePartialMethodFromCustomSignature passes it. C# requires a partial method's declaration and implementation to share the same return type, so the generator's resolved type is necessarily correct. Removes the docs note that previously required users to qualify return types with global::. Builds on microsoft#11058 (parameter rename fix). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
JoshLove-msft
requested review from
ShivangiReja,
jorgerangel-msft,
joseharriaga,
jsquire and
m-nash
as code owners
microsoft-github-policy-service
Bot
added
the
emitter:client:csharp
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
|
No changes needing a change description found. |
Contributor
Author
|
Folded this change directly into #11058 instead of stacking, per review feedback. Closing in favor of that PR. --generated by Copilot |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Builds on #11058. Merge #11058 first — this branch is stacked on it, so until that merges the diff here will also show its commit.
Problem
After #11058 fixes parameter names in partial method customization, the return type is still taken from the customer's parsed partial declaration. When that return type refers to a type generated into the same assembly (e.g. a
*.Modelstype), it is unresolved when the declaration is read — Roslyn surfaces it as an error type with no namespace — so the generated implementation emits a malformedglobal::.TypeName:\\csharp
// Observed in Azure/azure-sdk-for-net#59749
private static partial Task<Responseglobal::.DeallocateResourceOperationResult> BulkDeallocateOperationAsync(...)
\\
Fix
BuildPartialSignaturenow accepts an optionalreturnType, andTypeProvider.CreatePartialMethodFromCustomSignaturepassesgeneratedMethod.Signature.ReturnType.This is safe and correct: the return type is not part of how a partial declaration is matched to a generated method (
SignatureComparercompares name + parameter count + parameter types only), and C# requires a partial method's declaration and implementation to share the same return type. So the generator's resolved return type is necessarily the same type the customer declared — just fully resolved, with its namespace and resolved generic arguments.Docs
Removes the note added in #11058 that asked users to
global::-qualify return types — with this fix, parameter and return types are both auto-resolved from the generator, so no qualification is needed for the documented signature-customization scenario.Tests
CustomPartialMethodImplementationUsesGeneratorReturnType(verified: fails before the fix with an empty-namespace return type, passes after).TypeProviderTestssuite green (34 tests).