Forbid usage of `hir` `Infer` const/ty variants in ambiguous contexts
The feature `generic_arg_infer` allows providing `_` as an argument to const generics in order to infer them. This introduces a syntactic ambiguity as to whether generic arguments are type or const arguments. In order to get around this we introduced a fourth `GenericArg` variant, `Infer` used to represent `_` as an argument to generic parameters when we don't know if its a type or a const argument.
This made hir visitors that care about `TyKind::Infer` or `ConstArgKind::Infer` very error prone as checking for `TyKind::Infer`s in `visit_ty` would find *some* type infer arguments but not *all* of them as they would sometimes be lowered to `GenericArg::Infer` instead.
Additionally the `visit_infer` method would previously only visit `GenericArg::Infer` not *all* infers (e.g. `TyKind::Infer`), this made it very easy to override `visit_infer` and expect it to visit all infers when in reality it would only visit *some* infers.
---
This PR aims to fix those issues by making the `TyKind` and `ConstArgKind` types generic over whether the infer types/consts are represented by `Ty/ConstArgKind::Infer` or out of line (e.g. by a `GenericArg::Infer` or accessible by overiding `visit_infer`). We then make HIR Visitors convert all const args and types to the versions where infer vars are stored out of line and call `visit_infer` in cases where a `Ty`/`Const` would previously have had a `Ty/ConstArgKind::Infer` variant:
API Summary
```rust
enum AmbigArg {}
enum Ty/ConstArgKind<Unambig = ()> {
...
Infer(Unambig),
}
impl Ty/ConstArg {
fn try_as_ambig_ty/ct(self) -> Option<Ty/ConstArg<AmbigArg>>;
}
impl Ty/ConstArg<AmbigArg> {
fn as_unambig_ty/ct(self) -> Ty/ConstArg;
}
enum InferKind {
Ty(Ty),
Const(ConstArg),
Ambig(InferArg),
}
trait Visitor {
...
fn visit_ty/const_arg(&mut self, Ty/ConstArg<AmbigArg>) -> Self::Result;
fn visit_infer(&mut self, id: HirId, sp: Span, kind: InferKind) -> Self::Result;
}
// blanket impl'd, not meant to be overriden
trait VisitorExt {
fn visit_ty/const_arg_unambig(&mut self, Ty/ConstArg) -> Self::Result;
}
fn walk_unambig_ty/const_arg(&mut V, Ty/ConstArg) -> Self::Result;
fn walk_ty/const_arg(&mut V, Ty/ConstArg<AmbigArg>) -> Self::Result;
```
The end result is that `visit_infer` visits *all* infer args and is also the *only* way to visit an infer arg, `visit_ty` and `visit_const_arg` can now no longer encounter a `Ty/ConstArgKind::Infer`. Representing this in the type system means that it is now very difficult to mess things up, either accessing `TyKind::Infer` "just works" and you won't miss *some* type infers- or it doesn't work and you have to look at `visit_infer` or some `GenericArg::Infer` which forces you to think about the full complexity involved.
Unfortunately there is no lint right now about explicitly matching on uninhabited variants, I can't find the context for why this is the case 🤷♀️
I'm not convinced the framing of un/ambig ty/consts is necessarily the right one but I'm not sure what would be better. I somewhat like calling them full/partial types based on the fact that `Ty<Partial>`/`Ty<Full>` directly specifies how many of the type kinds are actually represented compared to `Ty<Ambig>` which which leaves that to the reader to figure out based on the logical consequences of it the type being in an ambiguous position.
---
tool changes have been modified in their own commits for easier reviewing by anyone getting cc'd from subtree changes. I also attempted to split out "bug fixes arising from the refactoring" into their own commit so they arent lumped in with a big general refactor commit
Fixes #112110
|
||
|---|---|---|
| .cargo | ||
| .github | ||
| book | ||
| clippy_config | ||
| 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 | ||
| rinja.toml | ||
| rust-toolchain | ||
| rustfmt.toml | ||
| triagebot.toml | ||
Clippy
A collection of lints to catch common mistakes and improve your Rust code.
There are over 750 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::restriction |
lints which prevent the use of language and library features1 | 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 restriction category should, emphatically, not be enabled as a whole. The contained
lints may lint against perfectly reasonable code, may not have an alternative suggestion,
and may contradict any other lints (including other categories). Lints should be considered
on a case-by-case basis before enabling.
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. Note that --fix implies
--all-targets, so it can fix as much code as it can.
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
Allowing/denying lints
You can add options to your code to allow/warn/deny Clippy lints:
-
the whole set of
Warnlints using theclippylint group (#![deny(clippy::all)]). Note thatrustchas additional lint groups. -
all lints using both the
clippyandclippy::pedanticlint groups (#![deny(clippy::all)],#![deny(clippy::pedantic)]). Note thatclippy::pedanticcontains some very aggressive lints prone to false positives. -
only some lints (
#![deny(clippy::single_match, clippy::box_vec)], etc.) -
allow/warn/denycan 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::...
Configure the behavior of some lints
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"]
The table of configurations contains all config values, their default, and a list of lints they affect. Each configurable lint , also contains information about these values.
For configurations that are a list type with default values such as
disallowed-names,
you can use the unique value ".." to extend the default values instead of replacing them.
# default of disallowed-names is ["foo", "baz", "quux"]
disallowed-names = ["bar", ".."] # -> ["bar", "foo", "baz", "quux"]
Note
clippy.tomlor.clippy.tomlcannot be used to allow/deny lints.
To deactivate the “for further information visit lint-link” message you can
define the CLIPPY_DISABLE_DOCS_LINKS environment variable.
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 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-2024 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.
-
Some use cases for
restrictionlints include:- Strict coding styles (e.g.
clippy::else_if_without_else). - Additional restrictions on CI (e.g.
clippy::todo). - Preventing panicking in certain functions (e.g.
clippy::unwrap_used). - Running a lint only on a subset of code (e.g.
#[forbid(clippy::float_arithmetic)]on a module).
- Strict coding styles (e.g.