Skip to content

Fix MA0193 code fix producing invalid calls with named arguments - #1486

Merged
meziantou merged 1 commit into
mainfrom
feature/ma0193-named-args-reorder-5112a5
Sep 12, 2026
Merged

meziantou merged 1 commit into
mainfrom
feature/ma0193-named-args-reorder-5112a5

Conversation

@meziantou

Copy link
Copy Markdown
Owner

Problem

The MA0193 code fix inserted the MidpointRounding argument 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:

Math.Round(digits: 2, value: 1.25)
// fixed to:
Math.Round(digits: 2, value: 1.25, MidpointRounding.ToEven) // CS1739

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 parameter a, while Math.Round(double value, MidpointRounding mode) names it value, so Math.Round(a: 2.5) was already broken by the previous code too.

Changes

TryGetMidpointRoundingParameterInfo became TryGetFixInfo, which computes the shape of the whole new argument list before any code action is registered, as required by the code fixer guidance in AGENTS.md:

  • All arguments positional — unchanged behavior: insert positionally at the parameter index, or append a named argument when optional parameters were omitted.
  • Any argument named — append the new argument named with the overload's parameter name, and rebind the existing named arguments to the overload's parameter names (a: → value:). Each argument's bound parameter is mapped to the overload parameter at the corresponding ordinal and the types are checked; since OverloadFinder matches 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:

Math.Round(digits: 2, value: 1.25) -> Math.Round(digits: 2, value: 1.25, mode: MidpointRounding.ToEven)
Math.Round(a: 2.5)                 -> Math.Round(value: 2.5, mode: MidpointRounding.ToEven)

Tests

Four tests added to UseAnOverloadThatHasMidpointRoundingAnalyzerTests, all failing before the change:

  • reordered named arguments (the reported repro)
  • a named argument renamed in the overload (a: → value:)
  • a trailing named argument
  • a generic IFloatingPoint<T> call with reordered named arguments

Validation

  • Full test suite passes on Roslyn 5.9 (4384 tests) and Roslyn 4.8 (4267 tests).
  • The MA0193 and sibling overload tests (93) pass on all five Roslyn versions (4.8, 4.14, 5.0, 5.6, 5.9).
  • dotnet run --project src/DocumentationGenerator exits 0 with no markdown changes.

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.
@meziantou
meziantou enabled auto-merge (squash) September 12, 2026 03:37
@meziantou
meziantou merged commit 943bbce into main Sep 12, 2026
13 checks passed
@meziantou
meziantou deleted the feature/ma0193-named-args-reorder-5112a5 branch September 12, 2026 03:37
This was referenced Sep 12, 2026
This was referenced Sep 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant