Cargo fix single-file mode

oftentimes i find myself wanting to run cargo fix on an individual file, especially when i'm contributing to a large project, and thus my changes must be limited in scope.

it would be handy to have a way to tell cargo fix to only modify a specific file.

additionally there could be an --ast-only mode that would only perform fixes for EarlyLintPasses, which can be performed on just the AST, which can be parsed in isolation. this would require a rustc flag for exiting after parsing and running early lints. this would be occasionally handy for developers of large projects to be able to automatically fix warnings in milliseconds rather than minutes.

3 Likes

Early lints run after macro expansion, which needs all files in the crate to be parsed.

An alternative might be to have many smaller crates. As a bonus, this should also improve compile times if you manage to make the dependency graph wide rather than deep. And it is probably a better way to architect the software.

one problem with splitting projects into many crates is there's no way to nest crates, so you end up using c-style pseudonamespaces. you can see this with rustc_*. this is manageable when splitting up a mono-crate project into a workspace-based project, but if your project is already split up into a workspace, and you want to split on of its libraries into several libraries, the repetition starts to get pretty noticeable (eg. rustc_mir_*).

also, this is basically a non-option when it comes to contributing to large projects. i'm not going to convince anyone that clippy should be split into more crates just so i can fix a wildcard import faster.

This is often extremely helpful when contributing to projects which potentially don't have automatic formatting/fixing, and a task I find myself doing regularly (but not often). Even more helpful than formatting/fixing an individual file is the ability to focus changes only overlapping the current diff, I wouldn't like to intermix for instance one new function with 1000 other lines of changes.

Formatting/fixing individual files is reasonably doable by git adding your existing changes, formatting/fixing everything, adding again the one file you want edited, and then resetting the outstanding changes. But it is not a first class workflow.