You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is probably asking too much but it'd be nice if cargo-fmt could support reading a file from stdin and putting formatted output on stdout like rustfmt does. With this there'd be no real need to specify rustfmt --edition <edition>.
The use case is a linting tool like ale which runs rustfmt as /bin/sh -c rustfmt < ${path_to_file_in_tmpdir} . It then takes this output and copies into the vim buffer. As far as I know ale doesn't support linters that modify files in place.
This currently doesn't work for files that use syntax from editions greater than 2015 (the default for rustfmt). It'd be nice not to have to hardcode a rust edition in my vim configuration and instead be able to point the config to cargo-fmt running in a "stdin mode", i.e:
/bin/sh -c cargo-fmt --stdin < ${path_to_file_in_tmpdir} . That way I can always adhere the project's edition specified in Cargo.toml as well as other configuration options specified in rustfmt.toml (assuming cargo-fmt adheres to the project's rustfmt.toml, I could be wrong about that).
I'd love to try to implement something like this if you all think it'd be valuable, but I understand if not. I can always see what I can do on the ale side of things to get this working.
The text was updated successfully, but these errors were encountered:
Thanks for reaching out, making your case, and offering to assist, but I think it's probably best to close this.
Will elaborate a bit more but in short:
tactically the best bet is to just incorporate/recommend a rustfmt.toml file in the project repo/directory with the edition value set to whatever it needs to be
though it's stalled/a bit blocked at the moment, there's work underway in in Allow cargo-fmt to handle formatting individual files. #5071 to make it more feasible to use cargo fmt against a single target which (IIRC) should cover this too. Would rather track discussion and efforts there instead of bifurcating
Different editors/IDEs have taken different approaches to formatting behavior, both in how they run rustfmt and if/how they attempt to provide edition information. At the end of the day though, rustfmt will always pick up the rustfmt.toml value (provided the file is in a supported location) so while some will argue it's duplicative to have to specify the edition in Cargo manifests and the rustfmt config file, it's the path of least resistance.
assuming cargo-fmt adheres to the project's rustfmt.toml, I could be wrong about that
Yup it will. cargo fmt is actually just a very, very lightweight rustfmt command builder. It simply uses some cargo utilities to discover information about the project/workspace, and then it runs the corresponding rustfmt ... commands with that discovered info being passed along as args to rustfmt
Thanks for the detailed answer and your help! Looks like having rustfmt.toml in the repo and having the CWD be the root of the repo is good enough for now.
This is probably asking too much but it'd be nice if
cargo-fmt
could support reading a file from stdin and putting formatted output on stdout likerustfmt
does. With this there'd be no real need to specifyrustfmt --edition <edition>
.The use case is a linting tool like ale which runs rustfmt as
/bin/sh -c rustfmt < ${path_to_file_in_tmpdir}
. It then takes this output and copies into the vim buffer. As far as I know ale doesn't support linters that modify files in place.This currently doesn't work for files that use syntax from editions greater than
2015
(the default for rustfmt). It'd be nice not to have to hardcode a rust edition in my vim configuration and instead be able to point the config to cargo-fmt running in a "stdin mode", i.e:/bin/sh -c cargo-fmt --stdin < ${path_to_file_in_tmpdir}
. That way I can always adhere the project's edition specified in Cargo.toml as well as other configuration options specified inrustfmt.toml
(assumingcargo-fmt
adheres to the project'srustfmt.toml
, I could be wrong about that).I'd love to try to implement something like this if you all think it'd be valuable, but I understand if not. I can always see what I can do on the
ale
side of things to get this working.The text was updated successfully, but these errors were encountered: