Use rustfmt given by RUSTFMT env var

[dtolnay]

This matches how Cargo uses the rustc and rustdoc specified by RUSTC and RUSTDOC environment variables (see https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-reads).

Trying to do this via PATH instead does not work because Cargo always prepends its own bin directory to PATH before calling any subcommand, and Rustup places its own rustfmt executable there.

$ PATH=/path/to/custom:$PATH cargo fmt  # does not call /path/to/custom/rustfmt

[calebcartwright]

I'm not opposed to this, but is there any additional context you could share around the use case? Curious if it's a case of wanting to run rustfmt via a different version of cargo fmt or something else.

There would also be some serious compatibility issues in the event someone tried to use v1 of one and v2 of the other

[dtolnay]

Sure thing -- my work codebase is a big monorepo (>2 million lines of first-party Rust code) in which:

• All projects are required to follow a consistent formatting (no custom rustfmt.toml allowed per project).
• Practically all projects build with Buck. Buck invokes rustc directly. We build rustc from source. There is no rustup or cargo involved.
• A small number of projects need to do some things using Cargo. For that, the developers have ordinary local rustup setups that are disconnected from the monorepo.
• The Cargo-using projects want to run cargo fmt -- --check in CI. That is only sensible if their rustup-managed Cargo is able to run the version of rustfmt provided and enforced by the monorepo builds.

In terms of incompatibility between 1.x and 2.x, we are happy to attach an explicit -- --recursive when cargo-fmt is 1.x and rustfmt is 2.x.

[calebcartwright]

That's really helpful info, thanks!

[calebcartwright]

LGTM

@topecongiro - will hold off on merging for a bit in case you have any objections, but seems a reasonable use case to me that we should support. If enough users end up leveraging and getting confused/hitting issues (for example the 1.x vs. 2.x) then we could address with a note to the docs and/or issue template

[topecongiro]

LGTM. Thank you!

We should add documentation about the RUSTFMT environment variable to our README.md and the cargo's documentation. I will create an issue to track these, and merge this PR first.

[calebcartwright]

I'm going to create a new branch to include the next rustc-ap bump in v1.4.22, and will pull these changes in so that it gets included with the next rustfmt update that hits nightly.

[karyon]

backported in #4453