I'm working on my own toy language and wondering if simple, obvious errors (like the `map` -> `nap` typo from the article) should come with an "Apply fix? [y/N]" option when run interactively.
I'm working on my own toy language and wondering if simple, obvious errors (like the `map` -> `nap` typo from the article) should come with an "Apply fix? [y/N]" option when run interactively.
Clippy supports fixes, but will only apply them if `--fix` is supplied. It does not ask for individual case, the assumptions likely being that if you're running this opt-in you can probably do so with a clean working copy and revert whichever fixes you didn't want or are incorrect.
An other issue is if you're providing fixers for suggestions, the fixer has to be extremely reliable, not a 90% thing, because replacing broken code by possibly subtler broken code is not great.
Right now, some errors offer fixes and these are marked machine-applicable. cargo-fix will apply these. The workflow was originally written for Edition migrations and has had little attention past that. Changes are applied in bulk and the worktree must be clean. There are known bugs and it isn't trusted to fix errors.
We want to slowly raise the visibility so we can collect feedback and gain more confidence in it. The first thing we did is tell users when there is something for cargo fix to do when getting compiler errors. Currently, this is limited to warnings and the nightly toolchain. I look forward to expanding this to more users (myself included).
I don't think I've ever used them, but I've ABSOLUTELY used suggested fixes from LSP/rust-analyzer tools, which fit much more into my typical workflow. For things like match statements in Rust (which need to be exhaustive), I now have muscle memory to just write an empty match statement, and trigger the first LSP/r-a suggestion, which fills the match block with placeholder items.
I guess I see LSP as my "compiler in interactive mode" interface (even if that isn't EXACTLY true).