[carljm]

In #28092 I fixed a bug where ty's redundant-cast removal fix could create broken code if the original cast() call was multi-line. Doug commented that this could perhaps be a general-purpose utility -- and it turned out there were two existing similar Ruff rules with pre-existing multi-line support that could benefit from such a shared utility.

This PR introduces a shared utility in ruff_python_edits for removing a function call in favor of one of its arguments. This is the common shape between redundant-cast removal, redundant int() removal, and redundant round() removal.

The new utility is more robust than the previous code for any of the three cases. Previously removing redundant int, round, and typing.cast calls could discard parentheses needed for line continuation or for token separation. For example, int(1).to_bytes() could become 1.to_bytes(), which is invalid.

The shared helper preserves optional argument parentheses and the comments inside them, adds grouping where required, and avoids redundant parentheses when the surrounding syntax already allows the expression. Ruff and ty retain their own diagnostic eligibility and fix-safety decisions.

Test plan

• Extend RUF046 and RUF057 fixtures for split callees, assignment expressions, integer attributes, adjacent keywords, and comments inside optional parentheses. Existing snapshot cases retain their fix text and safety classifications.
• Add compact helper tests in ruff_python_edits for conditional callees, comprehension iterables, and dictionary expressions inside f-strings.
• Existing ty cast mdtests cover positional and keyword arguments, operator precedence, multiline values, and comment preservation.

[astral-sh-bot]

Typing conformance results

No changes detected ✅

Current numbers

The percentage of diagnostics emitted that were expected errors held steady at 97.82%. The percentage of expected errors that received a diagnostic held steady at 95.48%. The number of fully passing files held steady at 126/145.

[astral-sh-bot]

Memory usage report

Memory usage unchanged ✅

[astral-sh-bot]

ecosystem-analyzer results

No diagnostic changes detected ✅

Full report with detailed diff (timing results)

[astral-sh-bot]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[AlexWaygood]

I'm not sure the ruff_python_ast crate is a good home for this helper. This feels like a more high-level, specific API than most of the other things in this module; the crate is mostly meant to be for very low-level, foundational stuff. If this helper were only going to be used by ruff then it would definitely go in https://github.com/astral-sh/ruff/blob/main/crates/ruff_linter/src/fix/edits.rs.

I wonder if we should create a new crate for these kinds of helpers that ruff and ty can both depend on, continuing the precedent that @BurntSushi started when he added the ruff_python_importer crate? Over time we can maybe move more of the helpers in https://github.com/astral-sh/ruff/blob/main/crates/ruff_linter/src/fix/edits.rs to this shared crate; I think a lot of them would be helpful to ty as well as ruff.

[carljm]

Good call. What about ruff_python_edits? Fits the precedent of ruff_python_importer. The scope of the crate would be "utilities for constructing edits to Python source code" -- anything in that scope that can be shared between ty and ruff (whether ty uses it for auto-fixes or for LSP refactors) could go there.

[AlexWaygood]

I haven't reviewed the code in depth for correctness, but the idea seems fine, though I still feel like in general this is a surprisingly complex method and it's okay to simply bail and not provide a fix in certain weird edge cases. (Do we really need to provide fixes in f-strings?)

It looks like this new method could probably be used to fix #28102 as well.

I'd appreciate sign-off from @ntBre as well!

[ntBre]

Looks good to me!

[carljm]

I haven't reviewed the code in depth for correctness, but the idea seems fine, though I still feel like in general this is a surprisingly complex method and it's okay to simply bail and not provide a fix in certain weird edge cases. (Do we really need to provide fixes in f-strings?)

Thanks for the review! My personal feeling is that this kind of consistency even in edge cases that seem "hard" is delightful as a user when you run into it, and this PR is well within the budget of how much complexity it's worth paying for that. Removing f-string support from this PR would add just as much or more code checking for that case and avoiding suggesting a fix as is required to support it (one if guard).