--ask/--interactive option for rustfmt and cargo fix

[AGausmann]

While I love what cargo fix and cargo fmt are providing with linting, we can all agree that sometimes linters are wrong. Currently, both utilities only have two modes of operation, the default “fix-all” and the more passive “check”. This doesn’t provide a lot of flexibility for the end-user, and this means that the implementers of cargo fix have been a lot more careful with the compiler warnings/suggestions that they choose to distinguish as applicable.

I think an “interactive” option would be a great middleground between the two because it can accept human input for each decision. The human could pick from a set of options that could be even more flexible than a simple yes/no question; for example, I would love to see an “ignore”/“allow” option that automatically adds the proper #[allow()] attribute to suppress the warning in future runs.

[matklad]

The ideal UI for this would be an IDE’s red bulb. It probably makes sense to add a CLI solution as well, but it would be so much better if we could just easily surface such features for IDEs…

[zackmdavis]

I agree that an interactive CLI mode for cargo fix would be great (and is in my private TODO list of things to work on when I have time). (This isn’t exclusive with integrated IDE lightbulb UI prompts, of course, but I am amongst those who have a fairly bare-bones text-editor setup and would be more excited about a terminal tool.) My understanding was that this used to exist in @killercup’s original rustfix, but was removed during the project’s overhaul to be integrated with cargo and become the official edition-migration tool.

[zackmdavis]

I would love to see an “ignore”/“allow” option that automatically adds the proper #[allow()] attribute to suppress the warning in future runs.

I also like this idea, but it seems nontrivial to implement given the way rustfix works: rather than reimplementing parser functionality, it takes JSON suggestions from the compiler that say which byte ranges in the file should be replaced by what text. So, I think the most likely implementation path would be to add another field to the compiler’s JSON output indicating where an #[allow] attribute would go?

[AGausmann]

Thanks for the responses!

The ideal UI for this would be an IDE’s red bulb. It probably makes sense to add a CLI solution as well, but it would be so much better if we could just easily surface such features for IDEs…

I prefer doing work with Vim and the terminal and I love using CLI over GUI. I do think there is a significant demand for command-line utilities, especially since Rust IDEs are not yet common, though I do see where you’re coming from.

I also like this idea, but it seems nontrivial to implement given the way rustfix works: rather than reimplementing parser functionality, it takes JSON suggestions from the compiler that say which byte ranges in the file should be replaced by what text. So, I think the most likely implementation path would be to add another field to the compiler’s JSON output indicating where an #[allow] attribute would go?

Yeah, I understand that this is a more difficult feature to implement that will require support from multiple components. I was thinking that the suggestions output format could be reworked to provide multiple suggestions of different types like fix/ignore, though there may not be a way to implement this that is both backwards-compatible and clean/non-ugly (I don’t know much about the JSON output format).

[killercup]

The ideal UI for this would be an IDE’s red bulb.

It’s my understanding that this already happens in VSCode with RLS but haven’t tried it recently

My understanding was that this used to exist in @killercup’s original rustfix, but was removed during the project’s overhaul to be integrated with cargo and become the official edition-migration tool.

Excatly. It migth be a good idea to bring this functionality back at some point, but I’m not sure if adding it to cargo (where the fix command lives) would be the best approach. For a prototype, writing a tool that works as a cargo subcommand (let’s say, cargo improve) might be easier.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.