Empowering everyone to build reliable and efficient software.
Go to file
bors 8b9376a706 Auto merge of #131349 - RalfJung:const-stability-checks, r=compiler-errors
Const stability checks v2

The const stability system has served us well ever since `const fn` were first stabilized. It's main feature is that it enforces *recursive* validity -- a stable const fn cannot internally make use of unstable const features without an explicit marker in the form of `#[rustc_allow_const_fn_unstable]`. This is done to make sure that we don't accidentally expose unstable const features on stable in a way that would be hard to take back. As part of this, it is enforced that a `#[rustc_const_stable]` can only call `#[rustc_const_stable]` functions. However, some problems have been coming up with increased usage:
- It is baffling that we have to mark private or even unstable functions as `#[rustc_const_stable]` when they are used as helpers in regular stable `const fn`, and often people will rather add `#[rustc_allow_const_fn_unstable]` instead which was not our intention.
- The system has several gaping holes: a private `const fn` without stability attributes whose inherited stability (walking up parent modules) is `#[stable]` is allowed to call *arbitrary* unstable const operations, but can itself be called from stable `const fn`. Similarly, `#[allow_internal_unstable]` on a macro completely bypasses the recursive nature of the check.

Fundamentally, the problem is that we have *three* disjoint categories of functions, and not enough attributes to distinguish them:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features

Functions in the first two categories cannot use unstable const features and they can only call functions from the first two categories.

This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.

Also, all the holes mentioned above have been closed. There's still one potential hole that is hard to avoid, which is when MIR building automatically inserts calls to a particular function in stable functions -- which happens in the panic machinery. Those need to be manually marked `#[rustc_const_stable_indirect]` to be sure they follow recursive const stability. But that's a fairly rare and special case so IMO it's fine.

The net effect of this is that a `#[unstable]` or unmarked function can be constified simply by marking it as `const fn`, and it will then be const-callable from stable `const fn` and subject to recursive const stability requirements. If it is publicly reachable (which implies it cannot be unmarked), it will be const-unstable under the same feature gate. Only if the function ever becomes `#[stable]` does it need a `#[rustc_const_unstable]` or `#[rustc_const_stable]` marker to decide if this should also imply const-stability.

Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to use unstable const lang features (including intrinsics), or (b) `#[stable]` functions that are not yet intended to be const-stable. Adding `#[rustc_const_stable]` is only needed for functions that are actually meant to be directly callable from stable const code. `#[rustc_const_stable_indirect]` is used to mark intrinsics as const-callable and for `#[rustc_const_unstable]` functions that are actually called from other, exposed-on-stable `const fn`. No other attributes are required.

Also see the updated dev-guide at https://github.com/rust-lang/rustc-dev-guide/pull/2098.

I think in the future we may want to tweak this further, so that in the hopefully common case where a public function's const-stability just exactly mirrors its regular stability, we never have to add any attribute. But right now, once the function is stable this requires `#[rustc_const_stable]`.

### Open question

There is one point I could see we might want to do differently, and that is putting `#[rustc_const_unstable]`  functions (but not intrinsics) in category 2 by default, and requiring an extra attribute for `#[rustc_const_not_exposed_on_stable]` or so. This would require a bunch of extra annotations, but would have the advantage that turning a `#[rustc_const_unstable]` into `#[rustc_const_stable]`  will never change the way the function is const-checked. Currently, we often discover in the const stabilization PR that a function needs some other unstable const things, and then we rush to quickly deal with that. In this alternative universe, we'd work towards getting rid of the `rustc_const_not_exposed_on_stable` before stabilization, and once that is done stabilization becomes a trivial matter. `#[rustc_const_stable_indirect]` would then only be used for intrinsics.

I think I like this idea, but might want to do it in a follow-up PR, as it will need a whole bunch of annotations in the standard library. Also, we probably want to convert all const intrinsics to the "new" form (`#[rustc_intrinsic]` instead of an `extern` block) before doing this to avoid having to deal with two different ways of declaring intrinsics.

Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
Part of https://github.com/rust-lang/rust/issues/129815 (but not finished since this is not yet sufficient to safely let us expose `const fn` from hashbrown)
Fixes https://github.com/rust-lang/rust/issues/131073 by making it so that const-stable functions are always stable

