Is it possible to run cargo clippy with an option so it will fix warnings automatically?
From the help message, it does not look like this option is supported at the moment.
As of June 2021 the autofix capability has been stabilized, you can apply changes using the following command
cargo clippy --fix
cargo fix can already apply some suggestions deriving from rustc's errors and warnings.
In nightly builds you can use cargo clippy --fix to apply some suggestions from Clippy. In some older Rust versions, the syntax is reversed: cargo fix --clippy.
If you are using a stable version of the Rust toolchain, you can opt-in to use a nightly build for just one command, by using +nightly to override the toolchain:
cargo +nightly clippy --fix -Z unstable-options
Related
Rustdoc offers some pretty useful lints for documentation. I'd like to check these lints as part of continuous integration for all of the crates in my Cargo workspace.
Unfortunately, I've not been able to find a way to run these lints for all of my crates. You can do e.g.
cargo rustdoc -p crate -- -D rustdoc::broken-intra-doc-links
to run on a specific crate, but there's no --workspace flag on cargo rustdoc. Obviously I could do some hacky thing with xargs here, but that's pretty slow & annoying. Is there a supported way to run this check?
You can use RUSTDOCFLAGS and cargo doc:
RUSTDOCFLAGS="-D rustdoc::broken-intra-doc-links" cargo doc
I have installed both nightly and stable rust toolchains and make some -Z ... compile flags for nightly, but the stable rust can't recognize it and stops compiling; is there a way or a cargo directive to conditionally switch between nightly/stable rust compiler.
In .cargo/config.toml file
[build]
rustflags = [
"-C...",
"-Z...",
]
For nightly rust read -Z and -C flags, for stable rust only read -C or ignore -Z completely. So that, we can use cargo +stable/+nightly build without modify config.toml file every time.
Thanks Ruster ~
I don't think it's possible to specify rustc unstable feature inside config.toml but you can specify cargo unstable feature. It could be nice to have.
You could create a "nightly" directory:
cd my_rust_project
mkdir my_nightly_project
cd my_nightly_project
rustup override set nightly
Then using merge feature of config file of cargo you create you can override the global config using a my_nightly_project/.cargo/config.toml file.
Consider using alias instead.
The output of rustup target list --toolchain nightly does not contain x86_64-apple-ios-macabi, even though it is in src/librustc_target on the Rust master branch.
How do I build for Mac Catalyst / x86_64-apple-ios-macabi?
The x86_64-apple-ios-macabi target is available on the nightly (5c5b8afd8 2019-11-16) compiler. Just because a target is available does not mean that the standard library and friends are compiled or available to rustup:
% rustc +nightly --print target-list | grep macabi
x86_64-apple-ios-macabi
Rust has a tier system (which is the subject of a proposed RFC). This target is so new it's not even listed on the tier list, but it's undoubtedly going to be tier 3. Tier 2.5 says (emphasis mine):
Tier 2.5 platforms can be thought of as "guaranteed to build", but without builds available through rustup
In the meantime, you will need to build your own libcore / libstd from source. I don't have the time nor ability to actually test that the compilation works, but something like these choices are the general starting path:
build-std
The unstable -Z build-std flag can be used to build the standard library:
% cargo +nightly build -Z build-std --target x86_64-apple-ios-macabi
Xargo
Building the standard library can be done using the xargo tool.
% rustup override set nightly
info: using existing install for 'nightly-x86_64-apple-darwin'
info: override toolchain for '/private/tmp/example' set to 'nightly-x86_64-apple-darwin'
nightly-x86_64-apple-darwin unchanged - rustc 1.41.0-nightly (5c5b8afd8 2019-11-16)
% cat > Xargo.toml
[target.x86_64-apple-ios-macabi.dependencies.std]
# features = ["jemalloc"] # Whatever is appropriate
% xargo build --target x86_64-apple-ios-macabi
# Iterate until libcore and libstd compile and work for your platform
#shepmaster 's answer is correct. In detail, you have to:
Install Xargo:
cargo install xargo
cd in your project
use the nighly build:
rustup override set nightly
create the Xargo.toml file with content:
[target.x86_64-apple-ios-macabi.dependencies.std]
In your projects Cargo.toml, make sure the [profile.release] section contains panic = "abort". If it does not, add it.
When building the project, use xargoinstead of cargo.
Shepmaster's answer is a little outdated. Cargo now supports the -Zbuild-std command. Using it, you can target any of the targets that rustc itself supports even if they aren't listed on rustup +nightly target list. Simply:
rustc +nightly --print target-list
and
cargo +nightly build -Z build-std --target x86_64-apple-ios-macabi
should be enough now. You don't need xargo to build the standard lib anymore.
If you have an old installation of rust, you might need to remove old nightly (or at least for me it fails to update nightly):
rustup toolchain remove nightly
rustup update
rustup toolchain install nightly
I'm trying to build and test my Rust code with a CI, and I'm wondering whether cargo clippy (potentially with options) covers everything that cargo check does. Do I only need to run cargo clippy, or do I need to run both?
clippy itself runs cargo check.
I'm using a specific Rust nightly build for CS 140E. When I run the commands
rustup default nightly-2018-01-09
rustup component add rust-src
cargo install xargo
I end up with libc failing to build:
error: non-string literals in attributes, or string literals in top-level positions, are experimental (see issue #34981)
--> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.58/src/macros.rs:78:15
It also mentions
= help: add #![feature(attr_literals)] to the crate attributes to enable
Which I've done, which brings me to more complex errors that I have less confidence to fix. Is a nightly build failing in this manner expected? I've also tried rustup default nightly and rustup default stable and they both fail for other reasons.