5 ms·

Should a compiler also suggest applying the fix? I'm working on my own toy language and wondering if simple, obvious errors (like the `map` -> `nap` typo from

Should a compiler also suggest applying the fix? 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.

masklinn 4y ago
Maybe as an opt-in (mode or blanket approval), having to continue on every compiler error which has a fixer would be rather frustrating. 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.
jamesmunns 4y ago
Both Rust (via 'cargo fix') and Clang (via `clang-tidy -fix` have ways of doing this, I don't think I've seen someone offer this automatically/interactively though. 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).
epage 4y ago
On top of what others said, cargo is looking to further improve the fix workflow. 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).

masklinn 4y ago

Maybe as an opt-in (mode or blanket approval), having to continue on every compiler error which has a fixer would be rather frustrating. 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.

jamesmunns 4y ago

Both Rust (via 'cargo fix') and Clang (via `clang-tidy -fix` have ways of doing this, I don't think I've seen someone offer this automatically/interactively though. 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).

epage 4y ago

On top of what others said, cargo is looking to further improve the fix workflow. 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).