try-job: test-various
2024-10-25 23:29:40 +00:00
.cargo Merge commit '0f8eabd6231366bfc1bb1464601297c2d48f8f68' into clippyup 2024-08-24 18:33:44 -04:00
.github Merge commit 'a109190d7060236e655fc75533373fa274ec5343' into clippy-subtree-update 2024-10-18 13:44:06 +02:00
book Merge commit 'a109190d7060236e655fc75533373fa274ec5343' into clippy-subtree-update 2024-10-18 13:44:06 +02:00
clippy_config Merge commit 'a109190d7060236e655fc75533373fa274ec5343' into clippy-subtree-update 2024-10-18 13:44:06 +02:00
clippy_dev Merge commit 'a109190d7060236e655fc75533373fa274ec5343' into clippy-subtree-update 2024-10-18 13:44:06 +02:00
clippy_dummy Merge commit '3e5a02b13b1244545454752c6629b767522a44b1' into clippy-subtree-update 2024-06-13 12:30:48 +02:00
clippy_lints nightly feature tracking: get rid of the per-feature bool fields 2024-10-23 09:14:41 +01:00
clippy_utils Auto merge of #131349 - RalfJung:const-stability-checks, r=compiler-errors 2024-10-25 23:29:40 +00:00
etc/relicense Merge commit '83e42a2337dadac915c956d125f1d69132f36425' into clippyup 2023-04-11 15:31:08 +02:00
lintcheck Merge commit 'a109190d7060236e655fc75533373fa274ec5343' into clippy-subtree-update 2024-10-18 13:44:06 +02:00
rustc_tools_util Merge commit 'a109190d7060236e655fc75533373fa274ec5343' into clippy-subtree-update 2024-10-18 13:44:06 +02:00
src Merge commit 'aa0d551351a9c15d8a95fdb3e2946b505893dda8' into clippy-subtree-update 2024-10-03 16:32:51 +02:00
tests make unsupported_calling_conventions a hard error 2024-10-20 15:22:21 +02:00
util Merge commit 'a109190d7060236e655fc75533373fa274ec5343' into clippy-subtree-update 2024-10-18 13:44:06 +02:00
.editorconfig Merge commit '83e42a2337dadac915c956d125f1d69132f36425' into clippyup 2023-04-11 15:31:08 +02:00
.gitattributes git attribute macros not allowed in submodules 2020-03-29 06:58:37 -07:00
.gitignore Merge commit 'a109190d7060236e655fc75533373fa274ec5343' into clippy-subtree-update 2024-10-18 13:44:06 +02:00
.remarkrc Merge commit '61eb38aeda6cb54b93b872bf503d70084c4d621c' into clippyup 2021-07-01 18:17:38 +02:00
build.rs Merge commit '4bdfb0741dbcecd5279a2635c3280726db0604b5' into clippyup 2022-12-17 14:12:54 +01:00
Cargo.toml Merge commit 'a109190d7060236e655fc75533373fa274ec5343' into clippy-subtree-update 2024-10-18 13:44:06 +02:00
CHANGELOG.md Merge commit 'a109190d7060236e655fc75533373fa274ec5343' into clippy-subtree-update 2024-10-18 13:44:06 +02:00
clippy.toml Merge commit '37f4fbb92913586b73a35772efd00eccd1cbbe13' into clippy-subtree-update 2024-07-25 18:29:17 +02:00
CODE_OF_CONDUCT.md Merge commit 'f4850f7292efa33759b4f7f9b7621268979e9914' into clippyup 2022-11-21 20:51:52 +01:00
CONTRIBUTING.md Merge commit 'edb720b199083f4107b858a8761648065bf38d86' into clippyup 2023-11-16 19:13:24 +01:00
COPYRIGHT Merge commit '26ac6aab023393c94edf42f38f6ad31196009643' 2024-01-11 17:27:03 +01:00
LICENSE-APACHE Merge commit '26ac6aab023393c94edf42f38f6ad31196009643' 2024-01-11 17:27:03 +01:00
LICENSE-MIT Merge commit '26ac6aab023393c94edf42f38f6ad31196009643' 2024-01-11 17:27:03 +01:00
README.md Merge commit '3e5a02b13b1244545454752c6629b767522a44b1' into clippy-subtree-update 2024-06-13 12:30:48 +02:00
rinja.toml Merge commit 'a109190d7060236e655fc75533373fa274ec5343' into clippy-subtree-update 2024-10-18 13:44:06 +02:00
rust-toolchain Merge commit 'a109190d7060236e655fc75533373fa274ec5343' into clippy-subtree-update 2024-10-18 13:44:06 +02:00
rustfmt.toml Merge commit 'd9c24d1b1ee61f276e550b967409c9f155eac4e3' into clippyup 2023-07-17 10:22:32 +02:00
triagebot.toml Merge commit 'a109190d7060236e655fc75533373fa274ec5343' into clippy-subtree-update 2024-10-18 13:44:06 +02:00

Clippy

Clippy Test License: MIT OR Apache-2.0

A collection of lints to catch common mistakes and improve your Rust code.

There are over 700 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 Warn lints using the clippy lint group (#![deny(clippy::all)]). Note that rustc has additional lint groups.

  • all lints using both the clippy and clippy::pedantic lint groups (#![deny(clippy::all)], #![deny(clippy::pedantic)]). Note that clippy::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::...

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.toml or .clippy.toml cannot 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.


  1. Some use cases for restriction lints include:

    ↩︎