cargo fix --interactive

[epage]

The user might not be interested in all fixes. If we allowed prompting the user for what diffs to apply (see also #6040 for generating diffs), they could then select only the ones that they want.

This could include

• Showing suggestions for all fixes, not just the ones with high confidence (cargo fix --interactive #11125, cargo fix: tell user why some fixes aren't applied (such as maybe-incorrect) #8806, cargo fix: Improve handling of MaybeIncorrect suggestions #13028)
• Apply-all, ignore-all for suggestion type or lint name (cargo fix: Allow filtering by lint #13029)
• Support fixing broken code (cargo fix should suggest --broken-code #15063)

See also #6040

[owenthewizard]

No love for this?

[epage]

In reading https://codeandbitters.com/rust-2024-upgrade/, it made me think that a "yes all" and "no all" to specific lint names would be useful (no to all if-let fixes for 2024, yes-all to something else)

[ericseppanen]

How much expertise with cargo internals would be required to work on this? I have some interest in seeing something like this happen.

[epage]

cargo fixs architecture is odd. It registers itself as "rustc", looping over calls to it until we have reached a fixed point. I'm not sure how well this would work for an interactive mode. iirc all output today is done by sending json messages back up the regular cargo run which then get report.

I've proposed a GSoC project to experiment with a different architecture, one that would put the control of applying fixes in the top level cargo invocation, removing potential barriers to an interactive mode.