09e4659a86
Initial implementation `result_large_err` This is a shot at #6560, #4652, and #3884. The lint checks for `Result` being returned from functions/methods where the `Err` variant is larger than a configurable threshold (the default of which is 128 bytes). There has been some discussion around this, which I'll try to quickly summarize: * A large `Err`-variant may force an equally large `Result` if `Err` is actually bigger than `Ok`. * There is a cost involved in large `Result`, as LLVM may choose to `memcpy` them around above a certain size. * We usually expect the `Err` variant to be seldomly used, but pay the cost every time. * `Result` returned from library code has a high chance of bubbling up the call stack, getting stuffed into `MyLibError { IoError(std::io::Error), ParseError(parselib::Error), ...}`, exacerbating the problem. This PR deliberately does not take into account comparing the `Ok` to the `Err` variant (e.g. a ratio, or one being larger than the other). Rather we choose an absolute threshold for `Err`'s size, above which we warn. The reason for this is that `Err`s probably get `map_err`'ed further up the call stack, and we can't draw conclusions from the ratio at the point where the `Result` is returned. A relative threshold would also be less predictable, while not accounting for the cost of LLVM being forced to generate less efficient code if the `Err`-variant is _large_ in absolute terms. We lint private functions as well as public functions, as the perf-cost applies to in-crate code as well. In order to account for type-parameters, I conjured up `fn approx_ty_size`. The function relies on `LateContext::layout_of` to compute the actual size, and in case of failure (e.g. due to generics) tries to come up with an "at least size". In the latter case, the size of obviously wrong, but the inspected size certainly can't be smaller than that. Please give the approach a heavy dose of review, as I'm not actually familiar with the type-system at all (read: I have no idea what I'm doing). The approach does, however flimsy it is, allow us to successfully lint situations like ```rust pub union UnionError<T: Copy> { _maybe: T, _or_perhaps_even: (T, [u8; 512]), } // We know `UnionError<T>` will be at least 512 bytes, no matter what `T` is pub fn param_large_union<T: Copy>() -> Result<(), UnionError<T>> { Ok(()) } ``` I've given some refactoring to `functions/result_unit_err.rs` to re-use some bits. This is also the groundwork for #6409 The default threshold is 128 because of https://github.com/rust-lang/rust-clippy/issues/4652#issue-505670554 `lintcheck` does not trigger this lint for a threshold of 128. It does warn for 64, though. The suggestion currently is the following, which is just a placeholder for discussion to be had. I did have the computed size in a `span_label`. However, that might cause both ui-tests here and lints elsewhere to become flaky wrt to their output (as the size is platform dependent). ``` error: the `Err`-variant returned via this `Result` is very large --> $DIR/result_large_err.rs:36:34 | LL | pub fn param_large_error<R>() -> Result<(), (u128, R, FullyDefinedLargeError)> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The `Err` variant is unusually large, at least 128 bytes ``` changelog: Add [`result_large_err`] lint |
||
---|---|---|
.cargo | ||
.github | ||
book | ||
clippy_dev | ||
clippy_dummy | ||
clippy_lints | ||
clippy_utils | ||
etc/relicense | ||
lintcheck | ||
rustc_tools_util | ||
src | ||
tests | ||
util | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
.remarkrc | ||
build.rs | ||
Cargo.toml | ||
CHANGELOG.md | ||
clippy.toml | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
COPYRIGHT | ||
LICENSE-APACHE | ||
LICENSE-MIT | ||
README.md | ||
rust-toolchain | ||
rustfmt.toml | ||
triagebot.toml |
Clippy
A collection of lints to catch common mistakes and improve your Rust code.
There are over 550 lints included in this crate!
Lints are divided into categories, each with a default lint level.
You can choose how much Clippy is supposed to annoy help you by changing the lint level by category.
Category | Description | Default level |
---|---|---|
clippy::all |
all lints that are on by default (correctness, suspicious, style, complexity, perf) | warn/deny |
clippy::correctness |
code that is outright wrong or useless | deny |
clippy::suspicious |
code that is most likely wrong or useless | warn |
clippy::style |
code that should be written in a more idiomatic way | warn |
clippy::complexity |
code that does something simple but in a complex way | warn |
clippy::perf |
code that can be written to run faster | warn |
clippy::pedantic |
lints which are rather strict or have occasional false positives | allow |
clippy::nursery |
new lints that are still under development | allow |
clippy::cargo |
lints for the cargo manifest | allow |
More to come, please file an issue if you have ideas!
The lint list also contains "restriction lints", which are for things which are usually not considered "bad", but may be useful to turn on in specific cases. These should be used very selectively, if at all.
Table of contents:
Usage
Below are instructions on how to use Clippy as a cargo subcommand, in projects that do not use cargo, or in Travis CI.
As a cargo subcommand (cargo clippy
)
One way to use Clippy is by installing Clippy through rustup as a cargo subcommand.
Step 1: Install Rustup
You can install Rustup on supported platforms. This will help us install Clippy and its dependencies.
If you already have Rustup installed, update to ensure you have the latest Rustup and compiler:
rustup update
Step 2: Install Clippy
Once you have rustup and the latest stable release (at least Rust 1.29) installed, run the following command:
rustup component add clippy
If it says that it can't find the clippy
component, please run rustup self update
.
Step 3: Run Clippy
Now you can run Clippy by invoking the following command:
cargo clippy
Automatically applying Clippy suggestions
Clippy can automatically apply some lint suggestions, just like the compiler.
cargo clippy --fix
Workspaces
All the usual workspace options should work with Clippy. For example the following command
will run Clippy on the example
crate:
cargo clippy -p example
As with cargo check
, this includes dependencies that are members of the workspace, like path dependencies.
If you want to run Clippy only on the given crate, use the --no-deps
option like this:
cargo clippy -p example -- --no-deps
Using clippy-driver
Clippy can also be used in projects that do not use cargo. To do so, run clippy-driver
with the same arguments you use for rustc
. For example:
clippy-driver --edition 2018 -Cpanic=abort foo.rs
Note that clippy-driver
is designed for running Clippy only and should not be used as a general
replacement for rustc
. clippy-driver
may produce artifacts that are not optimized as expected,
for example.
Travis CI
You can add Clippy to Travis CI in the same way you use it locally:
language: rust
rust:
- stable
- beta
before_script:
- rustup component add clippy
script:
- cargo clippy
# if you want the build job to fail when encountering warnings, use
- cargo clippy -- -D warnings
# in order to also check tests and non-default crate features, use
- cargo clippy --all-targets --all-features -- -D warnings
- cargo test
# etc.
Note that adding -D warnings
will cause your build to fail if any warnings are found in your code.
That includes warnings found by rustc (e.g. dead_code
, etc.). If you want to avoid this and only cause
an error for Clippy warnings, use #![deny(clippy::all)]
in your code or -D clippy::all
on the command
line. (You can swap clippy::all
with the specific lint category you are targeting.)
Configuration
Some lints can be configured in a TOML file named clippy.toml
or .clippy.toml
. It contains a basic variable = value
mapping e.g.
avoid-breaking-exported-api = false
disallowed-names = ["toto", "tata", "titi"]
cognitive-complexity-threshold = 30
See the list of lints for more information about which lints can be configured and the meaning of the variables.
Note that configuration changes will not apply for code that has already been compiled and cached under ./target/
;
for example, adding a new string to doc-valid-idents
may still result in Clippy flagging that string. To be sure that
any configuration changes are applied, you may want to run cargo clean
and re-compile your crate from scratch.
To deactivate the “for further information visit lint-link” message you can
define the CLIPPY_DISABLE_DOCS_LINKS
environment variable.
Allowing/denying lints
You can add options to your code to allow
/warn
/deny
Clippy lints:
-
the whole set of
Warn
lints using theclippy
lint group (#![deny(clippy::all)]
). Note thatrustc
has additional lint groups. -
all lints using both the
clippy
andclippy::pedantic
lint groups (#![deny(clippy::all)]
,#![deny(clippy::pedantic)]
). Note thatclippy::pedantic
contains some very aggressive lints prone to false positives. -
only some lints (
#![deny(clippy::single_match, clippy::box_vec)]
, etc.) -
allow
/warn
/deny
can be limited to a single function or module using#[allow(...)]
, etc.
Note: allow
means to suppress the lint for your code. With warn
the lint
will only emit a warning, while with deny
the lint will emit an error, when
triggering for your code. An error causes clippy to exit with an error code, so
is useful in scripts like CI/CD.
If you do not want to include your lint levels in your code, you can globally enable/disable lints by passing extra flags to Clippy during the run:
To allow lint_name
, run
cargo clippy -- -A clippy::lint_name
And to warn on lint_name
, run
cargo clippy -- -W clippy::lint_name
This also works with lint groups. For example, you can run Clippy with warnings for all lints enabled:
cargo clippy -- -W clippy::pedantic
If you care only about a single lint, you can allow all others and then explicitly warn on the lint(s) you are interested in:
cargo clippy -- -A clippy::all -W clippy::useless_format -W clippy::...
Specifying the minimum supported Rust version
Projects that intend to support old versions of Rust can disable lints pertaining to newer features by specifying the minimum supported Rust version (MSRV) in the clippy configuration file.
msrv = "1.30.0"
Alternatively, the rust-version
field
in the Cargo.toml
can be used.
# Cargo.toml
rust-version = "1.30"
The MSRV can also be specified as an inner attribute, like below.
#![feature(custom_inner_attributes)]
#![clippy::msrv = "1.30.0"]
fn main() {
...
}
You can also omit the patch version when specifying the MSRV, so msrv = 1.30
is equivalent to msrv = 1.30.0
.
Note: custom_inner_attributes
is an unstable feature, so it has to be enabled explicitly.
Lints that recognize this configuration option can be found here
Contributing
If you want to contribute to Clippy, you can find more information in CONTRIBUTING.md.
License
Copyright 2014-2022 The Rust Project Developers
Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or https://opensource.org/licenses/MIT>, at your option. Files in the project may not be copied, modified, or distributed except according to those terms.