Share the lookup and overload-resolution stages - #4147
Merged
Merged
Conversation
The three IsUnambiguous* checks each spelled out the same shape: bind the name from the target (or unqualified when there is none), then decide whether what came back is the member the IL referenced. Two helpers now carry the parts that are literally identical, so a change to how a name is bound or how a best candidate is verified cannot reach one check and miss another. The method-group check keeps its own verification: it does not reject BestCandidateErrors or an ambiguous result, and whether it should is untested, so it is left as it was rather than tightened blind. Field access keeps its own probe too - a field is reached by plain name equality and has no virtual dispatch for IsAppropriateCallTarget to tolerate. Assisted-by: Claude:claude-opus-5[1m]:Claude Code
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
1 participant
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.
Follow-up to #4144.
The three
IsUnambiguous*checks inDisambiguatoreach spelled out the sameshape: bind the name from the target (or unqualified when there is none), then
decide whether what came back is the member the IL referenced. Two helpers now
carry the parts that are literally identical:
LookUpNameIsUnambiguousCall,IsUnambiguousAccess(non-indexer),IsUnambiguousMethodReferenceCheckBestCandidateIsUnambiguousCall,IsUnambiguousAccess(indexer)A change to how a name is bound, or how a best candidate is verified, can no
longer reach one check and miss another.
Two checks deliberately keep their own code:
BestCandidateErrorsor an ambiguousresult, and a method group carries no arguments to be ambiguous over. Whether
that should hold for the type arguments too is untested, so it is left as it
was rather than tightened blind.
dispatch for
IsAppropriateCallTargetto tolerate.No intended change to decompiler output.
Verification
ILSpy.XPlat.slnf: 3781 tests, 0 failed (49 Windows-gated skips).This PR description was written by an AI agent (Claude Opus 5) working under
@siegfriedpammer's direction.