Skip to content

Fix path resolution of rustfmt in cargo-fmt #141100

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

onur-ozkan
Copy link
Member

Instead of resolving rustfmt path from RUSTFMT or PATH envs, use the one located in the same directory as cargo-fmt. So that cargo-fmt uses the expected version of rustfmt to avoid accidental use of unrelated versions.

Fixes #137666

Instead of resolving `rustfmt` path from RUSTFMT or PATH envs, use the one
located in the same directory as `cargo-fmt`. So that `cargo-fmt` uses the
expected version of `rustfmt` to avoid accidental use of unrelated versions.

Signed-off-by: onur-ozkan <[email protected]>
@rustbot
Copy link
Collaborator

rustbot commented May 16, 2025

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot
Copy link
Collaborator

rustbot commented May 16, 2025

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 16, 2025
@Kobzol
Copy link
Contributor

Kobzol commented May 16, 2025

Now that I think about it, I did some local testing again, and I think that the current behavior sort of... makes sense? cargo-fmt is from the nightly toolchain, but it seems like its intended behavior indeed should be to resolve rustfmt from either RUSTFMT or PATH, even though that rustfmt might actually be from a different toolchain.

And when it is invoked through cargo +nightly fmt, everything works as expected (it invokes the nightly rustfmt). So I think that my original issue was actually a red herring and it's fine. But I'll let Mark take a look.

@onur-ozkan
Copy link
Member Author

FWIW clippy also follows this approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

cargo-fmt reports weird version on nightly
4 participants