I have installed Rust using Rustup and didn't do any configuration aside from creating a binary Rust repository and switching the toolchain to nightly for Clippy using rustup override set.
rustup show:
Default host: x86_64-apple-darwin
installed toolchains
--------------------
stable-x86_64-apple-darwin
nightly-x86_64-apple-darwin
active toolchain
----------------
nightly-x86_64-apple-darwin (directory override for '/Users/Tom/Desktop/rust')
rustc 1.24.0-nightly (7eb64b86c 2017-12-20)
When doing cargo install rustfmt-nightly I get error: binary cargo-fmt already exists in destination. Okay, I figured Rustup installed Rustfmt as a part of the toolchain. Also, I had a previously pre-Rustup Rust installation which Rustup prompted me to uninstall before I do use Rustup and that's what I did, using the command suggested I use for this by Rustup. Maybe rustfmt existed previously and wasn't removed by the uninstaller?
But when doing cargo fmt I get rror: toolchain 'nightly-x86_64-apple-darwin' does not have the binary cargo-fmt. I tried cargo rustfmt, cargo rustfmt-nightly, rustfmt and rustfmt-nightly as well and neither succeeded.
I proceeded to force install Rustfmt again: cargo install rustfmt-nightly --force but that failed on me. Here's a selection of the errors:
GenericParam in ast in items.rs:1875:19params on type &syntax::ast::Generics in items.rs:1872:10syntax::ast::WhereBoundPredicate does not have a field named bound_generic_params in types.rs:416:17As shown previously, I am running on the nightly toolchain so I am not sure why the installation would fail.
I also cargo install rustfmt and that worked and replaced the borked installation of rustfmt-nightly, but obviously this version is deprecated and I always have to pass --force to it so I'd rather use rustfmt-nightly. But it works so that's a good start.
I tried to re-force-install rustfmt-nightly once more just in case after successful installation of rustfmt the original failure cause went away but it didn't.
Could someone please guide me in how to debug this issue? I am pretty sure I am compiling rustfmt-nightly with a nightly build, so that should not be a problem and I am surprised to see it failing on build and not installation.
Distribution via rustup is in the early stage, and likely to cause some annoyance.
When using cargo install, you need to have the latest nightly toolchain. Would you run rustup update nightly and try again?
@topecongiro Yep, that solved it, thank you! Although it now broke my VS Code Rust (RLS) extension (can't install new component rls-preview). I suppose that's expected though as nightly definitely can't be expected to be stable enough so that the extension never breaks.
I had this issue again today, solved it by adding '--force' to the install command.
Here's the answer mbrubeck gave me on IRC:
rustup component add rustfmt-preview
This means the component is managed by rustup as intended.
My issue on Linux with rustup and xargo installed but not working was that ~/.cargo/bin wasn't in the PATH, seems to be working now.
Here's the answer mbrubeck gave me on IRC:
rustup component add rustfmt-previewThis means the component is managed by rustup as intended.
I didn't know rustup had features like that.
TIL
Here's the answer mbrubeck gave me on IRC:
rustup component add rustfmt-previewThis means the component is managed by rustup as intended.
Nope... Like @topecongiro said:
Distribution via rustup is in the early stage, and likely to cause some annoyance.
Right now even after Rust 2018 edition was released, there is no rustfmt or rustfmt-preview component with nightly when installing via rustup. Installing the nightly binary of rustfmt though , works. Just switch to the nightly toolchain and run cargo install rustfmt-nightly (optionally add --force if you have another binary from previous rustup installations). Then make sure you have ~/cargo/bin in PATH. Then run it like rustfmt --edition 2018 src/main.rs or make an IDE/editor do that. cargo fmt should now work as well (reformat entire project).
Most helpful comment
Here's the answer mbrubeck gave me on IRC:
This means the component is managed by rustup as intended.