Fix MA0193 code fix producing invalid calls with named arguments - #1486
Merged
Merged
Conversation
The fixer inserted the MidpointRounding argument positionally at the
parameter ordinal of the overload, treating it as an index in the
argument list. When the existing arguments were named and reordered, the
added positional argument followed out-of-order named arguments, which
does not compile:
Math.Round(digits: 2, value: 1.25)
-> Math.Round(digits: 2, value: 1.25, MidpointRounding.ToEven) // CS1739
Appending a named argument is not enough either: the overload can name
its parameters differently, so the existing named arguments may not bind
anymore. `Math.Round(double a)` names its parameter `a`, while
`Math.Round(double value, MidpointRounding mode)` names it `value`.
When some arguments are named, the added argument is now named and
appended, and the existing named arguments are rebound to the parameters
of the overload. As `OverloadFinder` matches overloads whose parameters
are in a different order, the fix is not registered when the arguments
cannot be bound to the parameters of the overload. Calls with only
positional arguments are unchanged.
This was referenced Sep 24, 2026
Open
Open
Open
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
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.
Problem
The MA0193 code fix inserted the
MidpointRoundingargument positionally at the parameter ordinal of the target overload, treating that ordinal as an index in the argument list. When the existing arguments are named and reordered, the added positional argument follows out-of-order named arguments, which does not compile:Simply appending a named argument is not enough either: the overload can name its parameters differently, so the existing named arguments may no longer bind.
Math.Round(double a)names its parametera, whileMath.Round(double value, MidpointRounding mode)names itvalue, soMath.Round(a: 2.5)was already broken by the previous code too.Changes
TryGetMidpointRoundingParameterInfobecameTryGetFixInfo, which computes the shape of the whole new argument list before any code action is registered, as required by the code fixer guidance inAGENTS.md:a:→value:). Each argument's bound parameter is mapped to the overload parameter at the corresponding ordinal and the types are checked; sinceOverloadFindermatches overloads ignoring parameter order, the fix is not registered when the mapping does not line up, or when a positional argument would land on the new parameter.Results:
Tests
Four tests added to
UseAnOverloadThatHasMidpointRoundingAnalyzerTests, all failing before the change:a:→value:)IFloatingPoint<T>call with reordered named argumentsValidation
dotnet run --project src/DocumentationGeneratorexits 0 with no markdown changes.