[Feature] Introduce Auto-Fixing Capabilities (--fix flag)

[karanlvm]

Hello everyone,

For our next major release, I'm proposing that we introduce a --fix command-line flag to automatically correct certain warnings reported by PyWard. This will significantly improve the user experience by allowing for instant, safe fixes without manual intervention.

This issue will serve as an umbrella issue to track the overall progress of adding auto-fix capabilities to our checks. The goal is to incrementally add support for auto-fixing to various rules.

Implementation Roadmap

This checklist will track the rules that are candidates for auto-fixing. Each item will be converted into its own dedicated issue.

• Core --fix flag infrastructure (Updating cli.py, setting up the fixing mechanism) (See issue [Feature] Redesign and reimplement --fix architecture #39)
• Unused Imports: Remove unused import or from … import statements. (See issue [Auto-Fix] Implement "Remove Unused Imports" #34)

Contribution

If you'd like to contribute by adding an auto-fix for an existing rule, please open a new issue detailing the implementation plan and link it back to this umbrella issue.

[cafewang]

It seems that currently some optimization rules is fixable: (There are definitely more than what I've found)

• Unreachable code
• Unused variables

Auto-fixing is a thrilling feature, for real, also a complicated one. There are some important design issues:

• Since not all rules are fixable, we need to label each rule as fixable or not fixable, and we need to tell users explicitly about this
• Which parts are fixed(removed or replaced) should also be listed to make it clear for users, also for trouble shooting
• Fixing itself can change files, may influce check result of other rules, so check one rule and modify then next rule could be a relatively simple approach, maybe not the most efficient one.

[karanlvm]

Hi @cafewang,

These are excellent points and I completely agree with you.

My thoughts on your suggestions:

1. Labeling Rules: We'll need a way to mark rules as fixable in their definition, perhaps with a fixable: true property. Maybe we could display it when the user runs pyward without the --fix flag. Something like this maybe:

[Optimization][fixable] Line 12: Unused import ‘foo’
[Optimization][non-fixable] Line 37: Unreachable code

2. Reporting Changes: A full diff in the CLI could get noisy. A separate report.html is an interesting idea. Another option could be to only show diffs under a --verbose flag, but I think that a report file might be better for larger changes.
3. Fixing Strategy: The risk of cascading changes is real. For an initial implementation, a sequential, single-pass approach seems like the safest and most predictable path, even if it's not the most performant. So let's stick with that for now.

But yes, I think we should solidify the fixing architecture before implementing the fixable rules. You could start a separate issue or a discussion and we can start working on the --fix architecture.

Thank you!

[cafewang]

Great suggestions, totally agreed! I can start this issue as soon as this weekend.

[karanlvm]

Great suggestions, totally agreed! I can start this issue as soon as this weekend.

Awesome! I have created #39. We can use that issue to redesign and reimplement auto-fix architecture.