What is rustc?

Welcome to "The rustc book"! rustc is the compiler for the Rust programming language, provided by the project itself. Compilers take your source code and produce binary code, either as a library or executable.

Most Rust programmers don't invoke rustc directly, but instead do it through Cargo. It's all in service of rustc though! If you want to see how Cargo calls rustc, you can

$ cargo build --verbose

And it will print out each rustc invocation. This book can help you understand what each of these options does. Additionally, while most Rustaceans use Cargo, not all do: sometimes they integrate rustc into other build systems. This book should provide a guide to all of the options you'd need to do so.

Basic usage

Let's say you've got a little hello world program in a file hello.rs:

fn main() {
    println!("Hello, world!");
}

To turn this source code into an executable, you can use rustc:

$ rustc hello.rs
$ ./hello # on a *NIX
$ .\hello.exe # on Windows

Note that we only ever pass rustc the crate root, not every file we wish to compile. For example, if we had a main.rs that looked like this:

mod foo;

fn main() {
    foo::hello();
}

And a foo.rs that had this:

pub fn hello() {
    println!("Hello, world!");
}

To compile this, we'd run this command:

$ rustc main.rs

No need to tell rustc about foo.rs; the mod statements give it everything that it needs. This is different than how you would use a C compiler, where you invoke the compiler on each file, and then link everything together. In other words, the crate is a translation unit, not a particular module.

Command-line Arguments

Here's a list of command-line arguments to rustc and what they do.

-h/--help: get help

This flag will print out help information for rustc.

--cfg: configure the compilation environment

This flag can turn on or off various #[cfg] settings for conditional compilation.

The value can either be a single identifier or two identifiers separated by =.

For examples, --cfg 'verbose' or --cfg 'feature="serde"'. These correspond to #[cfg(verbose)] and #[cfg(feature = "serde")] respectively.

--check-cfg: configure compile-time checking of conditional compilation

This flag enables checking conditional configurations of the crate at compile-time, specifically it helps configure the set of expected cfg names and values, in order to check that every reachable #[cfg] matches the expected config names and values.

This is different from the --cfg flag above which activates some config but do not expect them. This is useful to prevent stalled conditions, typos, ...

Refer to the Checking conditional configurations of this book for further details and explanation.

For examples, --check-cfg 'cfg(verbose)' or --check-cfg 'cfg(feature, values("serde"))'. These correspond to #[cfg(verbose)] and #[cfg(feature = "serde")] respectively.

-L: add a directory to the library search path

The -L flag adds a path to search for external crates and libraries.

The kind of search path can optionally be specified with the form -L KIND=PATH where KIND may be one of:

• dependency — Only search for transitive dependencies in this directory.
• crate — Only search for this crate's direct dependencies in this directory.
• native — Only search for native libraries in this directory.
• framework — Only search for macOS frameworks in this directory.
• all — Search for all library kinds in this directory, except frameworks. This is the default if KIND is not specified.

-l: link the generated crate to a native library

Syntax: -l [KIND[:MODIFIERS]=]NAME[:RENAME].

This flag allows you to specify linking to a specific native library when building a crate.

The kind of library can optionally be specified with the form -l KIND=lib where KIND may be one of:

• dylib — A native dynamic library.
• static — A native static library (such as a .a archive).
• framework — A macOS framework.

If the kind is specified, then linking modifiers can be attached to it. Modifiers are specified as a comma-delimited string with each modifier prefixed with either a + or - to indicate that the modifier is enabled or disabled, respectively. Specifying multiple modifiers arguments in a single link attribute, or multiple identical modifiers in the same modifiers argument is not currently supported.
Example: -l static:+whole-archive=mylib.

The kind of library and the modifiers can also be specified in a #[link] attribute. If the kind is not specified in the link attribute or on the command-line, it will link a dynamic library by default, except when building a static executable. If the kind is specified on the command-line, it will override the kind specified in a link attribute.

The name used in a link attribute may be overridden using the form -l ATTR_NAME:LINK_NAME where ATTR_NAME is the name in the link attribute, and LINK_NAME is the name of the actual library that will be linked.

Linking modifiers: whole-archive

This modifier is only compatible with the static linking kind. Using any other kind will result in a compiler error.

+whole-archive means that the static library is linked as a whole archive without throwing any object files away.

This modifier translates to --whole-archive for ld-like linkers, to /WHOLEARCHIVE for link.exe, and to -force_load for ld64. The modifier does nothing for linkers that don't support it.

The default for this modifier is -whole-archive.

Linking modifiers: bundle

This modifier is only compatible with the static linking kind. Using any other kind will result in a compiler error.

When building a rlib or staticlib +bundle means that the native static library will be packed into the rlib or staticlib archive, and then retrieved from there during linking of the final binary.

When building a rlib -bundle means that the native static library is registered as a dependency of that rlib "by name", and object files from it are included only during linking of the final binary, the file search by that name is also performed during final linking.
When building a staticlib -bundle means that the native static library is simply not included into the archive and some higher level build system will need to add it later during linking of the final binary.

This modifier has no effect when building other targets like executables or dynamic libraries.

The default for this modifier is +bundle.

Linking modifiers: verbatim

This modifier is compatible with all linking kinds.

+verbatim means that rustc itself won't add any target-specified library prefixes or suffixes (like lib or .a) to the library name, and will try its best to ask for the same thing from the linker.

For ld-like linkers supporting GNU extensions rustc will use the -l:filename syntax (note the colon) when passing the library, so the linker won't add any prefixes or suffixes to it. See -l namespec in ld documentation for more details.
For linkers not supporting any verbatim modifiers (e.g. link.exe or ld64) the library name will be passed as is. So the most reliable cross-platform use scenarios for this option are when no linker is involved, for example bundling native libraries into rlibs.

-verbatim means that rustc will either add a target-specific prefix and suffix to the library name before passing it to linker, or won't prevent linker from implicitly adding it.
In case of raw-dylib kind in particular .dll will be added to the library name on Windows.

The default for this modifier is -verbatim.

NOTE: Even with +verbatim and -l:filename syntax ld-like linkers do not typically support passing absolute paths to libraries. Usually such paths need to be passed as input files without using any options like -l, e.g. ld /my/absolute/path.
-Clink-arg=/my/absolute/path can be used for doing this from stable rustc.

--crate-type: a list of types of crates for the compiler to emit

This instructs rustc on which crate type to build. This flag accepts a comma-separated list of values, and may be specified multiple times. The valid crate types are:

• lib — Generates a library kind preferred by the compiler, currently defaults to rlib.
• rlib — A Rust static library.
• staticlib — A native static library.
• dylib — A Rust dynamic library.
• cdylib — A native dynamic library.
• bin — A runnable executable program.
• proc-macro — Generates a format suitable for a procedural macro library that may be loaded by the compiler.

The crate type may be specified with the crate_type attribute. The --crate-type command-line value will override the crate_type attribute.

More details may be found in the linkage chapter of the reference.

--crate-name: specify the name of the crate being built

This informs rustc of the name of your crate.

--edition: specify the edition to use

This flag takes a value of 2015, 2018 or 2021. The default is 2015. More information about editions may be found in the edition guide.

--emit: specifies the types of output files to generate

This flag controls the types of output files generated by the compiler. It accepts a comma-separated list of values, and may be specified multiple times. The valid emit kinds are:

• asm — Generates a file with the crate's assembly code. The default output filename is CRATE_NAME.s.
• dep-info — Generates a file with Makefile syntax that indicates all the source files that were loaded to generate the crate. The default output filename is CRATE_NAME.d.
• link — Generates the crates specified by --crate-type. The default output filenames depend on the crate type and platform. This is the default if --emit is not specified.
• llvm-bc — Generates a binary file containing the LLVM bitcode. The default output filename is CRATE_NAME.bc.
• llvm-ir — Generates a file containing LLVM IR. The default output filename is CRATE_NAME.ll.
• metadata — Generates a file containing metadata about the crate. The default output filename is libCRATE_NAME.rmeta.
• mir — Generates a file containing rustc's mid-level intermediate representation. The default output filename is CRATE_NAME.mir.
• obj — Generates a native object file. The default output filename is CRATE_NAME.o.

The output filename can be set with the -o flag. A suffix may be added to the filename with the -C extra-filename flag.

Output files are written to the current directory unless the --out-dir flag is used.

Custom paths for individual emit kinds

Each emit type can optionally be followed by = to specify an explicit output path that only applies to the output of that type. For example:

• --emit=link,dep-info=/path/to/dep-info.d
  • Emit the crate itself as normal, and also emit dependency info to the specified path.
• --emit=llvm-ir=-,mir
  • Emit MIR to the default filename (based on crate name), and emit LLVM IR to stdout.

Emitting to stdout

When using --emit or -o, output can be sent to stdout by specifying - as the path (e.g. -o -).

Binary output types can only be written to stdout if it is not a tty. Text output types (asm, dep-info, llvm-ir and mir) can be written to stdout regardless of whether it is a tty or not.

Only one type of output can be written to stdout. Attempting to write multiple types to stdout at the same time will result in an error.

--print: print compiler information

This flag prints out various information about the compiler. This flag may be specified multiple times, and the information is printed in the order the flags are specified. Specifying a --print flag will usually disable the --emit step and will only print the requested information. The valid types of print values are:

• crate-name — The name of the crate.
• file-names — The names of the files created by the link emit kind.
• sysroot — Path to the sysroot.
• target-libdir — Path to the target libdir.
• host-tuple — The target-tuple string of the host compiler (e.g. x86_64-unknown-linux-gnu)
• cfg — List of cfg values. See conditional compilation for more information about cfg values.
• target-list — List of known targets. The target may be selected with the --target flag.
• target-cpus — List of available CPU values for the current target. The target CPU may be selected with the -C target-cpu=val flag.
• target-features — List of available target features for the current target. Target features may be enabled with the -C target-feature=val flag. This flag is unsafe. See known issues for more details.
• relocation-models — List of relocation models. Relocation models may be selected with the -C relocation-model=val flag.
• code-models — List of code models. Code models may be selected with the -C code-model=val flag.
• tls-models — List of Thread Local Storage models supported. The model may be selected with the -Z tls-model=val flag.
• native-static-libs — This may be used when creating a staticlib crate type. If this is the only flag, it will perform a full compilation and include a diagnostic note that indicates the linker flags to use when linking the resulting static library. The note starts with the text native-static-libs: to make it easier to fetch the output.
• link-args — This flag does not disable the --emit step. When linking, this flag causes rustc to print the full linker invocation in a human-readable form. This can be useful when debugging linker options. The exact format of this debugging output is not a stable guarantee, other than that it will include the linker executable and the text of each command-line argument passed to the linker.
• deployment-target — The currently selected deployment target (or minimum OS version) for the selected Apple platform target. This value can be used or passed along to other components alongside a Rust build that need this information, such as C compilers. This returns rustc's minimum supported deployment target if no *_DEPLOYMENT_TARGET variable is present in the environment, or otherwise returns the variable's parsed value.

A filepath may optionally be specified for each requested information kind, in the format --print KIND=PATH, just like for --emit. When a path is specified, information will be written there instead of to stdout.

-g: include debug information

A synonym for -C debuginfo=2.

-O: optimize your code

A synonym for -C opt-level=2.

-o: filename of the output

This flag controls the output filename.

--out-dir: directory to write the output in

The outputted crate will be written to this directory. This flag is ignored if the -o flag is used.

--explain: provide a detailed explanation of an error message

Each error of rustc's comes with an error code; this will print out a longer explanation of a given error.

--test: build a test harness

When compiling this crate, rustc will ignore your main function and instead produce a test harness. See the Tests chapter for more information about tests.

--target: select a target triple to build

This controls which target to produce.

-W: set lint warnings

This flag will set which lints should be set to the warn level.

Note: The order of these lint level arguments is taken into account, see lint level via compiler flag for more information.

--force-warn: force a lint to warn

This flag sets the given lint to the forced warn level and the level cannot be overridden, even ignoring the lint caps.

-A: set lint allowed

This flag will set which lints should be set to the allow level.

Note: The order of these lint level arguments is taken into account, see lint level via compiler flag for more information.

-D: set lint denied

This flag will set which lints should be set to the deny level.

Note: The order of these lint level arguments is taken into account, see lint level via compiler flag for more information.

-F: set lint forbidden

This flag will set which lints should be set to the forbid level.

Note: The order of these lint level arguments is taken into account, see lint level via compiler flag for more information.

-Z: set unstable options

This flag will allow you to set unstable options of rustc. In order to set multiple options, the -Z flag can be used multiple times. For example: rustc -Z verbose-internals -Z time-passes. Specifying options with -Z is only available on nightly. To view all available options run: rustc -Z help, or see The Unstable Book.

--cap-lints: set the most restrictive lint level

This flag lets you 'cap' lints, for more, see here.

-C/--codegen: code generation options

This flag will allow you to set codegen options.

-V/--version: print a version

This flag will print out rustc's version.

-v/--verbose: use verbose output

This flag, when combined with other flags, makes them produce extra output.

--extern: specify where an external library is located

This flag allows you to pass the name and location for an external crate of a direct dependency. Indirect dependencies (dependencies of dependencies) are located using the -L flag. The given crate name is added to the extern prelude, similar to specifying extern crate within the root module. The given crate name does not need to match the name the library was built with.

Specifying --extern has one behavior difference from extern crate: --extern merely makes the crate a candidate for being linked; it does not actually link it unless it's actively used. In rare occasions you may wish to ensure a crate is linked even if you don't actively use it from your code: for example, if it changes the global allocator or if it contains #[no_mangle] symbols for use by other programming languages. In such cases you'll need to use extern crate.

This flag may be specified multiple times. This flag takes an argument with either of the following formats:

• CRATENAME=PATH — Indicates the given crate is found at the given path.
• CRATENAME — Indicates the given crate may be found in the search path, such as within the sysroot or via the -L flag.

The same crate name may be specified multiple times for different crate types. If both an rlib and dylib are found, an internal algorithm is used to decide which to use for linking. The -C prefer-dynamic flag may be used to influence which is used.

If the same crate name is specified with and without a path, the one with the path is used and the pathless flag has no effect.

--sysroot: Override the system root

The "sysroot" is where rustc looks for the crates that come with the Rust distribution; this flag allows that to be overridden.

--error-format: control how errors are produced

This flag lets you control the format of messages. Messages are printed to stderr. The valid options are:

• human — Human-readable output. This is the default.
• json — Structured JSON output. See the JSON chapter for more detail.
• short — Short, one-line messages.

--color: configure coloring of output

This flag lets you control color settings of the output. The valid options are:

• auto — Use colors if output goes to a tty. This is the default.
• always — Always use colors.
• never — Never colorize output.

--diagnostic-width: specify the terminal width for diagnostics

This flag takes a number that specifies the width of the terminal in characters. Formatting of diagnostics will take the width into consideration to make them better fit on the screen.

--remap-path-prefix: remap source names in output

Remap source path prefixes in all output, including compiler diagnostics, debug information, macro expansions, etc. It takes a value of the form FROM=TO where a path prefix equal to FROM is rewritten to the value TO. The FROM may itself contain an = symbol, but the TO value may not. This flag may be specified multiple times.

This is useful for normalizing build products, for example by removing the current directory out of pathnames emitted into the object files. The replacement is purely textual, with no consideration of the current system's pathname syntax. For example --remap-path-prefix foo=bar will match foo/lib.rs but not ./foo/lib.rs.

When multiple remappings are given and several of them match, the last matching one is applied.

--json: configure json messages printed by the compiler

When the --error-format=json option is passed to rustc then all of the compiler's diagnostic output will be emitted in the form of JSON blobs. The --json argument can be used in conjunction with --error-format=json to configure what the JSON blobs contain as well as which ones are emitted.

With --error-format=json the compiler will always emit any compiler errors as a JSON blob, but the following options are also available to the --json flag to customize the output:

• diagnostic-short - json blobs for diagnostic messages should use the "short" rendering instead of the normal "human" default. This means that the output of --error-format=short will be embedded into the JSON diagnostics instead of the default --error-format=human.

• diagnostic-rendered-ansi - by default JSON blobs in their rendered field will contain a plain text rendering of the diagnostic. This option instead indicates that the diagnostic should have embedded ANSI color codes intended to be used to colorize the message in the manner rustc typically already does for terminal outputs. Note that this is usefully combined with crates like fwdansi to translate these ANSI codes on Windows to console commands or strip-ansi-escapes if you'd like to optionally remove the ansi colors afterwards.

• artifacts - this instructs rustc to emit a JSON blob for each artifact that is emitted. An artifact corresponds to a request from the --emit CLI argument, and as soon as the artifact is available on the filesystem a notification will be emitted.

• future-incompat - includes a JSON message that contains a report if the crate contains any code that may fail to compile in the future.

Note that it is invalid to combine the --json argument with the --color argument, and it is required to combine --json with --error-format=json.

See the JSON chapter for more detail.

@path: load command-line flags from a path

If you specify @path on the command-line, then it will open path and read command line options from it. These options are one per line; a blank line indicates an empty option. The file can use Unix or Windows style line endings, and must be encoded as UTF-8.

Codegen Options

All of these options are passed to rustc via the -C flag, short for "codegen." You can see a version of this list for your exact compiler by running rustc -C help.

ar

This option is deprecated and does nothing.

code-model

This option lets you choose which code model to use.
Code models put constraints on address ranges that the program and its symbols may use.
With smaller address ranges machine instructions may be able to use more compact addressing modes.

The specific ranges depend on target architectures and addressing modes available to them.
For x86 more detailed description of its code models can be found in System V Application Binary Interface specification.

Supported values for this option are:

• tiny - Tiny code model.
• small - Small code model. This is the default model for majority of supported targets.
• kernel - Kernel code model.
• medium - Medium code model.
• large - Large code model.

Supported values can also be discovered by running rustc --print code-models.

codegen-units

This flag controls the maximum number of code generation units the crate is split into. It takes an integer greater than 0.

When a crate is split into multiple codegen units, LLVM is able to process them in parallel. Increasing parallelism may speed up compile times, but may also produce slower code. Setting this to 1 may improve the performance of generated code, but may be slower to compile.

The default value, if not specified, is 16 for non-incremental builds. For incremental builds the default is 256 which allows caching to be more granular.

collapse-macro-debuginfo

This flag controls whether code locations from a macro definition are collapsed into a single location associated with that macro's call site, when generating debuginfo for this crate.

This option, if passed, overrides both default collapsing behavior and #[collapse_debuginfo] attributes in code.

• y, yes, on, true: collapse code locations in debuginfo.
• n, no, off or false: do not collapse code locations in debuginfo.
• external: collapse code locations in debuginfo only if the macro comes from a different crate.

control-flow-guard

This flag controls whether LLVM enables the Windows Control Flow Guard platform security feature. This flag is currently ignored for non-Windows targets. It takes one of the following values:

• y, yes, on, true, checks, or no value: enable Control Flow Guard.
• nochecks: emit Control Flow Guard metadata without runtime enforcement checks (this should only be used for testing purposes as it does not provide security enforcement).
• n, no, off, false: do not enable Control Flow Guard (the default).

debug-assertions

This flag lets you turn cfg(debug_assertions) conditional compilation on or off. It takes one of the following values:

• y, yes, on, true, or no value: enable debug-assertions.
• n, no, off or false: disable debug-assertions.

If not specified, debug assertions are automatically enabled only if the opt-level is 0.

debuginfo

This flag controls the generation of debug information. It takes one of the following values:

• 0 or none: no debug info at all (the default).
• line-directives-only: line info directives only. For the nvptx* targets this enables profiling. For other use cases, line-tables-only is the better, more compatible choice.
• line-tables-only: line tables only. Generates the minimal amount of debug info for backtraces with filename/line number info, but not anything else, i.e. no variable or function parameter info.
• 1 or limited: debug info without type or variable-level information.
• 2 or full: full debug info.

Note: The -g flag is an alias for -C debuginfo=2.

default-linker-libraries

This flag controls whether or not the linker includes its default libraries. It takes one of the following values:

• y, yes, on, true: include default libraries.
• n, no, off or false or no value: exclude default libraries (the default).

For example, for gcc flavor linkers, this issues the -nodefaultlibs flag to the linker.

dlltool

On windows-gnu targets, this flag controls which dlltool rustc invokes to generate import libraries when using the raw-dylib link kind. It takes a path to the dlltool executable. If this flag is not specified, a dlltool executable will be inferred based on the host environment and target.

embed-bitcode

This flag controls whether or not the compiler embeds LLVM bitcode into object files. It takes one of the following values:

• y, yes, on, true or no value: put bitcode in rlibs (the default).
• n, no, off or false: omit bitcode from rlibs.

LLVM bitcode is required when rustc is performing link-time optimization (LTO). It is also required on some targets like iOS ones where vendors look for LLVM bitcode. Embedded bitcode will appear in rustc-generated object files inside of a section whose name is defined by the target platform. Most of the time this is .llvmbc.

The use of -C embed-bitcode=no can significantly improve compile times and reduce generated file sizes if your compilation does not actually need bitcode (e.g. if you're not compiling for iOS or you're not performing LTO). For these reasons, Cargo uses -C embed-bitcode=no whenever possible. Likewise, if you are building directly with rustc we recommend using -C embed-bitcode=no whenever you are not using LTO.

If combined with -C lto, -C embed-bitcode=no will cause rustc to abort at start-up, because the combination is invalid.

Note: if you're building Rust code with LTO then you probably don't even need the embed-bitcode option turned on. You'll likely want to use -Clinker-plugin-lto instead which skips generating object files entirely and simply replaces object files with LLVM bitcode. The only purpose for -Cembed-bitcode is when you're generating an rlib that is both being used with and without LTO. For example Rust's standard library ships with embedded bitcode since users link to it both with and without LTO.

This also may make you wonder why the default is yes for this option. The reason for that is that it's how it was for rustc 1.44 and prior. In 1.45 this option was added to turn off what had always been the default.

extra-filename

This option allows you to put extra data in each output filename. It takes a string to add as a suffix to the filename. See the --emit flag for more information.

force-frame-pointers

This flag forces the use of frame pointers. It takes one of the following values:

• y, yes, on, true or no value: force-enable frame pointers.
• n, no, off or false: do not force-enable frame pointers. This does not necessarily mean frame pointers will be removed.

The default behaviour, if frame pointers are not force-enabled, depends on the target.

force-unwind-tables

This flag forces the generation of unwind tables. It takes one of the following values:

• y, yes, on, true or no value: Unwind tables are forced to be generated.
• n, no, off or false: Unwind tables are not forced to be generated. If unwind tables are required by the target an error will be emitted.

The default if not specified depends on the target.

incremental

This flag allows you to enable incremental compilation, which allows rustc to save information after compiling a crate to be reused when recompiling the crate, improving re-compile times. This takes a path to a directory where incremental files will be stored.

inline-threshold

This option is deprecated and does nothing.

Consider using -Cllvm-args=--inline-threshold=....

instrument-coverage

This option enables instrumentation-based code coverage support. See the chapter on instrumentation-based code coverage for more information.

Note that while the -C instrument-coverage option is stable, the profile data format produced by the resulting instrumentation may change, and may not work with coverage tools other than those built and shipped with the compiler.

link-arg

This flag lets you append a single extra argument to the linker invocation.

"Append" is significant; you can pass this flag multiple times to add multiple arguments.

link-args

This flag lets you append multiple extra arguments to the linker invocation. The options should be separated by spaces.

link-dead-code

This flag controls whether the linker will keep dead code. It takes one of the following values:

• y, yes, on, true or no value: keep dead code.
• n, no, off or false: remove dead code (the default).

An example of when this flag might be useful is when trying to construct code coverage metrics.

link-self-contained

On windows-gnu, linux-musl, and wasi targets, this flag controls whether the linker will use libraries and objects shipped with Rust instead of those in the system. It takes one of the following values:

• no value: rustc will use heuristic to disable self-contained mode if system has necessary tools.
• y, yes, on, true: use only libraries/objects shipped with Rust.
• n, no, off or false: rely on the user or the linker to provide non-Rust libraries/objects.

This allows overriding cases when detection fails or user wants to use shipped libraries.

linker

This flag controls which linker rustc invokes to link your code. It takes a path to the linker executable. If this flag is not specified, the linker will be inferred based on the target. See also the linker-flavor flag for another way to specify the linker.

linker-flavor

This flag controls the linker flavor used by rustc. If a linker is given with the -C linker flag, then the linker flavor is inferred from the value provided. If no linker is given then the linker flavor is used to determine the linker to use. Every rustc target defaults to some linker flavor. Valid options are:

• em: use Emscripten emcc.
• gcc: use the cc executable, which is typically gcc or clang on many systems.
• ld: use the ld executable.
• msvc: use the link.exe executable from Microsoft Visual Studio MSVC.
• wasm-ld: use the wasm-ld executable, a port of LLVM lld for WebAssembly.
• ld64.lld: use the LLVM lld executable with the -flavor darwin flag for Apple's ld.
• ld.lld: use the LLVM lld executable with the -flavor gnu flag for GNU binutils' ld.
• lld-link: use the LLVM lld executable with the -flavor link flag for Microsoft's link.exe.

linker-plugin-lto

This flag defers LTO optimizations to the linker. See linker-plugin-LTO for more details. It takes one of the following values:

• y, yes, on, true or no value: enable linker plugin LTO.
• n, no, off or false: disable linker plugin LTO (the default).
• A path to the linker plugin.

More specifically this flag will cause the compiler to replace its typical object file output with LLVM bitcode files. For example an rlib produced with -Clinker-plugin-lto will still have *.o files in it, but they'll all be LLVM bitcode instead of actual machine code. It is expected that the native platform linker is capable of loading these LLVM bitcode files and generating code at link time (typically after performing optimizations).

Note that rustc can also read its own object files produced with -Clinker-plugin-lto. If an rlib is only ever going to get used later with a -Clto compilation then you can pass -Clinker-plugin-lto to speed up compilation and avoid generating object files that aren't used.

llvm-args

This flag can be used to pass a list of arguments directly to LLVM.

The list must be separated by spaces.

Pass --help to see a list of options.

lto

This flag controls whether LLVM uses link time optimizations to produce better optimized code, using whole-program analysis, at the cost of longer linking time. It takes one of the following values:

• y, yes, on, true, fat, or no value: perform "fat" LTO which attempts to perform optimizations across all crates within the dependency graph.
• n, no, off, false: disables LTO.
• thin: perform "thin" LTO. This is similar to "fat", but takes substantially less time to run while still achieving performance gains similar to "fat".

If -C lto is not specified, then the compiler will attempt to perform "thin local LTO" which performs "thin" LTO on the local crate only across its codegen units. When -C lto is not specified, LTO is disabled if codegen units is 1 or optimizations are disabled (-C opt-level=0). That is:

• When -C lto is not specified:
  • codegen-units=1: disable LTO.
  • opt-level=0: disable LTO.
• When -C lto is specified:
  • lto: 16 codegen units, perform fat LTO across crates.
  • codegen-units=1 + lto: 1 codegen unit, fat LTO across crates.

See also linker-plugin-lto for cross-language LTO.

metadata

This option allows you to control the metadata used for symbol mangling. This takes a space-separated list of strings. Mangled symbols will incorporate a hash of the metadata. This may be used, for example, to differentiate symbols between two different versions of the same crate being linked.

no-prepopulate-passes

This flag tells the pass manager to use an empty list of passes, instead of the usual pre-populated list of passes.

no-redzone

This flag allows you to disable the red zone. It takes one of the following values:

• y, yes, on, true or no value: disable the red zone.
• n, no, off or false: enable the red zone.

The default behaviour, if the flag is not specified, depends on the target.

no-stack-check

This option is deprecated and does nothing.

no-vectorize-loops

This flag disables loop vectorization.

no-vectorize-slp

This flag disables vectorization using superword-level parallelism.

opt-level

This flag controls the optimization level.

• 0: no optimizations, also turns on cfg(debug_assertions) (the default).
• 1: basic optimizations.
• 2: some optimizations.
• 3: all optimizations.
• s: optimize for binary size.
• z: optimize for binary size, but also turn off loop vectorization.

Note: The -O flag is an alias for -C opt-level=2.

The default is 0.

overflow-checks

This flag allows you to control the behavior of runtime integer overflow. When overflow-checks are enabled, a panic will occur on overflow. This flag takes one of the following values:

• y, yes, on, true or no value: enable overflow checks.
• n, no, off or false: disable overflow checks.

If not specified, overflow checks are enabled if debug-assertions are enabled, disabled otherwise.

panic

This option lets you control what happens when the code panics.

• abort: terminate the process upon panic
• unwind: unwind the stack upon panic

If not specified, the default depends on the target.

passes

This flag can be used to add extra LLVM passes to the compilation.

The list must be separated by spaces.

See also the no-prepopulate-passes flag.

prefer-dynamic

By default, rustc prefers to statically link dependencies. This option will indicate that dynamic linking should be used if possible if both a static and dynamic versions of a library are available.

There is an internal algorithm for determining whether or not it is possible to statically or dynamically link with a dependency.

This flag takes one of the following values:

• y, yes, on, true or no value: prefer dynamic linking.
• n, no, off or false: prefer static linking (the default).

profile-generate

This flag allows for creating instrumented binaries that will collect profiling data for use with profile-guided optimization (PGO). The flag takes an optional argument which is the path to a directory into which the instrumented binary will emit the collected data. See the chapter on profile-guided optimization for more information.

profile-use

This flag specifies the profiling data file to be used for profile-guided optimization (PGO). The flag takes a mandatory argument which is the path to a valid .profdata file. See the chapter on profile-guided optimization for more information.

relocation-model

This option controls generation of position-independent code (PIC).

Supported values for this option are:

Primary relocation models

• static - non-relocatable code, machine instructions may use absolute addressing modes.

• pic - fully relocatable position independent code, machine instructions need to use relative addressing modes.
  Equivalent to the "uppercase" -fPIC or -fPIE options in other compilers, depending on the produced crate types.
  This is the default model for majority of supported targets.

• pie - position independent executable, relocatable code but without support for symbol interpositioning (replacing symbols by name using LD_PRELOAD and similar). Equivalent to the "uppercase" -fPIE option in other compilers. pie code cannot be linked into shared libraries (you'll get a linking error on attempt to do this).

Special relocation models

• dynamic-no-pic - relocatable external references, non-relocatable code.
  Only makes sense on Darwin and is rarely used.
  If StackOverflow tells you to use this as an opt-out of PIC or PIE, don't believe it, use -C relocation-model=static instead.
• ropi, rwpi and ropi-rwpi - relocatable code and read-only data, relocatable read-write data, and combination of both, respectively.
  Only makes sense for certain embedded ARM targets.
• default - relocation model default to the current target.
  Only makes sense as an override for some other explicitly specified relocation model previously set on the command line.

Supported values can also be discovered by running rustc --print relocation-models.

Linking effects

In addition to codegen effects, relocation-model has effects during linking.

If the relocation model is pic and the current target supports position-independent executables (PIE), the linker will be instructed (-pie) to produce one.
If the target doesn't support both position-independent and statically linked executables, then -C target-feature=+crt-static "wins" over -C relocation-model=pic, and the linker is instructed (-static) to produce a statically linked but not position-independent executable.

relro-level

This flag controls what level of RELRO (Relocation Read-Only) is enabled. RELRO is an exploit mitigation which makes the Global Offset Table (GOT) read-only.

Supported values for this option are:

• off: Dynamically linked functions are resolved lazily and the GOT is writable.
• partial: Dynamically linked functions are resolved lazily and written into the Procedure Linking Table (PLT) part of the GOT (.got.plt). The non-PLT part of the GOT (.got) is made read-only and both are moved to prevent writing from buffer overflows.
• full: Dynamically linked functions are resolved at the start of program execution and the Global Offset Table (.got/.got.plt) is populated eagerly and then made read-only. The GOT is also moved to prevent writing from buffer overflows. Full RELRO uses more memory and increases process startup time.

This flag is ignored on platforms where RELRO is not supported (targets which do not use the ELF binary format), such as Windows or macOS. Each rustc target has its own default for RELRO. rustc enables Full RELRO by default on platforms where it is supported.

remark

This flag lets you print remarks for optimization passes.

The list of passes should be separated by spaces.

all will remark on every pass.

rpath

This flag controls whether rpath is enabled. It takes one of the following values:

• y, yes, on, true or no value: enable rpath.
• n, no, off or false: disable rpath (the default).

save-temps

This flag controls whether temporary files generated during compilation are deleted once compilation finishes. It takes one of the following values:

• y, yes, on, true or no value: save temporary files.
• n, no, off or false: delete temporary files (the default).

soft-float

This option controls whether rustc generates code that emulates floating point instructions in software. It takes one of the following values:

• y, yes, on, true or no value: use soft floats.
• n, no, off or false: use hardware floats (the default).

split-debuginfo

This option controls the emission of "split debuginfo" for debug information that rustc generates. The default behavior of this option is platform-specific, and not all possible values for this option work on all platforms. Possible values are:

• off - This is the default for platforms with ELF binaries and windows-gnu (not Windows MSVC and not macOS). This typically means that DWARF debug information can be found in the final artifact in sections of the executable. This option is not supported on Windows MSVC. On macOS this options prevents the final execution of dsymutil to generate debuginfo.

• packed - This is the default for Windows MSVC and macOS. The term "packed" here means that all the debug information is packed into a separate file from the main executable. On Windows MSVC this is a *.pdb file, on macOS this is a *.dSYM folder, and on other platforms this is a *.dwp file.

• unpacked - This means that debug information will be found in separate files for each compilation unit (object file). This is not supported on Windows MSVC. On macOS this means the original object files will contain debug information. On other Unix platforms this means that *.dwo files will contain debug information.

Note that all three options are supported on Linux and Apple platforms, packed is supported on Windows-MSVC, and all other platforms support off. Attempting to use an unsupported option requires using the nightly channel with the -Z unstable-options flag.

strip

The option -C strip=val controls stripping of debuginfo and similar auxiliary data from binaries during linking.

Supported values for this option are:

• none - debuginfo and symbols are not modified.
• debuginfo - debuginfo sections and debuginfo symbols from the symbol table section are stripped at link time and are not copied to the produced binary. This should leave backtraces mostly-intact but may make using a debugger like gdb or lldb ineffectual. Prior to 1.79, this unintentionally disabled the generation of *.pdb files on MSVC, resulting in the absence of symbols.
• symbols - same as debuginfo, but the rest of the symbol table section is stripped as well, depending on platform support. On platforms which depend on this symbol table for backtraces, profiling, and similar, this can affect them so negatively as to make the trace incomprehensible. Programs which may be combined with others, such as CLI pipelines and developer tooling, or even anything which wants crash-reporting, should usually avoid -Cstrip=symbols.

Note that, at any level, removing debuginfo only necessarily impacts "friendly" introspection. -Cstrip cannot be relied on as a meaningful security or obfuscation measure, as disassemblers and decompilers can extract considerable information even in the absence of symbols.

symbol-mangling-version

This option controls the name mangling format for encoding Rust item names for the purpose of generating object code and linking.

Supported values for this option are:

• v0 — The "v0" mangling scheme.

The default, if not specified, will use a compiler-chosen default which may change in the future.

See the Symbol Mangling chapter for details on symbol mangling and the mangling format.

target-cpu

This instructs rustc to generate code specifically for a particular processor.

You can run rustc --print target-cpus to see the valid options to pass and the default target CPU for the current build target. Each target has a default base CPU. Special values include:

• native can be passed to use the processor of the host machine.
• generic refers to an LLVM target with minimal features but modern tuning.

target-feature

Individual targets will support different features; this flag lets you control enabling or disabling a feature. Each feature should be prefixed with a + to enable it or - to disable it.

Features from multiple -C target-feature options are combined.
Multiple features can be specified in a single option by separating them with commas - -C target-feature=+x,-y.
If some feature is specified more than once with both + and -, then values passed later override values passed earlier.
For example, -C target-feature=+x,-y,+z -Ctarget-feature=-x,+y is equivalent to -C target-feature=-x,+y,+z.

To see the valid options and an example of use, run rustc --print target-features.

Using this flag is unsafe and might result in undefined runtime behavior.

See also the target_feature attribute for controlling features per-function.

This also supports the feature +crt-static and -crt-static to control static C runtime linkage.

Each target and target-cpu has a default set of enabled features.

tune-cpu

This instructs rustc to schedule code specifically for a particular processor. This does not affect the compatibility (instruction sets or ABI), but should make your code slightly more efficient on the selected CPU.

The valid options are the same as those for target-cpu. The default is None, which LLVM translates as the target-cpu.

This is an unstable option. Use -Z tune-cpu=machine to specify a value.

Due to limitations in LLVM (12.0.0-git9218f92), this option is currently effective only for x86 targets.

Jobserver

Internally, rustc may take advantage of parallelism. rustc will coordinate with the build system calling it if a GNU Make jobserver is passed in the MAKEFLAGS environment variable. Other flags may have an effect as well, such as CARGO_MAKEFLAGS. If a jobserver is not passed, then rustc will choose the number of jobs to use.

Starting with Rust 1.76.0, rustc will warn if a jobserver appears to be available but is not accessible, e.g.:

$ echo 'fn main() {}' | MAKEFLAGS=--jobserver-auth=3,4 rustc -
warning: failed to connect to jobserver from environment variable `MAKEFLAGS="--jobserver-auth=3,4"`: cannot open file descriptor 3 from the jobserver environment variable value: Bad file descriptor (os error 9)
  |
  = note: the build environment is likely misconfigured

Integration with build systems

The following subsections contain recommendations on how to integrate rustc with build systems so that the jobserver is handled appropriately.

GNU Make

When calling rustc from GNU Make, it is recommended that all rustc invocations are marked as recursive in the Makefile (by prefixing the command line with the + indicator), so that GNU Make enables the jobserver for them. For instance:

x:
	+@echo 'fn main() {}' | rustc -

In particular, GNU Make 4.3 (a widely used version as of 2024) passes a simple pipe jobserver in MAKEFLAGS even when it was not made available for the child process, which in turn means rustc will warn about it. For instance, if the + indicator is removed from the example above and GNU Make is called with e.g. make -j2, then the aforementioned warning will trigger.

For calls to rustc inside $(shell ...) inside a recursive Make, one can disable the jobserver manually by clearing the MAKEFLAGS variable, e.g.:

S := $(shell MAKEFLAGS= rustc --print sysroot)

x:
	@$(MAKE) y

y:
	@echo $(S)

CMake

CMake 3.28 supports the JOB_SERVER_AWARE option in its add_custom_target command, e.g.:

cmake_minimum_required(VERSION 3.28)
project(x)
add_custom_target(x
    JOB_SERVER_AWARE TRUE
    COMMAND echo 'fn main() {}' | rustc -
)

For earlier versions, when using CMake with the Makefile generator, one workaround is to have $(MAKE) somewhere in the command so that GNU Make treats it as a recursive Make call, e.g.:

cmake_minimum_required(VERSION 3.22)
project(x)
add_custom_target(x
    COMMAND DUMMY_VARIABLE=$(MAKE) echo 'fn main() {}' | rustc -
)

Lints

In software, a "lint" is a tool used to help improve your source code. The Rust compiler contains a number of lints, and when it compiles your code, it will also run the lints. These lints may produce a warning, an error, or nothing at all, depending on how you've configured things.

Here's a small example:

$ cat main.rs
fn main() {
    let x = 5;
}
$ rustc main.rs
warning: unused variable: `x`
 --> main.rs:2:9
  |
2 |     let x = 5;
  |         ^
  |
  = note: `#[warn(unused_variables)]` on by default
  = note: to avoid this warning, consider using `_x` instead

This is the unused_variables lint, and it tells you that you've introduced a variable that you don't use in your code. That's not wrong, so it's not an error, but it might be a bug, so you get a warning.

Future-incompatible lints

Sometimes the compiler needs to be changed to fix an issue that can cause existing code to stop compiling. "Future-incompatible" lints are issued in these cases to give users of Rust a smooth transition to the new behavior. Initially, the compiler will continue to accept the problematic code and issue a warning. The warning has a description of the problem, a notice that this will become an error in the future, and a link to a tracking issue that provides detailed information and an opportunity for feedback. This gives users some time to fix the code to accommodate the change. After some time, the warning may become an error.

The following is an example of what a future-incompatible looks like:

warning: borrow of packed field is unsafe and requires unsafe function or block (error E0133)
  --> lint_example.rs:11:13
   |
11 |     let y = &x.data.0;
   |             ^^^^^^^^^
   |
   = note: `#[warn(safe_packed_borrows)]` on by default
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #46043 <https://github.com/rust-lang/rust/issues/46043>
   = note: fields of packed structs might be misaligned: dereferencing a misaligned pointer or even just creating a misaligned reference is undefined behavior

For more information about the process and policy of future-incompatible changes, see RFC 1589.

Lint Levels

In rustc, lints are divided into six levels:

1. allow
2. expect
3. warn
4. force-warn
5. deny
6. forbid

Each lint has a default level (explained in the lint listing later in this chapter), and the compiler has a default warning level. First, let's explain what these levels mean, and then we'll talk about configuration.

allow

These lints exist, but by default, do nothing. For example, consider this source:

pub fn foo() {}

Compiling this file produces no warnings:

$ rustc lib.rs --crate-type=lib
$

But this code violates the missing_docs lint.

These lints exist mostly to be manually turned on via configuration, as we'll talk about later in this section.

expect

Sometimes, it can be helpful to suppress lints, but at the same time ensure that the code in question still emits them. The 'expect' level does exactly this. If the lint in question is not emitted, the unfulfilled_lint_expectation lint triggers on the expect attribute, notifying you that the expectation is no longer fulfilled.

fn main() {
    #[expect(unused_variables)]
    let unused = "Everyone ignores me";

    #[expect(unused_variables)] // `unused_variables` lint is not emitted
    let used = "I'm useful";    // the expectation is therefore unfulfilled
    println!("The `used` value is equal to: {:?}", used);
}

This will produce the following warning:

warning: this lint expectation is unfulfilled
 --> src/main.rs:7:14
  |
7 |     #[expect(unused_variables)]
  |              ^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unfulfilled_lint_expectations)]` on by default

This level can only be defined via the #[expect] attribute, there is no equivalent flag. Lints with the special 'force-warn' level will still be emitted as usual.

warn

The 'warn' lint level will produce a warning if you violate the lint. For example, this code runs afoul of the unused_variables lint:

pub fn foo() {
    let x = 5;
}

This will produce this warning:

$ rustc lib.rs --crate-type=lib
warning: unused variable: `x`
 --> lib.rs:2:9
  |
2 |     let x = 5;
  |         ^
  |
  = note: `#[warn(unused_variables)]` on by default
  = note: to avoid this warning, consider using `_x` instead

force-warn

'force-warn' is a special lint level. It's the same as 'warn' in that a lint at this level will produce a warning, but unlike the 'warn' level, the 'force-warn' level cannot be overridden. If a lint is set to 'force-warn', it is guaranteed to warn: no more, no less. This is true even if the overall lint level is capped via cap-lints.

deny

A 'deny' lint produces an error if you violate it. For example, this code runs into the exceeding_bitshifts lint.

fn main() {
    100u8 << 10;
}

$ rustc main.rs
error: bitshift exceeds the type's number of bits
 --> main.rs:2:13
  |
2 |     100u8 << 10;
  |     ^^^^^^^^^^^
  |
  = note: `#[deny(exceeding_bitshifts)]` on by default

What's the difference between an error from a lint and a regular old error? Lints are configurable via levels, so in a similar way to 'allow' lints, warnings that are 'deny' by default let you allow them. Similarly, you may wish to set up a lint that is warn by default to produce an error instead. This lint level gives you that.

forbid

'forbid' is a special lint level that fills the same role for 'deny' that 'force-warn' does for 'warn'. It's the same as 'deny' in that a lint at this level will produce an error, but unlike the 'deny' level, the 'forbid' level can not be overridden to be anything lower than an error. However, lint levels may still be capped with --cap-lints (see below) so rustc --cap-lints warn will make lints set to 'forbid' just warn.

Configuring warning levels

Remember our missing_docs example from the 'allow' lint level?

$ cat lib.rs
pub fn foo() {}
$ rustc lib.rs --crate-type=lib
$

We can configure this lint to operate at a higher level, both with compiler flags, as well as with an attribute in the source code.

You can also "cap" lints so that the compiler can choose to ignore certain lint levels. We'll talk about that last.

Via compiler flag

The -A, -W, --force-warn -D, and -F flags let you turn one or more lints into allowed, warning, force-warn, deny, or forbid levels, like this:

$ rustc lib.rs --crate-type=lib -W missing-docs
warning: missing documentation for crate
 --> lib.rs:1:1
  |
1 | pub fn foo() {}
  | ^^^^^^^^^^^^
  |
  = note: requested on the command line with `-W missing-docs`

warning: missing documentation for a function
 --> lib.rs:1:1
  |
1 | pub fn foo() {}
  | ^^^^^^^^^^^^

$ rustc lib.rs --crate-type=lib -D missing-docs
error: missing documentation for crate
 --> lib.rs:1:1
  |
1 | pub fn foo() {}
  | ^^^^^^^^^^^^
  |
  = note: requested on the command line with `-D missing-docs`

error: missing documentation for a function
 --> lib.rs:1:1
  |
1 | pub fn foo() {}
  | ^^^^^^^^^^^^

error: aborting due to 2 previous errors

You can also pass each flag more than once for changing multiple lints:

$ rustc lib.rs --crate-type=lib -D missing-docs -D unused-variables

And of course, you can mix these five flags together:

$ rustc lib.rs --crate-type=lib -D missing-docs -A unused-variables

The order of these command line arguments is taken into account. The following allows the unused-variables lint, because it is the last argument for that lint:

$ rustc lib.rs --crate-type=lib -D unused-variables -A unused-variables

You can make use of this behavior by overriding the level of one specific lint out of a group of lints. The following example denies all the lints in the unused group, but explicitly allows the unused-variables lint in that group (forbid still trumps everything regardless of ordering):

$ rustc lib.rs --crate-type=lib -D unused -A unused-variables

Since force-warn and forbid cannot be overridden, setting one of them will prevent any later level for the same lint from taking effect.

Via an attribute

You can also modify the lint level with a crate-wide attribute:

$ cat lib.rs
#![warn(missing_docs)]

pub fn foo() {}
$ rustc lib.rs --crate-type=lib
warning: missing documentation for crate
 --> lib.rs:1:1
  |
1 | / #![warn(missing_docs)]
2 | |
3 | | pub fn foo() {}
  | |_______________^
  |
note: lint level defined here
 --> lib.rs:1:9
  |
1 | #![warn(missing_docs)]
  |         ^^^^^^^^^^^^

warning: missing documentation for a function
 --> lib.rs:3:1
  |
3 | pub fn foo() {}
  | ^^^^^^^^^^^^

warn, allow, deny, and forbid all work this way. There is no way to set a lint to force-warn using an attribute.

You can also pass in multiple lints per attribute:

#![warn(missing_docs, unused_variables)]

pub fn foo() {}

And use multiple attributes together:

#![warn(missing_docs)]
#![deny(unused_variables)]

pub fn foo() {}

All lint attributes support an additional reason parameter, to give context why a certain attribute was added. This reason will be displayed as part of the lint message, if the lint is emitted at the defined level.

use std::path::PathBuf;
pub fn get_path() -> PathBuf {
    #[allow(unused_mut, reason = "this is only modified on some platforms")]
    let mut file_name = PathBuf::from("git");
    #[cfg(target_os = "windows")]
    file_name.set_extension("exe");
    file_name
}

Capping lints

rustc supports a flag, --cap-lints LEVEL that sets the "lint cap level." This is the maximum level for all lints. So for example, if we take our code sample from the "deny" lint level above:

fn main() {
    100u8 << 10;
}

And we compile it, capping lints to warn:

$ rustc lib.rs --cap-lints warn
warning: bitshift exceeds the type's number of bits
 --> lib.rs:2:5
  |
2 |     100u8 << 10;
  |     ^^^^^^^^^^^
  |
  = note: `#[warn(exceeding_bitshifts)]` on by default

warning: this expression will panic at run-time
 --> lib.rs:2:5
  |
2 |     100u8 << 10;
  |     ^^^^^^^^^^^ attempt to shift left with overflow

It now only warns, rather than errors. We can go further and allow all lints:

$ rustc lib.rs --cap-lints allow
$

This feature is used heavily by Cargo; it will pass --cap-lints allow when compiling your dependencies, so that if they have any warnings, they do not pollute the output of your build.

Lint Groups

rustc has the concept of a "lint group", where you can toggle several warnings through one name.

For example, the nonstandard-style lint sets non-camel-case-types, non-snake-case, and non-upper-case-globals all at once. So these are equivalent:

$ rustc -D nonstandard-style
$ rustc -D non-camel-case-types -D non-snake-case -D non-upper-case-globals

Here's a list of each lint group, and the lints that they are made up of:

Additionally, there's a bad-style lint group that's a deprecated alias for nonstandard-style.

Finally, you can also see the table above by invoking rustc -W help. This will give you the exact values for the specific compiler you have installed.

Lint Listing

This section lists out all of the lints, grouped by their default lint levels.

You can also see this list by running rustc -W help.

Allowed-by-default Lints

These lints are all set to the 'allow' level by default. As such, they won't show up unless you set them to a higher lint level with a flag or attribute.

• absolute_paths_not_starting_with_crate
• ambiguous_negative_literals
• async-idents
• closure_returning_async_block
• deprecated_safe_2024
• disjoint-capture-migration
• edition_2024_expr_fragment_specifier
• elided-lifetime-in-path
• elided_lifetimes_in_paths
• explicit_outlives_requirements
• ffi_unwind_calls
• fuzzy_provenance_casts
• if_let_rescope
• impl_trait_overcaptures
• keyword-idents
• keyword_idents_2018
• keyword_idents_2024
• let_underscore_drop
• lossy_provenance_casts
• macro_use_extern_crate
• meta_variable_misuse
• missing_abi
• missing_copy_implementations
• missing_debug_implementations
• missing_docs
• missing_unsafe_on_extern
• multiple_supertrait_upcastable
• must_not_suspend
• non_ascii_idents
• non_exhaustive_omitted_patterns
• or-patterns-back-compat
• redundant_imports
• redundant_lifetimes
• rust_2021_incompatible_closure_captures
• rust_2021_incompatible_or_patterns
• rust_2021_prefixes_incompatible_syntax
• rust_2021_prelude_collisions
• rust_2024_guarded_string_incompatible_syntax
• rust_2024_incompatible_pat
• rust_2024_prelude_collisions
• single-use-lifetime
• single_use_lifetimes
• tail_expr_drop_order
• trivial_casts
• trivial_numeric_casts
• unit_bindings
• unnameable_types
• unqualified_local_imports
• unreachable_pub
• unsafe_attr_outside_unsafe
• unsafe_code
• unsafe_op_in_unsafe_fn
• unstable_features
• unused_crate_dependencies
• unused_extern_crates
• unused_import_braces
• unused_lifetimes
• unused_macro_rules
• unused_qualifications
• unused_results
• variant_size_differences

absolute-paths-not-starting-with-crate

The absolute_paths_not_starting_with_crate lint detects fully qualified paths that start with a module name instead of crate, self, or an extern crate name

Example

#![deny(absolute_paths_not_starting_with_crate)]

mod foo {
    pub fn bar() {}
}

fn main() {
    ::foo::bar();
}

This will produce:

error: absolute paths must start with `self`, `super`, `crate`, or an external crate name in the 2018 edition
 --> lint_example.rs:8:5
  |
8 |     ::foo::bar();
  |     ^^^^^^^^^^ help: use `crate`: `crate::foo::bar`
  |
  = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018!
  = note: for more information, see issue #53130 <https://github.com/rust-lang/rust/issues/53130>
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(absolute_paths_not_starting_with_crate)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

Rust editions allow the language to evolve without breaking backwards compatibility. This lint catches code that uses absolute paths in the style of the 2015 edition. In the 2015 edition, absolute paths (those starting with ::) refer to either the crate root or an external crate. In the 2018 edition it was changed so that they only refer to external crates. The path prefix crate:: should be used instead to reference items from the crate root.

If you switch the compiler from the 2015 to 2018 edition without updating the code, then it will fail to compile if the old style paths are used. You can manually change the paths to use the crate:: prefix to transition to the 2018 edition.

This lint solves the problem automatically. It is "allow" by default because the code is perfectly valid in the 2015 edition. The cargo fix tool with the --edition flag will switch this lint to "warn" and automatically apply the suggested fix from the compiler. This provides a completely automated way to update old code to the 2018 edition.

ambiguous-negative-literals

The ambiguous_negative_literals lint checks for cases that are confusing between a negative literal and a negation that's not part of the literal.

Example

#![deny(ambiguous_negative_literals)]
#![allow(unused)]
-1i32.abs(); // equals -1, while `(-1i32).abs()` equals 1

This will produce:

error: `-` has lower precedence than method calls, which might be unexpected
 --> lint_example.rs:4:1
  |
4 | -1i32.abs(); // equals -1, while `(-1i32).abs()` equals 1
  | ^^^^^^^^^^^
  |
  = note: e.g. `-4.abs()` equals `-4`; while `(-4).abs()` equals `4`
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(ambiguous_negative_literals)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: add parentheses around the `-` and the literal to call the method on a negative literal
  |
4 | (-1i32).abs(); // equals -1, while `(-1i32).abs()` equals 1
  | +     +
help: add parentheses around the literal and the method call to keep the current behavior
  |
4 | -(1i32.abs()); // equals -1, while `(-1i32).abs()` equals 1
  |  +          +

Explanation

Method calls take precedence over unary precedence. Setting the precedence explicitly makes the code clearer and avoid potential bugs.

async-idents

The lint async-idents has been renamed to keyword-idents.

closure-returning-async-block

The closure_returning_async_block lint detects cases where users write a closure that returns an async block.

Example

#![feature(async_closure)]
#![warn(closure_returning_async_block)]
let c = |x: &str| async {};

This will produce:

warning: closure returning async block can be made into an async closure
 --> lint_example.rs:4:9
  |
4 | let c = |x: &str| async {};
  |         ^^^^^^^^^ ----- this async block can be removed, and the closure can be turned into an async closure
  |
note: the lint level is defined here
 --> lint_example.rs:2:9
  |
2 | #![warn(closure_returning_async_block)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: turn this into an async closure
  |
4 - let c = |x: &str| async {};
4 + let c = async |x: &str| {};
  |

Explanation

Using an async closure is preferable over a closure that returns an async block, since async closures are less restrictive in how its captures are allowed to be used.

For example, this code does not work with a closure returning an async block:

async fn callback(x: &str) {}

let captured_str = String::new();
let c = move || async {
    callback(&captured_str).await;
};

But it does work with async closures:

#![feature(async_closure)]

async fn callback(x: &str) {}

let captured_str = String::new();
let c = async move || {
    callback(&captured_str).await;
};

deprecated-safe-2024

The deprecated_safe_2024 lint detects unsafe functions being used as safe functions.

Example

#![deny(deprecated_safe)]
// edition 2021
use std::env;
fn enable_backtrace() {
    env::set_var("RUST_BACKTRACE", "1");
}

This will produce:

error: call to deprecated safe function `std::env::set_var` is unsafe and requires unsafe block
 --> lint_example.rs:6:5
  |
6 |     env::set_var("RUST_BACKTRACE", "1");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
  |
  = warning: this is accepted in the current edition (Rust 2021) but is a hard error in Rust 2024!
  = note: for more information, see issue #27970 <https://github.com/rust-lang/rust/issues/27970>
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(deprecated_safe)]
  |         ^^^^^^^^^^^^^^^
  = note: `#[deny(deprecated_safe_2024)]` implied by `#[deny(deprecated_safe)]`
help: you can wrap the call in an `unsafe` block if you can guarantee that the environment access only happens in single-threaded code
  |
6 +     // TODO: Audit that the environment access only happens in single-threaded code.
7 ~     unsafe { env::set_var("RUST_BACKTRACE", "1") };
  |

Explanation

Rust editions allow the language to evolve without breaking backward compatibility. This lint catches code that uses unsafe functions that were declared as safe (non-unsafe) in editions prior to Rust 2024. If you switch the compiler to Rust 2024 without updating the code, then it will fail to compile if you are using a function previously marked as safe.

You can audit the code to see if it suffices the preconditions of the unsafe code, and if it does, you can wrap it in an unsafe block. If you can't fulfill the preconditions, you probably need to switch to a different way of doing what you want to achieve.

This lint can automatically wrap the calls in unsafe blocks, but this obviously cannot verify that the preconditions of the unsafe functions are fulfilled, so that is still up to the user.

The lint is currently "allow" by default, but that might change in the future.

disjoint-capture-migration

The lint disjoint-capture-migration has been renamed to rust-2021-incompatible-closure-captures.

edition-2024-expr-fragment-specifier

The edition_2024_expr_fragment_specifier lint detects the use of expr fragments in macros during migration to the 2024 edition.

The expr fragment specifier will accept more expressions in the 2024 edition. To maintain the behavior from the 2021 edition and earlier, use the expr_2021 fragment specifier.

Example

#![deny(edition_2024_expr_fragment_specifier)]
macro_rules! m {
  ($e:expr) => {
      $e
  }
}

fn main() {
   m!(1);
}

This will produce:

error: the `expr` fragment specifier will accept more expressions in the 2024 edition
 --> lint_example.rs:3:7
  |
3 |   ($e:expr) => {
  |       ^^^^
  |
  = warning: this changes meaning in Rust 2024
  = note: for more information, see Migration Guide <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/macro-fragment-specifiers.html>
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(edition_2024_expr_fragment_specifier)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: to keep the existing behavior, use the `expr_2021` fragment specifier
  |
3 |   ($e:expr_2021) => {
  |       ~~~~~~~~~

Explanation

Rust editions allow the language to evolve without breaking backwards compatibility. This lint catches code that uses macro matcher fragment specifiers that have changed meaning in the 2024 edition. If you switch to the new edition without updating the code, your macros may behave differently.

In the 2024 edition, the expr fragment specifier expr will also match const { ... } blocks. This means if a macro had a pattern that matched $e:expr and another that matches const { $e: expr }, for example, that under the 2024 edition the first pattern would match while in the 2021 and earlier editions the second pattern would match. To keep the old behavior, use the expr_2021 fragment specifier.

This lint detects macros whose behavior might change due to the changing meaning of the expr fragment specifier. It is "allow" by default because the code is perfectly valid in older editions. The cargo fix tool with the --edition flag will switch this lint to "warn" and automatically apply the suggested fix from the compiler. This provides a completely automated way to update old code for a new edition.

Using cargo fix --edition with this lint will ensure that your code retains the same behavior. This may not be the desired, as macro authors often will want their macros to use the latest grammar for matching expressions. Be sure to carefully review changes introduced by this lint to ensure the macros implement the desired behavior.

elided-lifetime-in-path

The lint elided-lifetime-in-path has been renamed to elided-lifetimes-in-paths.

elided-lifetimes-in-paths

The elided_lifetimes_in_paths lint detects the use of hidden lifetime parameters.

Example

#![deny(elided_lifetimes_in_paths)]
#![deny(warnings)]
struct Foo<'a> {
    x: &'a u32
}

fn foo(x: &Foo) {
}

This will produce:

error: hidden lifetime parameters in types are deprecated
 --> lint_example.rs:8:12
  |
8 | fn foo(x: &Foo) {
  |            ^^^ expected lifetime parameter
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(elided_lifetimes_in_paths)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^
help: indicate the anonymous lifetime
  |
8 | fn foo(x: &Foo<'_>) {
  |               ++++

Explanation

Elided lifetime parameters can make it difficult to see at a glance that borrowing is occurring. This lint ensures that lifetime parameters are always explicitly stated, even if it is the '_ placeholder lifetime.

This lint is "allow" by default because it has some known issues, and may require a significant transition for old code.

explicit-outlives-requirements

The explicit_outlives_requirements lint detects unnecessary lifetime bounds that can be inferred.

Example

#![allow(unused)]
#![deny(explicit_outlives_requirements)]
#![deny(warnings)]

struct SharedRef<'a, T>
where
    T: 'a,
{
    data: &'a T,
}

This will produce:

error: outlives requirements can be inferred
 --> lint_example.rs:6:24
  |
6 |   struct SharedRef<'a, T>
  |  ________________________^
7 | | where
8 | |     T: 'a,
  | |__________^ help: remove this bound
  |
note: the lint level is defined here
 --> lint_example.rs:2:9
  |
2 | #![deny(explicit_outlives_requirements)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

If a struct contains a reference, such as &'a T, the compiler requires that T outlives the lifetime 'a. This historically required writing an explicit lifetime bound to indicate this requirement. However, this can be overly explicit, causing clutter and unnecessary complexity. The language was changed to automatically infer the bound if it is not specified. Specifically, if the struct contains a reference, directly or indirectly, to T with lifetime 'x, then it will infer that T: 'x is a requirement.

This lint is "allow" by default because it can be noisy for existing code that already had these requirements. This is a stylistic choice, as it is still valid to explicitly state the bound. It also has some false positives that can cause confusion.

See RFC 2093 for more details.

ffi-unwind-calls

The ffi_unwind_calls lint detects calls to foreign functions or function pointers with C-unwind or other FFI-unwind ABIs.

Example

#![warn(ffi_unwind_calls)]

extern "C-unwind" {
    fn foo();
}

fn bar() {
    unsafe { foo(); }
    let ptr: unsafe extern "C-unwind" fn() = foo;
    unsafe { ptr(); }
}

This will produce:

warning: call to foreign function with FFI-unwind ABI
 --> lint_example.rs:9:14
  |
9 |     unsafe { foo(); }
  |              ^^^^^ call to foreign function with FFI-unwind ABI
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![warn(ffi_unwind_calls)]
  |         ^^^^^^^^^^^^^^^^


warning: call to function pointer with FFI-unwind ABI
  --> lint_example.rs:11:14
   |
11 |     unsafe { ptr(); }
   |              ^^^^^ call to function pointer with FFI-unwind ABI

Explanation

For crates containing such calls, if they are compiled with -C panic=unwind then the produced library cannot be linked with crates compiled with -C panic=abort. For crates that desire this ability it is therefore necessary to avoid such calls.

fuzzy-provenance-casts

The fuzzy_provenance_casts lint detects an as cast between an integer and a pointer.

Example

#![warn(fuzzy_provenance_casts)]

fn main() {
    let _dangling = 16_usize as *const u8;
}

This will produce:

warning: unknown lint: `fuzzy_provenance_casts`
 --> lint_example.rs:1:1
  |
1 | #![warn(fuzzy_provenance_casts)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: the `fuzzy_provenance_casts` lint is unstable
  = note: see issue #130351 <https://github.com/rust-lang/rust/issues/130351> for more information
  = help: add `#![feature(strict_provenance_lints)]` to the crate attributes to enable
  = note: this compiler was built on 2024-11-10; consider upgrading it if it is out of date
  = note: `#[warn(unknown_lints)]` on by default

Explanation

This lint is part of the strict provenance effort, see issue #95228. Casting an integer to a pointer is considered bad style, as a pointer contains, besides the address also a provenance, indicating what memory the pointer is allowed to read/write. Casting an integer, which doesn't have provenance, to a pointer requires the compiler to assign (guess) provenance. The compiler assigns "all exposed valid" (see the docs of ptr::with_exposed_provenance for more information about this "exposing"). This penalizes the optimiser and is not well suited for dynamic analysis/dynamic program verification (e.g. Miri or CHERI platforms).

It is much better to use ptr::with_addr instead to specify the provenance you want. If using this function is not possible because the code relies on exposed provenance then there is as an escape hatch ptr::with_exposed_provenance.

if-let-rescope

The if_let_rescope lint detects cases where a temporary value with significant drop is generated on the right hand side of if let and suggests a rewrite into match when possible.

Example

#![warn(if_let_rescope)]
#![allow(unused_variables)]

struct Droppy;
impl Drop for Droppy {
    fn drop(&mut self) {
        // Custom destructor, including this `drop` implementation, is considered
        // significant.
        // Rust does not check whether this destructor emits side-effects that can
        // lead to observable change in program semantics, when the drop order changes.
        // Rust biases to be on the safe side, so that you can apply discretion whether
        // this change indeed breaches any contract or specification that your code needs
        // to honour.
        println!("dropped");
    }
}
impl Droppy {
    fn get(&self) -> Option<u8> {
        None
    }
}

fn main() {
    if let Some(value) = Droppy.get() {
        // do something
    } else {
        // do something else
    }
}

This will produce:

warning: `if let` assigns a shorter lifetime since Edition 2024
  --> lint_example.rs:24:8
   |
24 |     if let Some(value) = Droppy.get() {
   |        ^^^^^^^^^^^^^^^^^^------^^^^^^
   |                          |
   |                          this value has a significant drop implementation which may observe a major change in drop order and requires your discretion
   |
   = warning: this changes meaning in Rust 2024
   = note: for more information, see issue #124085 <https://github.com/rust-lang/rust/issues/124085>
help: the value is now dropped here in Edition 2024
  --> lint_example.rs:26:5
   |
26 |     } else {
   |     ^
note: the lint level is defined here
  --> lint_example.rs:1:9
   |
1  | #![warn(if_let_rescope)]
   |         ^^^^^^^^^^^^^^
help: a `match` with a single arm can preserve the drop order up to Edition 2021
   |
24 ~     match Droppy.get() { Some(value) => {
25 |         // do something
26 ~     } _ => {
27 |         // do something else
28 ~     }}
   |

Explanation

With Edition 2024, temporaries generated while evaluating if lets will be dropped before the else block. This lint captures a possible change in runtime behaviour due to a change in sequence of calls to significant Drop::drop destructors.

A significant Drop::drop destructor here refers to an explicit, arbitrary implementation of the Drop trait on the type with exceptions including Vec, Box, Rc, BTreeMap and HashMap that are marked by the compiler otherwise so long that the generic types have no significant destructor recursively. In other words, a type has a significant drop destructor when it has a Drop implementation or its destructor invokes a significant destructor on a type. Since we cannot completely reason about the change by just inspecting the existence of a significant destructor, this lint remains only a suggestion and is set to allow by default.

Whenever possible, a rewrite into an equivalent match expression that observe the same order of calls to such destructors is proposed by this lint. Authors may take their own discretion whether the rewrite suggestion shall be accepted, or rejected to continue the use of the if let expression.

impl-trait-overcaptures

The impl_trait_overcaptures lint warns against cases where lifetime capture behavior will differ in edition 2024.

In the 2024 edition, impl Traits will capture all lifetimes in scope, rather than just the lifetimes that are mentioned in the bounds of the type. Often these sets are equal, but if not, it means that the impl Trait may cause erroneous borrow-checker errors.

Example

#![deny(impl_trait_overcaptures)]
use std::fmt::Display;
let mut x = vec![];
x.push(1);

fn test(x: &Vec<i32>) -> impl Display {
    x[0]
}

let element = test(&x);
x.push(2);
println!("{element}");

This will produce:

error: `impl std::fmt::Display` will capture more lifetimes than possibly intended in edition 2024
 --> lint_example.rs:7:26
  |
7 | fn test(x: &Vec<i32>) -> impl Display {
  |                          ^^^^^^^^^^^^
  |
  = warning: this changes meaning in Rust 2024
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/rpit-lifetime-capture.html>
note: specifically, this lifetime is in scope but not mentioned in the type's bounds
 --> lint_example.rs:7:12
  |
7 | fn test(x: &Vec<i32>) -> impl Display {
  |            ^
  = note: all lifetimes in scope will be captured by `impl Trait`s in edition 2024
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(impl_trait_overcaptures)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^
help: use the precise capturing `use<...>` syntax to make the captures explicit
  |
7 | fn test(x: &Vec<i32>) -> impl Display + use<> {
  |                                       +++++++

Explanation

In edition < 2024, the returned impl Display doesn't capture the lifetime from the &Vec<i32>, so the vector can be mutably borrowed while the impl Display is live.

To fix this, we can explicitly state that the impl Display doesn't capture any lifetimes, using impl Display + use<>.

keyword-idents

The lint keyword-idents has been renamed to keyword-idents-2018.

keyword-idents-2018

The keyword_idents_2018 lint detects edition keywords being used as an identifier.

Example

#![deny(keyword_idents_2018)]
// edition 2015
fn dyn() {}

This will produce:

error: `dyn` is a keyword in the 2018 edition
 --> lint_example.rs:4:4
  |
4 | fn dyn() {}
  |    ^^^ help: you can use a raw identifier to stay compatible: `r#dyn`
  |
  = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018!
  = note: for more information, see issue #49716 <https://github.com/rust-lang/rust/issues/49716>
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(keyword_idents_2018)]
  |         ^^^^^^^^^^^^^^^^^^^

Explanation

Rust editions allow the language to evolve without breaking backwards compatibility. This lint catches code that uses new keywords that are added to the language that are used as identifiers (such as a variable name, function name, etc.). If you switch the compiler to a new edition without updating the code, then it will fail to compile if you are using a new keyword as an identifier.

You can manually change the identifiers to a non-keyword, or use a raw identifier, for example r#dyn, to transition to a new edition.

This lint solves the problem automatically. It is "allow" by default because the code is perfectly valid in older editions. The cargo fix tool with the --edition flag will switch this lint to "warn" and automatically apply the suggested fix from the compiler (which is to use a raw identifier). This provides a completely automated way to update old code for a new edition.

keyword-idents-2024

The keyword_idents_2024 lint detects edition keywords being used as an identifier.

Example

#![deny(keyword_idents_2024)]
// edition 2015
fn gen() {}

This will produce:

error: `gen` is a keyword in the 2024 edition
 --> lint_example.rs:4:4
  |
4 | fn gen() {}
  |    ^^^ help: you can use a raw identifier to stay compatible: `r#gen`
  |
  = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2024!
  = note: for more information, see issue #49716 <https://github.com/rust-lang/rust/issues/49716>
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(keyword_idents_2024)]
  |         ^^^^^^^^^^^^^^^^^^^

Explanation

Rust editions allow the language to evolve without breaking backwards compatibility. This lint catches code that uses new keywords that are added to the language that are used as identifiers (such as a variable name, function name, etc.). If you switch the compiler to a new edition without updating the code, then it will fail to compile if you are using a new keyword as an identifier.

You can manually change the identifiers to a non-keyword, or use a raw identifier, for example r#gen, to transition to a new edition.

This lint solves the problem automatically. It is "allow" by default because the code is perfectly valid in older editions. The cargo fix tool with the --edition flag will switch this lint to "warn" and automatically apply the suggested fix from the compiler (which is to use a raw identifier). This provides a completely automated way to update old code for a new edition.

let-underscore-drop

The let_underscore_drop lint checks for statements which don't bind an expression which has a non-trivial Drop implementation to anything, causing the expression to be dropped immediately instead of at end of scope.

Example

struct SomeStruct;
impl Drop for SomeStruct {
    fn drop(&mut self) {
        println!("Dropping SomeStruct");
    }
}

fn main() {
   #[warn(let_underscore_drop)]
    // SomeStruct is dropped immediately instead of at end of scope,
    // so "Dropping SomeStruct" is printed before "end of main".
    // The order of prints would be reversed if SomeStruct was bound to
    // a name (such as "_foo").
    let _ = SomeStruct;
    println!("end of main");
}

This will produce:

warning: non-binding let on a type that has a destructor
  --> lint_example.rs:14:5
   |
14 |     let _ = SomeStruct;
   |     ^^^^^^^^^^^^^^^^^^^
   |
note: the lint level is defined here
  --> lint_example.rs:9:11
   |
9  |    #[warn(let_underscore_drop)]
   |           ^^^^^^^^^^^^^^^^^^^
help: consider binding to an unused variable to avoid immediately dropping the value
   |
14 |     let _unused = SomeStruct;
   |         ~~~~~~~
help: consider immediately dropping the value
   |
14 |     drop(SomeStruct);
   |     ~~~~~          +

Explanation

Statements which assign an expression to an underscore causes the expression to immediately drop instead of extending the expression's lifetime to the end of the scope. This is usually unintended, especially for types like MutexGuard, which are typically used to lock a mutex for the duration of an entire scope.

If you want to extend the expression's lifetime to the end of the scope, assign an underscore-prefixed name (such as _foo) to the expression. If you do actually want to drop the expression immediately, then calling std::mem::drop on the expression is clearer and helps convey intent.

lossy-provenance-casts

The lossy_provenance_casts lint detects an as cast between a pointer and an integer.

Example

#![warn(lossy_provenance_casts)]

fn main() {
    let x: u8 = 37;
    let _addr: usize = &x as *const u8 as usize;
}

This will produce:

warning: unknown lint: `lossy_provenance_casts`
 --> lint_example.rs:1:1
  |
1 | #![warn(lossy_provenance_casts)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: the `lossy_provenance_casts` lint is unstable
  = note: see issue #130351 <https://github.com/rust-lang/rust/issues/130351> for more information
  = help: add `#![feature(strict_provenance_lints)]` to the crate attributes to enable
  = note: this compiler was built on 2024-11-10; consider upgrading it if it is out of date
  = note: `#[warn(unknown_lints)]` on by default

Explanation

This lint is part of the strict provenance effort, see issue #95228. Casting a pointer to an integer is a lossy operation, because beyond just an address a pointer may be associated with a particular provenance. This information is used by the optimiser and for dynamic analysis/dynamic program verification (e.g. Miri or CHERI platforms).

Since this cast is lossy, it is considered good style to use the ptr::addr method instead, which has a similar effect, but doesn't "expose" the pointer provenance. This improves optimisation potential. See the docs of ptr::addr and ptr::expose_provenance for more information about exposing pointer provenance.

If your code can't comply with strict provenance and needs to expose the provenance, then there is ptr::expose_provenance as an escape hatch, which preserves the behaviour of as usize casts while being explicit about the semantics.

macro-use-extern-crate

The macro_use_extern_crate lint detects the use of the macro_use attribute.

Example

#![deny(macro_use_extern_crate)]

#[macro_use]
extern crate serde_json;

fn main() {
    let _ = json!{{}};
}

This will produce:

error: applying the `#[macro_use]` attribute to an `extern crate` item is deprecated
 --> src/main.rs:3:1
  |
3 | #[macro_use]
  | ^^^^^^^^^^^^
  |
  = help: remove it and import macros at use sites with a `use` item instead
note: the lint level is defined here
 --> src/main.rs:1:9
  |
1 | #![deny(macro_use_extern_crate)]
  |         ^^^^^^^^^^^^^^^^^^^^^^

Explanation

The macro_use attribute on an extern crate item causes macros in that external crate to be brought into the prelude of the crate, making the macros in scope everywhere. As part of the efforts to simplify handling of dependencies in the 2018 edition, the use of extern crate is being phased out. To bring macros from extern crates into scope, it is recommended to use a use import.

This lint is "allow" by default because this is a stylistic choice that has not been settled, see issue #52043 for more information.

meta-variable-misuse

The meta_variable_misuse lint detects possible meta-variable misuse in macro definitions.

Example

#![deny(meta_variable_misuse)]

macro_rules! foo {
    () => {};
    ($( $i:ident = $($j:ident),+ );*) => { $( $( $i = $k; )+ )* };
}

fn main() {
    foo!();
}

This will produce:

error: unknown macro variable `k`
 --> lint_example.rs:5:55
  |
5 |     ($( $i:ident = $($j:ident),+ );*) => { $( $( $i = $k; )+ )* };
  |                                                       ^^
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(meta_variable_misuse)]
  |         ^^^^^^^^^^^^^^^^^^^^

Explanation

There are quite a few different ways a macro_rules macro can be improperly defined. Many of these errors were previously only detected when the macro was expanded or not at all. This lint is an attempt to catch some of these problems when the macro is defined.

This lint is "allow" by default because it may have false positives and other issues. See issue #61053 for more details.

missing-abi

The missing_abi lint detects cases where the ABI is omitted from extern declarations.

Example

#![deny(missing_abi)]

extern fn foo() {}

This will produce:

error: extern declarations without an explicit ABI are deprecated
 --> lint_example.rs:4:1
  |
4 | extern fn foo() {}
  | ^^^^^^ help: explicitly specify the C ABI: `extern "C"`
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(missing_abi)]
  |         ^^^^^^^^^^^

Explanation

For historic reasons, Rust implicitly selects C as the default ABI for extern declarations. Other ABIs like C-unwind and system have been added since then, and especially with their addition seeing the ABI easily makes code review easier.

missing-copy-implementations

The missing_copy_implementations lint detects potentially-forgotten implementations of Copy for public types.

Example

#![deny(missing_copy_implementations)]
pub struct Foo {
    pub field: i32
}
fn main() {}

This will produce:

error: type could implement `Copy`; consider adding `impl Copy`
 --> lint_example.rs:2:1
  |
2 | / pub struct Foo {
3 | |     pub field: i32
4 | | }
  | |_^
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(missing_copy_implementations)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

Historically (before 1.0), types were automatically marked as Copy if possible. This was changed so that it required an explicit opt-in by implementing the Copy trait. As part of this change, a lint was added to alert if a copyable type was not marked Copy.

This lint is "allow" by default because this code isn't bad; it is common to write newtypes like this specifically so that a Copy type is no longer Copy. Copy types can result in unintended copies of large data which can impact performance.

missing-debug-implementations

The missing_debug_implementations lint detects missing implementations of fmt::Debug for public types.

Example

#![deny(missing_debug_implementations)]
pub struct Foo;
fn main() {}

This will produce:

error: type does not implement `Debug`; consider adding `#[derive(Debug)]` or a manual implementation
 --> lint_example.rs:2:1
  |
2 | pub struct Foo;
  | ^^^^^^^^^^^^^^^
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(missing_debug_implementations)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

Having a Debug implementation on all types can assist with debugging, as it provides a convenient way to format and display a value. Using the #[derive(Debug)] attribute will automatically generate a typical implementation, or a custom implementation can be added by manually implementing the Debug trait.

This lint is "allow" by default because adding Debug to all types can have a negative impact on compile time and code size. It also requires boilerplate to be added to every type, which can be an impediment.

missing-docs

The missing_docs lint detects missing documentation for public items.

Example

#![deny(missing_docs)]
pub fn foo() {}

This will produce:

error: missing documentation for the crate
 --> lint_example.rs:1:1
  |
1 | / #![deny(missing_docs)]
2 | | fn main() {
3 | | pub fn foo() {}
4 | | }
  | |_^
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(missing_docs)]
  |         ^^^^^^^^^^^^

Explanation

This lint is intended to ensure that a library is well-documented. Items without documentation can be difficult for users to understand how to use properly.

This lint is "allow" by default because it can be noisy, and not all projects may want to enforce everything to be documented.

missing-unsafe-on-extern

The missing_unsafe_on_extern lint detects missing unsafe keyword on extern declarations.

Example

#![warn(missing_unsafe_on_extern)]
#![allow(dead_code)]

extern "C" {
    fn foo(_: i32);
}

fn main() {}

This will produce:

warning: extern blocks should be unsafe
 --> lint_example.rs:4:1
  |
4 |   extern "C" {
  |   ^
  |   |
  |  _help: needs `unsafe` before the extern keyword: `unsafe`
  | |
5 | |     fn foo(_: i32);
6 | | }
  | |_^
  |
  = warning: this is accepted in the current edition (Rust 2021) but is a hard error in Rust 2024!
  = note: for more information, see issue #123743 <https://github.com/rust-lang/rust/issues/123743>
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![warn(missing_unsafe_on_extern)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

Declaring extern items, even without ever using them, can cause Undefined Behavior. We should consider all sources of Undefined Behavior to be unsafe.

This is a future-incompatible lint to transition this to a hard error in the future.

multiple-supertrait-upcastable

The multiple_supertrait_upcastable lint detects when a dyn-compatible trait has multiple supertraits.

Example

#![feature(multiple_supertrait_upcastable)]
trait A {}
trait B {}

#[warn(multiple_supertrait_upcastable)]
trait C: A + B {}

This will produce:

warning: `C` is dyn-compatible and has multiple supertraits
 --> lint_example.rs:7:1
  |
7 | trait C: A + B {}
  | ^^^^^^^^^^^^^^
  |
note: the lint level is defined here
 --> lint_example.rs:6:8
  |
6 | #[warn(multiple_supertrait_upcastable)]
  |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

To support upcasting with multiple supertraits, we need to store multiple vtables and this can result in extra space overhead, even if no code actually uses upcasting. This lint allows users to identify when such scenarios occur and to decide whether the additional overhead is justified.

must-not-suspend

The must_not_suspend lint guards against values that shouldn't be held across suspend points (.await)

Example

#![feature(must_not_suspend)]
#![warn(must_not_suspend)]

#[must_not_suspend]
struct SyncThing {}

async fn yield_now() {}

pub async fn uhoh() {
    let guard = SyncThing {};
    yield_now().await;
    let _guard = guard;
}

This will produce:

warning: `SyncThing` held across a suspend point, but should not be
  --> lint_example.rs:11:9
   |
11 |     let guard = SyncThing {};
   |         ^^^^^
12 |     yield_now().await;
   |                 ----- the value is held across this suspend point
   |
help: consider using a block (`{ ... }`) to shrink the value's scope, ending before the suspend point
  --> lint_example.rs:11:9
   |
11 |     let guard = SyncThing {};
   |         ^^^^^
note: the lint level is defined here
  --> lint_example.rs:2:9
   |
2  | #![warn(must_not_suspend)]
   |         ^^^^^^^^^^^^^^^^

Explanation

The must_not_suspend lint detects values that are marked with the #[must_not_suspend] attribute being held across suspend points. A "suspend" point is usually a .await in an async function.

This attribute can be used to mark values that are semantically incorrect across suspends (like certain types of timers), values that have async alternatives, and values that regularly cause problems with the Send-ness of async fn's returned futures (like MutexGuard's)

non-ascii-idents

The non_ascii_idents lint detects non-ASCII identifiers.

Example

#![allow(unused)]
#![deny(non_ascii_idents)]
fn main() {
    let föö = 1;
}

This will produce:

error: identifier contains non-ASCII characters
 --> lint_example.rs:4:9
  |
4 |     let föö = 1;
  |         ^^^
  |
note: the lint level is defined here
 --> lint_example.rs:2:9
  |
2 | #![deny(non_ascii_idents)]
  |         ^^^^^^^^^^^^^^^^

Explanation

This lint allows projects that wish to retain the limit of only using ASCII characters to switch this lint to "forbid" (for example to ease collaboration or for security reasons). See RFC 2457 for more details.

non-exhaustive-omitted-patterns

The non_exhaustive_omitted_patterns lint aims to help consumers of a #[non_exhaustive] struct or enum who want to match all of its fields/variants explicitly.

The #[non_exhaustive] annotation forces matches to use wildcards, so exhaustiveness checking cannot be used to ensure that all fields/variants are matched explicitly. To remedy this, this allow-by-default lint warns the user when a match mentions some but not all of the fields/variants of a #[non_exhaustive] struct or enum.

Example

// crate A
#[non_exhaustive]
pub enum Bar {
    A,
    B, // added variant in non breaking change
}

// in crate B
#![feature(non_exhaustive_omitted_patterns_lint)]
#[warn(non_exhaustive_omitted_patterns)]
match Bar::A {
    Bar::A => {},
    _ => {},
}

This will produce:

warning: some variants are not matched explicitly
   --> $DIR/reachable-patterns.rs:70:9
   |
LL |         match Bar::A {
   |               ^ pattern `Bar::B` not covered
   |
 note: the lint level is defined here
  --> $DIR/reachable-patterns.rs:69:16
   |
LL |         #[warn(non_exhaustive_omitted_patterns)]
   |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   = help: ensure that all variants are matched explicitly by adding the suggested match arms
   = note: the matched value is of type `Bar` and the `non_exhaustive_omitted_patterns` attribute was found

Warning: setting this to deny will make upstream non-breaking changes (adding fields or variants to a #[non_exhaustive] struct or enum) break your crate. This goes against expected semver behavior.

Explanation

Structs and enums tagged with #[non_exhaustive] force the user to add a (potentially redundant) wildcard when pattern-matching, to allow for future addition of fields or variants. The non_exhaustive_omitted_patterns lint detects when such a wildcard happens to actually catch some fields/variants. In other words, when the match without the wildcard would not be exhaustive. This lets the user be informed if new fields/variants were added.

or-patterns-back-compat

The lint or-patterns-back-compat has been renamed to rust-2021-incompatible-or-patterns.

redundant-imports

The redundant_imports lint detects imports that are redundant due to being imported already; either through a previous import, or being present in the prelude.

Example

#![deny(redundant_imports)]
use std::option::Option::None;
fn foo() -> Option<i32> { None }

This will produce:

error: the item `None` is imported redundantly
   --> lint_example.rs:3:5
    |
3   | use std::option::Option::None;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^
    |
   ::: /checkout/library/std/src/prelude/mod.rs:155:13
    |
155 |     pub use core::prelude::rust_2021::*;
    |             ------------------------ the item `None` is already defined here
    |
note: the lint level is defined here
   --> lint_example.rs:1:9
    |
1   | #![deny(redundant_imports)]
    |         ^^^^^^^^^^^^^^^^^

Explanation

Redundant imports are unnecessary and can be removed to simplify code. If you intended to re-export the item to make it available outside of the module, add a visibility modifier like pub.

redundant-lifetimes

The redundant_lifetimes lint detects lifetime parameters that are redundant because they are equal to another named lifetime.

Example

#[deny(redundant_lifetimes)]

// `'a = 'static`, so all usages of `'a` can be replaced with `'static`
pub fn bar<'a: 'static>() {}

// `'a = 'b`, so all usages of `'b` can be replaced with `'a`
pub fn bar<'a: 'b, 'b: 'a>() {}

This will produce:

error: unnecessary lifetime parameter `'a`
 --> lint_example.rs:5:12
  |
5 | pub fn bar<'a: 'static>() {}
  |            ^^
  |
  = note: you can use the `'static` lifetime directly, in place of `'a`
note: the lint level is defined here
 --> lint_example.rs:2:8
  |
2 | #[deny(redundant_lifetimes)]
  |        ^^^^^^^^^^^^^^^^^^^

Explanation

Unused lifetime parameters may signal a mistake or unfinished code. Consider removing the parameter.

rust-2021-incompatible-closure-captures

The rust_2021_incompatible_closure_captures lint detects variables that aren't completely captured in Rust 2021, such that the Drop order of their fields may differ between Rust 2018 and 2021.

It can also detect when a variable implements a trait like Send, but one of its fields does not, and the field is captured by a closure and used with the assumption that said field implements the same trait as the root variable.

Example of drop reorder

#![deny(rust_2021_incompatible_closure_captures)]
#![allow(unused)]

struct FancyInteger(i32);

impl Drop for FancyInteger {
    fn drop(&mut self) {
        println!("Just dropped {}", self.0);
    }
}

struct Point { x: FancyInteger, y: FancyInteger }

fn main() {
  let p = Point { x: FancyInteger(10), y: FancyInteger(20) };

  let c = || {
     let x = p.x;
  };

  c();

  // ... More code ...
}

This will produce:

error: changes to closure capture in Rust 2021 will affect drop order
  --> lint_example.rs:17:11
   |
17 |   let c = || {
   |           ^^
18 |      let x = p.x;
   |              --- in Rust 2018, this closure captures all of `p`, but in Rust 2021, it will only capture `p.x`
...
24 | }
   | - in Rust 2018, `p` is dropped here, but in Rust 2021, only `p.x` will be dropped here as part of the closure
   |
   = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/disjoint-capture-in-closures.html>
note: the lint level is defined here
  --> lint_example.rs:1:9
   |
1  | #![deny(rust_2021_incompatible_closure_captures)]
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: add a dummy let to cause `p` to be fully captured
   |
17 ~   let c = || {
18 +      let _ = &p;
   |

Explanation

In the above example, p.y will be dropped at the end of f instead of with c in Rust 2021.

Example of auto-trait

#![deny(rust_2021_incompatible_closure_captures)]
use std::thread;

struct Pointer(*mut i32);
unsafe impl Send for Pointer {}

fn main() {
    let mut f = 10;
    let fptr = Pointer(&mut f as *mut i32);
    thread::spawn(move || unsafe {
        *fptr.0 = 20;
    });
}

This will produce:

error: changes to closure capture in Rust 2021 will affect which traits the closure implements
  --> lint_example.rs:10:19
   |
10 |     thread::spawn(move || unsafe {
   |                   ^^^^^^^ in Rust 2018, this closure implements `Send` as `fptr` implements `Send`, but in Rust 2021, this closure will no longer implement `Send` because `fptr` is not fully captured and `fptr.0` does not implement `Send`
11 |         *fptr.0 = 20;
   |         ------- in Rust 2018, this closure captures all of `fptr`, but in Rust 2021, it will only capture `fptr.0`
   |
   = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/disjoint-capture-in-closures.html>
note: the lint level is defined here
  --> lint_example.rs:1:9
   |
1  | #![deny(rust_2021_incompatible_closure_captures)]
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: add a dummy let to cause `fptr` to be fully captured
   |
10 ~     thread::spawn(move || { let _ = &fptr; unsafe {
11 |         *fptr.0 = 20;
12 ~     } });
   |

Explanation

In the above example, only fptr.0 is captured in Rust 2021. The field is of type *mut i32, which doesn't implement Send, making the code invalid as the field cannot be sent between threads safely.

rust-2021-incompatible-or-patterns

The rust_2021_incompatible_or_patterns lint detects usage of old versions of or-patterns.

Example

#![deny(rust_2021_incompatible_or_patterns)]

macro_rules! match_any {
    ( $expr:expr , $( $( $pat:pat )|+ => $expr_arm:expr ),+ ) => {
        match $expr {
            $(
                $( $pat => $expr_arm, )+
            )+
        }
    };
}

fn main() {
    let result: Result<i64, i32> = Err(42);
    let int: i64 = match_any!(result, Ok(i) | Err(i) => i.into());
    assert_eq!(int, 42);
}

This will produce:

error: the meaning of the `pat` fragment specifier is changing in Rust 2021, which may affect this macro
 --> lint_example.rs:4:26
  |
4 |     ( $expr:expr , $( $( $pat:pat )|+ => $expr_arm:expr ),+ ) => {
  |                          ^^^^^^^^ help: use pat_param to preserve semantics: `$pat:pat_param`
  |
  = warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021!
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/or-patterns-macro-rules.html>
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(rust_2021_incompatible_or_patterns)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

In Rust 2021, the pat matcher will match additional patterns, which include the | character.

rust-2021-prefixes-incompatible-syntax

The rust_2021_prefixes_incompatible_syntax lint detects identifiers that will be parsed as a prefix instead in Rust 2021.

Example

#![deny(rust_2021_prefixes_incompatible_syntax)]

macro_rules! m {
    (z $x:expr) => ();
}

m!(z"hey");

This will produce:

error: prefix `z` is unknown
 --> lint_example.rs:8:4
  |
8 | m!(z"hey");
  |    ^ unknown prefix
  |
  = warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021!
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/reserving-syntax.html>
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(rust_2021_prefixes_incompatible_syntax)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: insert whitespace here to avoid this being parsed as a prefix in Rust 2021
  |
8 | m!(z "hey");
  |     +

Explanation

In Rust 2015 and 2018, z"hey" is two tokens: the identifier z followed by the string literal "hey". In Rust 2021, the z is considered a prefix for "hey".

This lint suggests to add whitespace between the z and "hey" tokens to keep them separated in Rust 2021.

rust-2021-prelude-collisions

The rust_2021_prelude_collisions lint detects the usage of trait methods which are ambiguous with traits added to the prelude in future editions.

Example

#![deny(rust_2021_prelude_collisions)]

trait Foo {
    fn try_into(self) -> Result<String, !>;
}

impl Foo for &str {
    fn try_into(self) -> Result<String, !> {
        Ok(String::from(self))
    }
}

fn main() {
    let x: String = "3".try_into().unwrap();
    //                  ^^^^^^^^
    // This call to try_into matches both Foo::try_into and TryInto::try_into as
    // `TryInto` has been added to the Rust prelude in 2021 edition.
    println!("{x}");
}

This will produce:

error: trait method `try_into` will become ambiguous in Rust 2021
  --> lint_example.rs:14:21
   |
14 |     let x: String = "3".try_into().unwrap();
   |                     ^^^^^^^^^^^^^^ help: disambiguate the associated function: `Foo::try_into(&*"3")`
   |
   = warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021!
   = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/prelude.html>
note: the lint level is defined here
  --> lint_example.rs:1:9
   |
1  | #![deny(rust_2021_prelude_collisions)]
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

In Rust 2021, one of the important introductions is the prelude changes, which add TryFrom, TryInto, and FromIterator into the standard library's prelude. Since this results in an ambiguity as to which method/function to call when an existing try_into method is called via dot-call syntax or a try_from/from_iter associated function is called directly on a type.

rust-2024-guarded-string-incompatible-syntax

The rust_2024_guarded_string_incompatible_syntax lint detects # tokens that will be parsed as part of a guarded string literal in Rust 2024.

Example

#![deny(rust_2024_guarded_string_incompatible_syntax)]

macro_rules! m {
    (# $x:expr #) => ();
    (# $x:expr) => ();
}

m!(#"hey"#);
m!(#"hello");

This will produce:

error: will be parsed as a guarded string in Rust 2024
 --> lint_example.rs:9:4
  |
9 | m!(#"hey"#);
  |    ^^^^^^^
  |
  = warning: this is accepted in the current edition (Rust 2021) but is a hard error in Rust 2024!
  = note: for more information, see issue #123735 <https://github.com/rust-lang/rust/issues/123735>
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(rust_2024_guarded_string_incompatible_syntax)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: insert whitespace here to avoid this being parsed as a guarded string in Rust 2024
  |
9 | m!(# "hey"#);
  |     +


error: will be parsed as a guarded string in Rust 2024
  --> lint_example.rs:10:4
   |
10 | m!(#"hello");
   |    ^^^^^^^^
   |
   = warning: this is accepted in the current edition (Rust 2021) but is a hard error in Rust 2024!
   = note: for more information, see issue #123735 <https://github.com/rust-lang/rust/issues/123735>
help: insert whitespace here to avoid this being parsed as a guarded string in Rust 2024
   |
10 | m!(# "hello");
   |     +

Explanation

Prior to Rust 2024, #"hey"# is three tokens: the first # followed by the string literal "hey" then the final #. In Rust 2024, the whole sequence is considered a single token.

This lint suggests to add whitespace between the leading # and the string to keep them separated in Rust 2024.

rust-2024-incompatible-pat

The rust_2024_incompatible_pat lint detects patterns whose meaning will change in the Rust 2024 edition.

Example

#![warn(rust_2024_incompatible_pat)]

if let Some(&a) = &Some(&0u8) {
    let _: u8 = a;
}
if let Some(mut _a) = &mut Some(0u8) {
    _a = 7u8;
}

This will produce:

warning: patterns are not allowed to reset the default binding mode in edition 2024
 --> lint_example.rs:4:8
  |
4 | if let Some(&a) = &Some(&0u8) {
  |        -^^^^^^^
  |        |
  |        help: desugar the match ergonomics: `&`
  |
  = warning: this changes meaning in Rust 2024
  = note: for more information, see 123076
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![warn(rust_2024_incompatible_pat)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^


warning: patterns are not allowed to reset the default binding mode in edition 2024
 --> lint_example.rs:7:8
  |
7 | if let Some(mut _a) = &mut Some(0u8) {
  |        -^^^^^^^^^^^
  |        |
  |        help: desugar the match ergonomics: `&mut`
  |
  = warning: this changes meaning in Rust 2024
  = note: for more information, see 123076

Explanation

In Rust 2024 and above, the mut keyword does not reset the pattern binding mode, and nor do & or &mut patterns. The lint will suggest code that has the same meaning in all editions.

rust-2024-prelude-collisions

The rust_2024_prelude_collisions lint detects the usage of trait methods which are ambiguous with traits added to the prelude in future editions.

Example

#![deny(rust_2024_prelude_collisions)]
trait Meow {
    fn poll(&self) {}
}
impl<T> Meow for T {}

fn main() {
    core::pin::pin!(async {}).poll();
    //                        ^^^^^^
    // This call to try_into matches both Future::poll and Meow::poll as
    // `Future` has been added to the Rust prelude in 2024 edition.
}

This will produce:

error: trait method `poll` will become ambiguous in Rust 2024
 --> lint_example.rs:8:5
  |
8 |     core::pin::pin!(async {}).poll();
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: disambiguate the associated function: `Meow::poll(&core::pin::pin!(async {}))`
  |
  = warning: this is accepted in the current edition (Rust 2021) but is a hard error in Rust 2024!
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/prelude.html>
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(rust_2024_prelude_collisions)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

Rust 2024, introduces two new additions to the standard library's prelude: Future and IntoFuture. This results in an ambiguity as to which method/function to call when an existing poll/into_future method is called via dot-call syntax or a poll/into_future associated function is called directly on a type.

single-use-lifetime

The lint single-use-lifetime has been renamed to single-use-lifetimes.

single-use-lifetimes

The single_use_lifetimes lint detects lifetimes that are only used once.

Example

#![deny(single_use_lifetimes)]

fn foo<'a>(x: &'a u32) {}

This will produce:

error: lifetime parameter `'a` only used once
 --> lint_example.rs:4:8
  |
4 | fn foo<'a>(x: &'a u32) {}
  |        ^^      -- ...is used only here
  |        |
  |        this lifetime...
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(single_use_lifetimes)]
  |         ^^^^^^^^^^^^^^^^^^^^
help: elide the single-use lifetime
  |
4 - fn foo<'a>(x: &'a u32) {}
4 + fn foo(x: &u32) {}
  |

Explanation

Specifying an explicit lifetime like 'a in a function or impl should only be used to link together two things. Otherwise, you should just use '_ to indicate that the lifetime is not linked to anything, or elide the lifetime altogether if possible.

This lint is "allow" by default because it was introduced at a time when '_ and elided lifetimes were first being introduced, and this lint would be too noisy. Also, there are some known false positives that it produces. See RFC 2115 for historical context, and issue #44752 for more details.

tail-expr-drop-order

The tail_expr_drop_order lint looks for those values generated at the tail expression location, that runs a custom Drop destructor. Some of them may be dropped earlier in Edition 2024 that they used to in Edition 2021 and prior. This lint detects those cases and provides you information on those values and their custom destructor implementations. Your discretion on this information is required.

Example

#![warn(tail_expr_drop_order)]
struct Droppy(i32);
impl Droppy {
    fn get(&self) -> i32 {
        self.0
    }
}
impl Drop for Droppy {
    fn drop(&mut self) {
        // This is a custom destructor and it induces side-effects that is observable
        // especially when the drop order at a tail expression changes.
        println!("loud drop {}", self.0);
    }
}
fn edition_2021() -> i32 {
    let another_droppy = Droppy(0);
    Droppy(1).get()
}
fn main() {
    edition_2021();
}

This will produce:

warning: these values and local bindings have significant drop implementation that will have a different drop order from that of Edition 2021
  --> lint_example.rs:17:5
   |
16 |     let another_droppy = Droppy(0);
   |         -------------- these values have significant drop implementation and will observe changes in drop order under Edition 2024
17 |     Droppy(1).get()
   |     ^^^^^^^^^
   |
   = warning: this changes meaning in Rust 2024
   = note: for more information, see issue #123739 <https://github.com/rust-lang/rust/issues/123739>
note: the lint level is defined here
  --> lint_example.rs:1:9
   |
1  | #![warn(tail_expr_drop_order)]
   |         ^^^^^^^^^^^^^^^^^^^^

Explanation

In tail expression of blocks or function bodies, values of type with significant Drop implementation has an ill-specified drop order before Edition 2024 so that they are dropped only after dropping local variables. Edition 2024 introduces a new rule with drop orders for them, so that they are dropped first before dropping local variables.

A significant Drop::drop destructor here refers to an explicit, arbitrary implementation of the Drop trait on the type, with exceptions including Vec, Box, Rc, BTreeMap and HashMap that are marked by the compiler otherwise so long that the generic types have no significant destructor recursively. In other words, a type has a significant drop destructor when it has a Drop implementation or its destructor invokes a significant destructor on a type. Since we cannot completely reason about the change by just inspecting the existence of a significant destructor, this lint remains only a suggestion and is set to allow by default.

This lint only points out the issue with Droppy, which will be dropped before another_droppy does in Edition 2024. No fix will be proposed by this lint. However, the most probable fix is to hoist Droppy into its own local variable binding.

struct Droppy(i32);
impl Droppy {
    fn get(&self) -> i32 {
        self.0
    }
}
fn edition_2024() -> i32 {
    let value = Droppy(0);
    let another_droppy = Droppy(1);
    value.get()
}

trivial-casts

The trivial_casts lint detects trivial casts which could be replaced with coercion, which may require a temporary variable.

Example

#![deny(trivial_casts)]
let x: &u32 = &42;
let y = x as *const u32;

This will produce:

error: trivial cast: `&u32` as `*const u32`
 --> lint_example.rs:4:9
  |
4 | let y = x as *const u32;
  |         ^^^^^^^^^^^^^^^
  |
  = help: cast can be replaced by coercion; this might require a temporary variable
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(trivial_casts)]
  |         ^^^^^^^^^^^^^

Explanation

A trivial cast is a cast e as T where e has type U and U is a subtype of T. This type of cast is usually unnecessary, as it can be usually be inferred.

This lint is "allow" by default because there are situations, such as with FFI interfaces or complex type aliases, where it triggers incorrectly, or in situations where it will be more difficult to clearly express the intent. It may be possible that this will become a warning in the future, possibly with an explicit syntax for coercions providing a convenient way to work around the current issues. See RFC 401 (coercions), RFC 803 (type ascription) and RFC 3307 (remove type ascription) for historical context.

trivial-numeric-casts

The trivial_numeric_casts lint detects trivial numeric casts of types which could be removed.

Example

#![deny(trivial_numeric_casts)]
let x = 42_i32 as i32;

This will produce:

error: trivial numeric cast: `i32` as `i32`
 --> lint_example.rs:3:9
  |
3 | let x = 42_i32 as i32;
  |         ^^^^^^^^^^^^^
  |
  = help: cast can be replaced by coercion; this might require a temporary variable
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(trivial_numeric_casts)]
  |         ^^^^^^^^^^^^^^^^^^^^^

Explanation

A trivial numeric cast is a cast of a numeric type to the same numeric type. This type of cast is usually unnecessary.

This lint is "allow" by default because there are situations, such as with FFI interfaces or complex type aliases, where it triggers incorrectly, or in situations where it will be more difficult to clearly express the intent. It may be possible that this will become a warning in the future, possibly with an explicit syntax for coercions providing a convenient way to work around the current issues. See RFC 401 (coercions), RFC 803 (type ascription) and RFC 3307 (remove type ascription) for historical context.

unit-bindings

The unit_bindings lint detects cases where bindings are useless because they have the unit type () as their inferred type. The lint is suppressed if the user explicitly annotates the let binding with the unit type (), or if the let binding uses an underscore wildcard pattern, i.e. let _ = expr, or if the binding is produced from macro expansions.

Example

#![deny(unit_bindings)]

fn foo() {
    println!("do work");
}

pub fn main() {
    let x = foo(); // useless binding
}

This will produce:

error: binding has unit type `()`
 --> lint_example.rs:8:5
  |
8 |     let x = foo(); // useless binding
  |     ^^^^-^^^^^^^^^
  |         |
  |         this pattern is inferred to be the unit type `()`
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(unit_bindings)]
  |         ^^^^^^^^^^^^^

Explanation

Creating a local binding with the unit type () does not do much and can be a sign of a user error, such as in this example:

fn main() {
    let mut x = [1, 2, 3];
    x[0] = 5;
    let y = x.sort(); // useless binding as `sort` returns `()` and not the sorted array.
    println!("{:?}", y); // prints "()"
}

unnameable-types

The unnameable_types lint detects types for which you can get objects of that type, but cannot name the type itself.

Example

#![allow(unused)]
#![deny(unnameable_types)]
mod m {
    pub struct S;
}

pub fn get_unnameable() -> m::S { m::S }
fn main() {}

This will produce:

error: struct `S` is reachable but cannot be named
 --> lint_example.rs:4:5
  |
4 |     pub struct S;
  |     ^^^^^^^^^^^^ reachable at visibility `pub`, but can only be named at visibility `pub(crate)`
  |
note: the lint level is defined here
 --> lint_example.rs:2:9
  |
2 | #![deny(unnameable_types)]
  |         ^^^^^^^^^^^^^^^^

Explanation

It is often expected that if you can obtain an object of type T, then you can name the type T as well, this lint attempts to enforce this rule. The recommended action is to either reexport the type properly to make it nameable, or document that users are not supposed to be able to name it for one reason or another.

Besides types, this lint applies to traits because traits can also leak through signatures, and you may obtain objects of their dyn Trait or impl Trait types.

unqualified-local-imports

The unqualified_local_imports lint checks for use items that import a local item using a path that does not start with self::, super::, or crate::.

Example

#![warn(unqualified_local_imports)]

mod localmod {
    pub struct S;
}

use localmod::S;
// We have to actually use `S`, or else the `unused` warnings suppress the lint we care about.
pub fn main() {
    let _x = S;
}

This will produce:

warning: unknown lint: `unqualified_local_imports`
 --> lint_example.rs:1:1
  |
1 | #![warn(unqualified_local_imports)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: the `unqualified_local_imports` lint is unstable
  = help: add `#![feature(unqualified_local_imports)]` to the crate attributes to enable
  = note: this compiler was built on 2024-11-10; consider upgrading it if it is out of date
  = note: `#[warn(unknown_lints)]` on by default

Explanation

This lint is meant to be used with the (unstable) rustfmt setting group_imports = "StdExternalCrate". That setting makes rustfmt group self::, super::, and crate:: imports separately from those refering to other crates. However, rustfmt cannot know whether use c::S; refers to a local module c or an external crate c, so it always gets categorized as an import from another crate. To ensure consistent grouping of imports from the local crate, all local imports must start with self::, super::, or crate::. This lint can be used to enforce that style.

unreachable-pub

The unreachable_pub lint triggers for pub items not reachable from other crates - that means neither directly accessible, nor reexported, nor leaked through things like return types.

Example

#![deny(unreachable_pub)]
mod foo {
    pub mod bar {

    }
}

This will produce:

error: unreachable `pub` item
 --> lint_example.rs:4:5
  |
4 |     pub mod bar {
  |     ---^^^^^^^^
  |     |
  |     help: consider restricting its visibility: `pub(crate)`
  |
  = help: or consider exporting it for use by other crates
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(unreachable_pub)]
  |         ^^^^^^^^^^^^^^^

Explanation

The pub keyword both expresses an intent for an item to be publicly available, and also signals to the compiler to make the item publicly accessible. The intent can only be satisfied, however, if all items which contain this item are also publicly accessible. Thus, this lint serves to identify situations where the intent does not match the reality.

If you wish the item to be accessible elsewhere within the crate, but not outside it, the pub(crate) visibility is recommended to be used instead. This more clearly expresses the intent that the item is only visible within its own crate.

This lint is "allow" by default because it will trigger for a large amount existing Rust code, and has some false-positives. Eventually it is desired for this to become warn-by-default.

unsafe-attr-outside-unsafe

The unsafe_attr_outside_unsafe lint detects a missing unsafe keyword on attributes considered unsafe.

Example

#![warn(unsafe_attr_outside_unsafe)]

#[no_mangle]
extern "C" fn foo() {}

fn main() {}

This will produce:

warning: unsafe attribute used without unsafe
 --> lint_example.rs:3:3
  |
3 | #[no_mangle]
  |   ^^^^^^^^^ usage of unsafe attribute
  |
  = warning: this is accepted in the current edition (Rust 2021) but is a hard error in Rust 2024!
  = note: for more information, see issue #123757 <https://github.com/rust-lang/rust/issues/123757>
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![warn(unsafe_attr_outside_unsafe)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^
help: wrap the attribute in `unsafe(...)`
  |
3 | #[unsafe(no_mangle)]
  |   +++++++         +

Explanation

Some attributes (e.g. no_mangle, export_name, link_section -- see issue #82499 for a more complete list) are considered "unsafe" attributes. An unsafe attribute must only be used inside unsafe(...).

This lint can automatically wrap the attributes in unsafe(...) , but this obviously cannot verify that the preconditions of the unsafe attributes are fulfilled, so that is still up to the user.

The lint is currently "allow" by default, but that might change in the future.

unsafe-code

The unsafe_code lint catches usage of unsafe code and other potentially unsound constructs like no_mangle, export_name, and link_section.

Example

#![deny(unsafe_code)]
fn main() {
    unsafe {

    }
}

#[no_mangle]
fn func_0() { }

#[export_name = "exported_symbol_name"]
pub fn name_in_rust() { }

#[no_mangle]
#[link_section = ".example_section"]
pub static VAR1: u32 = 1;

This will produce:

error: usage of an `unsafe` block
 --> lint_example.rs:3:5
  |
3 | /     unsafe {
4 | |
5 | |     }
  | |_____^
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(unsafe_code)]
  |         ^^^^^^^^^^^


error: declaration of a `no_mangle` function
 --> lint_example.rs:8:1
  |
8 | #[no_mangle]
  | ^^^^^^^^^^^^
  |
  = note: the linker's behavior with multiple libraries exporting duplicate symbol names is undefined and Rust cannot provide guarantees when you manually override them


error: declaration of a function with `export_name`
  --> lint_example.rs:11:1
   |
11 | #[export_name = "exported_symbol_name"]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: the linker's behavior with multiple libraries exporting duplicate symbol names is undefined and Rust cannot provide guarantees when you manually override them


error: declaration of a `no_mangle` static
  --> lint_example.rs:14:1
   |
14 | #[no_mangle]
   | ^^^^^^^^^^^^
   |
   = note: the linker's behavior with multiple libraries exporting duplicate symbol names is undefined and Rust cannot provide guarantees when you manually override them


error: declaration of a static with `link_section`
  --> lint_example.rs:15:1
   |
15 | #[link_section = ".example_section"]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: the program's behavior with overridden link sections on items is unpredictable and Rust cannot provide guarantees when you manually override them

Explanation

This lint is intended to restrict the usage of unsafe blocks and other constructs (including, but not limited to no_mangle, link_section and export_name attributes) wrong usage of which causes undefined behavior.

unsafe-op-in-unsafe-fn

The unsafe_op_in_unsafe_fn lint detects unsafe operations in unsafe functions without an explicit unsafe block.

Example

#![deny(unsafe_op_in_unsafe_fn)]

unsafe fn foo() {}

unsafe fn bar() {
    foo();
}

fn main() {}

This will produce:

error[E0133]: call to unsafe function `foo` is unsafe and requires unsafe block
 --> lint_example.rs:6:5
  |
6 |     foo();
  |     ^^^^^ call to unsafe function
  |
  = note: for more information, see issue #71668 <https://github.com/rust-lang/rust/issues/71668>
  = note: consult the function's documentation for information on how to avoid undefined behavior
note: an unsafe function restricts its caller, but its body is safe by default
 --> lint_example.rs:5:1
  |
5 | unsafe fn bar() {
  | ^^^^^^^^^^^^^^^
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(unsafe_op_in_unsafe_fn)]
  |         ^^^^^^^^^^^^^^^^^^^^^^

Explanation

Currently, an unsafe fn allows any unsafe operation within its body. However, this can increase the surface area of code that needs to be scrutinized for proper behavior. The unsafe block provides a convenient way to make it clear exactly which parts of the code are performing unsafe operations. In the future, it is desired to change it so that unsafe operations cannot be performed in an unsafe fn without an unsafe block.

The fix to this is to wrap the unsafe code in an unsafe block.

This lint is "allow" by default on editions up to 2021, from 2024 it is "warn" by default; the plan for increasing severity further is still being considered. See RFC #2585 and issue #71668 for more details.

unstable-features

The unstable_features lint detects uses of #![feature].

Example

#![deny(unstable_features)]
#![feature(test)]

This will produce:

error: use of an unstable feature
 --> lint_example.rs:2:12
  |
2 | #![feature(test)]
  |            ^^^^
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(unstable_features)]
  |         ^^^^^^^^^^^^^^^^^

Explanation

In larger nightly-based projects which

• consist of a multitude of crates where a subset of crates has to compile on stable either unconditionally or depending on a cfg flag to for example allow stable users to depend on them,
• don't use nightly for experimental features but for, e.g., unstable options only,

this lint may come in handy to enforce policies of these kinds.

unused-crate-dependencies

The unused_crate_dependencies lint detects crate dependencies that are never used.

Example

#![deny(unused_crate_dependencies)]

This will produce:

error: extern crate `regex` is unused in crate `lint_example`
  |
  = help: remove the dependency or add `use regex as _;` to the crate root
note: the lint level is defined here
 --> src/lib.rs:1:9
  |
1 | #![deny(unused_crate_dependencies)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

After removing the code that uses a dependency, this usually also requires removing the dependency from the build configuration. However, sometimes that step can be missed, which leads to time wasted building dependencies that are no longer used. This lint can be enabled to detect dependencies that are never used (more specifically, any dependency passed with the --extern command-line flag that is never referenced via use, extern crate, or in any path).

This lint is "allow" by default because it can provide false positives depending on how the build system is configured. For example, when using Cargo, a "package" consists of multiple crates (such as a library and a binary), but the dependencies are defined for the package as a whole. If there is a dependency that is only used in the binary, but not the library, then the lint will be incorrectly issued in the library.

unused-extern-crates

The unused_extern_crates lint guards against extern crate items that are never used.

Example

#![deny(unused_extern_crates)]
#![deny(warnings)]
extern crate proc_macro;

This will produce:

error: unused extern crate
 --> lint_example.rs:4:1
  |
4 | extern crate proc_macro;
  | ^^^^^^^^^^^^^^^^^^^^^^^^ help: remove it
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(unused_extern_crates)]
  |         ^^^^^^^^^^^^^^^^^^^^

Explanation

extern crate items that are unused have no effect and should be removed. Note that there are some cases where specifying an extern crate is desired for the side effect of ensuring the given crate is linked, even though it is not otherwise directly referenced. The lint can be silenced by aliasing the crate to an underscore, such as extern crate foo as _. Also note that it is no longer idiomatic to use extern crate in the 2018 edition, as extern crates are now automatically added in scope.

This lint is "allow" by default because it can be noisy, and produce false-positives. If a dependency is being removed from a project, it is recommended to remove it from the build configuration (such as Cargo.toml) to ensure stale build entries aren't left behind.

unused-import-braces

The unused_import_braces lint catches unnecessary braces around an imported item.

Example

#![deny(unused_import_braces)]
use test::{A};

pub mod test {
    pub struct A;
}
fn main() {}

This will produce:

error: braces around A is unnecessary
 --> lint_example.rs:2:1
  |
2 | use test::{A};
  | ^^^^^^^^^^^^^^
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(unused_import_braces)]
  |         ^^^^^^^^^^^^^^^^^^^^

Explanation

If there is only a single item, then remove the braces (use test::A; for example).

This lint is "allow" by default because it is only enforcing a stylistic choice.

unused-lifetimes

The unused_lifetimes lint detects lifetime parameters that are never used.

Example

#[deny(unused_lifetimes)]

pub fn foo<'a>() {}

This will produce:

error: lifetime parameter `'a` never used
 --> lint_example.rs:4:12
  |
4 | pub fn foo<'a>() {}
  |           -^^- help: elide the unused lifetime
  |
note: the lint level is defined here
 --> lint_example.rs:2:8
  |
2 | #[deny(unused_lifetimes)]
  |        ^^^^^^^^^^^^^^^^

Explanation

Unused lifetime parameters may signal a mistake or unfinished code. Consider removing the parameter.

unused-macro-rules

The unused_macro_rules lint detects macro rules that were not used.

Note that the lint is distinct from the unused_macros lint, which fires if the entire macro is never called, while this lint fires for single unused rules of the macro that is otherwise used. unused_macro_rules fires only if unused_macros wouldn't fire.

Example

#[warn(unused_macro_rules)]
macro_rules! unused_empty {
    (hello) => { println!("Hello, world!") }; // This rule is unused
    () => { println!("empty") }; // This rule is used
}

fn main() {
    unused_empty!(hello);
}

This will produce:

warning: rule #2 of macro `unused_empty` is never used
 --> lint_example.rs:4:5
  |
4 |     () => { println!("empty") }; // This rule is used
  |     ^^
  |
note: the lint level is defined here
 --> lint_example.rs:1:8
  |
1 | #[warn(unused_macro_rules)]
  |        ^^^^^^^^^^^^^^^^^^

Explanation

Unused macro rules may signal a mistake or unfinished code. Furthermore, they slow down compilation. Right now, silencing the warning is not supported on a single rule level, so you have to add an allow to the entire macro definition.

If you intended to export the macro to make it available outside of the crate, use the macro_export attribute.

unused-qualifications

The unused_qualifications lint detects unnecessarily qualified names.

Example

#![deny(unused_qualifications)]
mod foo {
    pub fn bar() {}
}

fn main() {
    use foo::bar;
    foo::bar();
    bar();
}

This will produce:

error: unnecessary qualification
 --> lint_example.rs:8:5
  |
8 |     foo::bar();
  |     ^^^^^^^^
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(unused_qualifications)]
  |         ^^^^^^^^^^^^^^^^^^^^^
help: remove the unnecessary path segments
  |
8 -     foo::bar();
8 +     bar();
  |

Explanation

If an item from another module is already brought into scope, then there is no need to qualify it in this case. You can call bar() directly, without the foo::.

This lint is "allow" by default because it is somewhat pedantic, and doesn't indicate an actual problem, but rather a stylistic choice, and can be noisy when refactoring or moving around code.

unused-results

The unused_results lint checks for the unused result of an expression in a statement.

Example

#![deny(unused_results)]
fn foo<T>() -> T { panic!() }

fn main() {
    foo::<usize>();
}

This will produce:

error: unused result of type `usize`
 --> lint_example.rs:5:5
  |
5 |     foo::<usize>();
  |     ^^^^^^^^^^^^^^^
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(unused_results)]
  |         ^^^^^^^^^^^^^^

Explanation

Ignoring the return value of a function may indicate a mistake. In cases were it is almost certain that the result should be used, it is recommended to annotate the function with the must_use attribute. Failure to use such a return value will trigger the unused_must_use lint which is warn-by-default. The unused_results lint is essentially the same, but triggers for all return values.

This lint is "allow" by default because it can be noisy, and may not be an actual problem. For example, calling the remove method of a Vec or HashMap returns the previous value, which you may not care about. Using this lint would require explicitly ignoring or discarding such values.

variant-size-differences

The variant_size_differences lint detects enums with widely varying variant sizes.

Example

#![deny(variant_size_differences)]
enum En {
    V0(u8),
    VBig([u8; 1024]),
}

This will produce:

error: enum variant is more than three times larger (1024 bytes) than the next largest
 --> lint_example.rs:5:5
  |
5 |     VBig([u8; 1024]),
  |     ^^^^^^^^^^^^^^^^
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(variant_size_differences)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

It can be a mistake to add a variant to an enum that is much larger than the other variants, bloating the overall size required for all variants. This can impact performance and memory usage. This is triggered if one variant is more than 3 times larger than the second-largest variant.

Consider placing the large variant's contents on the heap (for example via Box) to keep the overall size of the enum itself down.

This lint is "allow" by default because it can be noisy, and may not be an actual problem. Decisions about this should be guided with profiling and benchmarking.

Warn-by-default Lints

These lints are all set to the 'warn' level by default.

• abi_unsupported_vector_types
• ambiguous_glob_imports
• ambiguous_glob_reexports
• ambiguous_wide_pointer_comparisons
• anonymous_parameters
• array_into_iter
• asm_sub_register
• async_fn_in_trait
• bad_asm_style
• bare-trait-object
• bare_trait_objects
• boxed_slice_into_iter
• break_with_label_and_loop
• clashing_extern_declarations
• coherence_leak_check
• confusable_idents
• const_evaluatable_unchecked
• const_item_mutation
• dangling_pointers_from_temporaries
• dead_code
• dependency_on_unit_never_type_fallback
• deprecated
• deprecated_where_clause_location
• deref_into_dyn_supertrait
• deref_nullptr
• drop_bounds
• dropping_copy_types
• dropping_references
• duplicate_macro_attributes
• dyn_drop
• elided_named_lifetimes
• ellipsis_inclusive_range_patterns
• exported_private_dependencies
• for_loops_over_fallibles
• forbidden_lint_groups
• forgetting_copy_types
• forgetting_references
• function_item_references
• hidden_glob_reexports
• impl_trait_redundant_captures
• improper_ctypes
• improper_ctypes_definitions
• incomplete_features
• inline_no_sanitize
• internal_features
• invalid_from_utf8
• invalid_macro_export_arguments
• invalid_nan_comparisons
• invalid_value
• irrefutable_let_patterns
• large_assignments
• late_bound_lifetime_arguments
• legacy_derive_helpers
• map_unit_fn
• mixed_script_confusables
• named_arguments_used_positionally
• never_type_fallback_flowing_into_unsafe
• no_mangle_generic_items
• non-fmt-panic
• non_camel_case_types
• non_contiguous_range_endpoints
• non_fmt_panics
• non_local_definitions
• non_shorthand_field_patterns
• non_snake_case
• non_upper_case_globals
• noop_method_call
• opaque_hidden_inferred_bound
• out_of_scope_macro_calls
• overlapping-patterns
• overlapping_range_endpoints
• path_statements
• private_bounds
• private_interfaces
• private_macro_use
• ptr_cast_add_auto_to_object
• ptr_to_integer_transmute_in_consts
• redundant-semicolon
• redundant_semicolons
• refining_impl_trait_internal
• refining_impl_trait_reachable
• renamed_and_removed_lints
• repr_transparent_external_private_fields
• self_constructor_from_outer_item
• semicolon_in_expressions_from_macros
• special_module_name
• stable_features
• static-mut-ref
• static_mut_refs
• suspicious_double_ref_op
• trivial_bounds
• type_alias_bounds
• tyvar_behind_raw_pointer
• uncommon_codepoints
• unconditional_recursion
• uncovered_param_in_projection
• undefined_naked_function_abi
• unexpected_cfgs
• unfulfilled_lint_expectations
• ungated_async_fn_track_caller
• uninhabited_static
• unknown_lints
• unknown_or_malformed_diagnostic_attributes
• unnameable_test_items
• unreachable_code
• unreachable_patterns
• unstable-name-collision
• unstable_name_collisions
• unstable_syntax_pre_expansion
• unsupported_fn_ptr_calling_conventions
• unused-doc-comment
• unused-tuple-struct-fields
• unused_allocation
• unused_assignments
• unused_associated_type_bounds
• unused_attributes
• unused_braces
• unused_comparisons
• unused_doc_comments
• unused_features
• unused_imports
• unused_labels
• unused_macros
• unused_must_use
• unused_mut
• unused_parens
• unused_unsafe
• unused_variables
• useless_ptr_null_checks
• warnings
• while_true

abi-unsupported-vector-types

The abi_unsupported_vector_types lint detects function definitions and calls whose ABI depends on enabling certain target features, but those features are not enabled.

Example

extern "C" fn missing_target_feature(_: std::arch::x86_64::__m256) {
  todo!()
}

#[target_feature(enable = "avx")]
unsafe extern "C" fn with_target_feature(_: std::arch::x86_64::__m256) {
  todo!()
}

fn main() {
  let v = unsafe { std::mem::zeroed() };
  unsafe { with_target_feature(v); }
}

warning: ABI error: this function call uses a avx vector type, which is not enabled in the caller
 --> lint_example.rs:18:12
  |
  |   unsafe { with_target_feature(v); }
  |            ^^^^^^^^^^^^^^^^^^^^^^ function called here
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #116558 <https://github.com/rust-lang/rust/issues/116558>
  = help: consider enabling it globally (-C target-feature=+avx) or locally (#[target_feature(enable="avx")])
  = note: `#[warn(abi_unsupported_vector_types)]` on by default


warning: ABI error: this function definition uses a avx vector type, which is not enabled
 --> lint_example.rs:3:1
  |
  | pub extern "C" fn with_target_feature(_: std::arch::x86_64::__m256) {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ function defined here
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #116558 <https://github.com/rust-lang/rust/issues/116558>
  = help: consider enabling it globally (-C target-feature=+avx) or locally (#[target_feature(enable="avx")])

Explanation

The C ABI for __m256 requires the value to be passed in an AVX register, which is only possible when the avx target feature is enabled. Therefore, missing_target_feature cannot be compiled without that target feature. A similar (but complementary) message is triggered when with_target_feature is called by a function that does not enable the avx target feature.

Note that this lint is very similar to the -Wpsabi warning in gcc/clang.

ambiguous-glob-imports

The ambiguous_glob_imports lint detects glob imports that should report ambiguity errors, but previously didn't do that due to rustc bugs.

Example

#![deny(ambiguous_glob_imports)]
pub fn foo() -> u32 {
    use sub::*;
    C
}

mod sub {
    mod mod1 { pub const C: u32 = 1; }
    mod mod2 { pub const C: u32 = 2; }

    pub use mod1::*;
    pub use mod2::*;
}

This will produce:

error: `C` is ambiguous
  --> lint_example.rs:5:5
   |
5  |     C
   |     ^ ambiguous name
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #114095 <https://github.com/rust-lang/rust/issues/114095>
   = note: ambiguous because of multiple glob imports of a name in the same module
note: `C` could refer to the constant imported here
  --> lint_example.rs:12:13
   |
12 |     pub use mod1::*;
   |             ^^^^^^^
   = help: consider adding an explicit import of `C` to disambiguate
note: `C` could also refer to the constant imported here
  --> lint_example.rs:13:13
   |
13 |     pub use mod2::*;
   |             ^^^^^^^
   = help: consider adding an explicit import of `C` to disambiguate
note: the lint level is defined here
  --> lint_example.rs:1:9
   |
1  | #![deny(ambiguous_glob_imports)]
   |         ^^^^^^^^^^^^^^^^^^^^^^

Explanation

Previous versions of Rust compile it successfully because it had lost the ambiguity error when resolve use sub::mod2::*.

This is a future-incompatible lint to transition this to a hard error in the future.

ambiguous-glob-reexports

The ambiguous_glob_reexports lint detects cases where names re-exported via globs collide. Downstream users trying to use the same name re-exported from multiple globs will receive a warning pointing out redefinition of the same name.

Example

#![deny(ambiguous_glob_reexports)]
pub mod foo {
    pub type X = u8;
}

pub mod bar {
    pub type Y = u8;
    pub type X = u8;
}

pub use foo::*;
pub use bar::*;


pub fn main() {}

This will produce:

error: ambiguous glob re-exports
  --> lint_example.rs:11:9
   |
11 | pub use foo::*;
   |         ^^^^^^ the name `X` in the type namespace is first re-exported here
12 | pub use bar::*;
   |         ------ but the name `X` in the type namespace is also re-exported here
   |
note: the lint level is defined here
  --> lint_example.rs:1:9
   |
1  | #![deny(ambiguous_glob_reexports)]
   |         ^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

This was previously accepted but it could silently break a crate's downstream users code. For example, if foo::* and bar::* were re-exported before bar::X was added to the re-exports, down stream users could use this_crate::X without problems. However, adding bar::X would cause compilation errors in downstream crates because X is defined multiple times in the same namespace of this_crate.

ambiguous-wide-pointer-comparisons

The ambiguous_wide_pointer_comparisons lint checks comparison of *const/*mut ?Sized as the operands.

Example

struct A;
struct B;

trait T {}
impl T for A {}
impl T for B {}

let ab = (A, B);
let a = &ab.0 as *const dyn T;
let b = &ab.1 as *const dyn T;

let _ = a == b;

This will produce:

warning: ambiguous wide pointer comparison, the comparison includes metadata which may not be expected
  --> lint_example.rs:13:9
   |
13 | let _ = a == b;
   |         ^^^^^^
   |
   = note: `#[warn(ambiguous_wide_pointer_comparisons)]` on by default
help: use `std::ptr::addr_eq` or untyped pointers to only compare their addresses
   |
13 | let _ = std::ptr::addr_eq(a, b);
   |         ++++++++++++++++++ ~  +

Explanation

The comparison includes metadata which may not be expected.

anonymous-parameters

The anonymous_parameters lint detects anonymous parameters in trait definitions.

Example

#![deny(anonymous_parameters)]
// edition 2015
pub trait Foo {
    fn foo(usize);
}
fn main() {}

This will produce:

error: anonymous parameters are deprecated and will be removed in the next edition
 --> lint_example.rs:4:12
  |
4 |     fn foo(usize);
  |            ^^^^^ help: try naming the parameter or explicitly ignoring it: `_: usize`
  |
  = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018!
  = note: for more information, see issue #41686 <https://github.com/rust-lang/rust/issues/41686>
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(anonymous_parameters)]
  |         ^^^^^^^^^^^^^^^^^^^^

Explanation

This syntax is mostly a historical accident, and can be worked around quite easily by adding an _ pattern or a descriptive identifier:

trait Foo {
    fn foo(_: usize);
}

This syntax is now a hard error in the 2018 edition. In the 2015 edition, this lint is "warn" by default. This lint enables the cargo fix tool with the --edition flag to automatically transition old code from the 2015 edition to 2018. The tool will run this lint and automatically apply the suggested fix from the compiler (which is to add _ to each parameter). This provides a completely automated way to update old code for a new edition. See issue #41686 for more details.

array-into-iter

The array_into_iter lint detects calling into_iter on arrays.

Example

#![allow(unused)]
[1, 2, 3].into_iter().for_each(|n| { *n; });

This will produce:

warning: this method call resolves to `<&[T; N] as IntoIterator>::into_iter` (due to backwards compatibility), but will resolve to `<[T; N] as IntoIterator>::into_iter` in Rust 2021
 --> lint_example.rs:3:11
  |
3 | [1, 2, 3].into_iter().for_each(|n| { *n; });
  |           ^^^^^^^^^
  |
  = warning: this changes meaning in Rust 2021
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/IntoIterator-for-arrays.html>
  = note: `#[warn(array_into_iter)]` on by default
help: use `.iter()` instead of `.into_iter()` to avoid ambiguity
  |
3 | [1, 2, 3].iter().for_each(|n| { *n; });
  |           ~~~~
help: or use `IntoIterator::into_iter(..)` instead of `.into_iter()` to explicitly iterate by value
  |
3 | IntoIterator::into_iter([1, 2, 3]).for_each(|n| { *n; });
  | ++++++++++++++++++++++++         ~

Explanation

Since Rust 1.53, arrays implement IntoIterator. However, to avoid breakage, array.into_iter() in Rust 2015 and 2018 code will still behave as (&array).into_iter(), returning an iterator over references, just like in Rust 1.52 and earlier. This only applies to the method call syntax array.into_iter(), not to any other syntax such as for _ in array or IntoIterator::into_iter(array).

asm-sub-register

The asm_sub_register lint detects using only a subset of a register for inline asm inputs.

Example

#[cfg(target_arch="x86_64")]
use std::arch::asm;

fn main() {
    #[cfg(target_arch="x86_64")]
    unsafe {
        asm!("mov {0}, {0}", in(reg) 0i16);
    }
}

This will produce:

warning: formatting may not be suitable for sub-register argument
 --> src/main.rs:7:19
  |
7 |         asm!("mov {0}, {0}", in(reg) 0i16);
  |                   ^^^  ^^^           ---- for this argument
  |
  = note: `#[warn(asm_sub_register)]` on by default
  = help: use the `x` modifier to have the register formatted as `ax`
  = help: or use the `r` modifier to keep the default formatting of `rax`

Explanation

Registers on some architectures can use different names to refer to a subset of the register. By default, the compiler will use the name for the full register size. To explicitly use a subset of the register, you can override the default by using a modifier on the template string operand to specify when subregister to use. This lint is issued if you pass in a value with a smaller data type than the default register size, to alert you of possibly using the incorrect width. To fix this, add the suggested modifier to the template, or cast the value to the correct size.

See register template modifiers in the reference for more details.

async-fn-in-trait

The async_fn_in_trait lint detects use of async fn in the definition of a publicly-reachable trait.

Example

pub trait Trait {
    async fn method(&self);
}
fn main() {}

This will produce:

warning: use of `async fn` in public traits is discouraged as auto trait bounds cannot be specified
 --> lint_example.rs:2:5
  |
2 |     async fn method(&self);
  |     ^^^^^
  |
  = note: you can suppress this lint if you plan to use the trait only in your own code, or do not care about auto traits like `Send` on the `Future`
  = note: `#[warn(async_fn_in_trait)]` on by default
help: you can alternatively desugar to a normal `fn` that returns `impl Future` and add any desired bounds such as `Send`, but these cannot be relaxed without a breaking API change
  |
2 -     async fn method(&self);
2 +     fn method(&self) -> impl std::future::Future<Output = ()> + Send;
  |

Explanation

When async fn is used in a trait definition, the trait does not promise that the opaque Future returned by the associated function or method will implement any auto traits such as Send. This may be surprising and may make the associated functions or methods on the trait less useful than intended. On traits exposed publicly from a crate, this may affect downstream crates whose authors cannot alter the trait definition.

For example, this code is invalid:

pub trait Trait {
    async fn method(&self) {}
}

fn test<T: Trait>(x: T) {
    fn spawn<T: Send>(_: T) {}
    spawn(x.method()); // Not OK.
}

This lint exists to warn authors of publicly-reachable traits that they may want to consider desugaring the async fn to a normal fn that returns an opaque impl Future<..> + Send type.

For example, instead of:

pub trait Trait {
    async fn method(&self) {}
}

The author of the trait may want to write:

use core::future::Future;
pub trait Trait {
    fn method(&self) -> impl Future<Output = ()> + Send { async {} }
}

This still allows the use of async fn within impls of the trait. However, it also means that the trait will never be compatible with impls where the returned Future of the method does not implement Send.

Conversely, if the trait is used only locally, if it is never used in generic functions, or if it is only used in single-threaded contexts that do not care whether the returned Future implements Send, then the lint may be suppressed.

bad-asm-style

The bad_asm_style lint detects the use of the .intel_syntax and .att_syntax directives.

Example

#[cfg(target_arch="x86_64")]
use std::arch::asm;

fn main() {
    #[cfg(target_arch="x86_64")]
    unsafe {
        asm!(
            ".att_syntax",
            "movq %{0}, %{0}", in(reg) 0usize
        );
    }
}

This will produce:

warning: avoid using `.att_syntax`, prefer using `options(att_syntax)` instead
 --> src/main.rs:8:14
  |
8 |             ".att_syntax",
  |              ^^^^^^^^^^^
  |
  = note: `#[warn(bad_asm_style)]` on by default

Explanation

On x86, asm! uses the intel assembly syntax by default. While this can be switched using assembler directives like .att_syntax, using the att_syntax option is recommended instead because it will also properly prefix register placeholders with % as required by AT&T syntax.

bare-trait-object

The lint bare-trait-object has been renamed to bare-trait-objects.

bare-trait-objects

The bare_trait_objects lint suggests using dyn Trait for trait objects.

Example

trait Trait { }

fn takes_trait_object(_: Box<Trait>) {
}

This will produce:

warning: trait objects without an explicit `dyn` are deprecated
 --> lint_example.rs:4:30
  |
4 | fn takes_trait_object(_: Box<Trait>) {
  |                              ^^^^^
  |
  = warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021!
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html>
  = note: `#[warn(bare_trait_objects)]` on by default
help: if this is a dyn-compatible trait, use `dyn`
  |
4 | fn takes_trait_object(_: Box<dyn Trait>) {
  |                              +++

Explanation

Without the dyn indicator, it can be ambiguous or confusing when reading code as to whether or not you are looking at a trait object. The dyn keyword makes it explicit, and adds a symmetry to contrast with impl Trait.

boxed-slice-into-iter

The boxed_slice_into_iter lint detects calling into_iter on boxed slices.

Example

#![allow(unused)]
vec![1, 2, 3].into_boxed_slice().into_iter().for_each(|n| { *n; });

This will produce:

warning: this method call resolves to `<&Box<[T]> as IntoIterator>::into_iter` (due to backwards compatibility), but will resolve to `<Box<[T]> as IntoIterator>::into_iter` in Rust 2024
 --> lint_example.rs:3:34
  |
3 | vec![1, 2, 3].into_boxed_slice().into_iter().for_each(|n| { *n; });
  |                                  ^^^^^^^^^
  |
  = warning: this changes meaning in Rust 2024
  = note: `#[warn(boxed_slice_into_iter)]` on by default
help: use `.iter()` instead of `.into_iter()` to avoid ambiguity
  |
3 | vec![1, 2, 3].into_boxed_slice().iter().for_each(|n| { *n; });
  |                                  ~~~~
help: or use `IntoIterator::into_iter(..)` instead of `.into_iter()` to explicitly iterate by value
  |
3 | IntoIterator::into_iter(vec![1, 2, 3].into_boxed_slice()).for_each(|n| { *n; });
  | ++++++++++++++++++++++++                                ~

Explanation

Since Rust 1.80.0, boxed slices implement IntoIterator. However, to avoid breakage, boxed_slice.into_iter() in Rust 2015, 2018, and 2021 code will still behave as (&boxed_slice).into_iter(), returning an iterator over references, just like in Rust 1.79.0 and earlier. This only applies to the method call syntax boxed_slice.into_iter(), not to any other syntax such as for _ in boxed_slice or IntoIterator::into_iter(boxed_slice).

break-with-label-and-loop

The break_with_label_and_loop lint detects labeled break expressions with an unlabeled loop as their value expression.

Example

'label: loop {
    break 'label loop { break 42; };
};

This will produce:

warning: this labeled break expression is easy to confuse with an unlabeled break with a labeled value expression
 --> lint_example.rs:3:5
  |
3 |     break 'label loop { break 42; };
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(break_with_label_and_loop)]` on by default
help: wrap this expression in parentheses
  |
3 |     break 'label (loop { break 42; });
  |                  +                  +

Explanation

In Rust, loops can have a label, and break expressions can refer to that label to break out of specific loops (and not necessarily the innermost one). break expressions can also carry a value expression, which can be another loop. A labeled break with an unlabeled loop as its value expression is easy to confuse with an unlabeled break with a labeled loop and is thus discouraged (but allowed for compatibility); use parentheses around the loop expression to silence this warning. Unlabeled break expressions with labeled loops yield a hard error, which can also be silenced by wrapping the expression in parentheses.

clashing-extern-declarations

The clashing_extern_declarations lint detects when an extern fn has been declared with the same name but different types.

Example

mod m {
    extern "C" {
        fn foo();
    }
}

extern "C" {
    fn foo(_: u32);
}

This will produce:

warning: `foo` redeclared with a different signature
 --> lint_example.rs:9:5
  |
4 |         fn foo();
  |         --------- `foo` previously declared here
...
9 |     fn foo(_: u32);
  |     ^^^^^^^^^^^^^^^ this signature doesn't match the previous declaration
  |
  = note: expected `unsafe extern "C" fn()`
             found `unsafe extern "C" fn(u32)`
  = note: `#[warn(clashing_extern_declarations)]` on by default

Explanation

Because two symbols of the same name cannot be resolved to two different functions at link time, and one function cannot possibly have two types, a clashing extern declaration is almost certainly a mistake. Check to make sure that the extern definitions are correct and equivalent, and possibly consider unifying them in one location.

This lint does not run between crates because a project may have dependencies which both rely on the same extern function, but declare it in a different (but valid) way. For example, they may both declare an opaque type for one or more of the arguments (which would end up distinct types), or use types that are valid conversions in the language the extern fn is defined in. In these cases, the compiler can't say that the clashing declaration is incorrect.

coherence-leak-check

The coherence_leak_check lint detects conflicting implementations of a trait that are only distinguished by the old leak-check code.

Example

trait SomeTrait { }
impl SomeTrait for for<'a> fn(&'a u8) { }
impl<'a> SomeTrait for fn(&'a u8) { }

This will produce:

warning: conflicting implementations of trait `SomeTrait` for type `for<'a> fn(&'a u8)`
 --> lint_example.rs:4:1
  |
3 | impl SomeTrait for for<'a> fn(&'a u8) { }
  | ------------------------------------- first implementation here
4 | impl<'a> SomeTrait for fn(&'a u8) { }
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `for<'a> fn(&'a u8)`
  |
  = warning: the behavior may change in a future release
  = note: for more information, see issue #56105 <https://github.com/rust-lang/rust/issues/56105>
  = note: this behavior recently changed as a result of a bug fix; see rust-lang/rust#56105 for details
  = note: `#[warn(coherence_leak_check)]` on by default

Explanation

In the past, the compiler would accept trait implementations for identical functions that differed only in where the lifetime binder appeared. Due to a change in the borrow checker implementation to fix several bugs, this is no longer allowed. However, since this affects existing code, this is a future-incompatible lint to transition this to a hard error in the future.

Code relying on this pattern should introduce "newtypes", like struct Foo(for<'a> fn(&'a u8)).

See issue #56105 for more details.

confusable-idents

The confusable_idents lint detects visually confusable pairs between identifiers.

Example

// Latin Capital Letter E With Caron
pub const Ě: i32 = 1;
// Latin Capital Letter E With Breve
pub const Ĕ: i32 = 2;

This will produce:

warning: found both `Ě` and `Ĕ` as identifiers, which look alike
 --> lint_example.rs:5:11
  |
3 | pub const Ě: i32 = 1;
  |           - other identifier used here
4 | // Latin Capital Letter E With Breve
5 | pub const Ĕ: i32 = 2;
  |           ^ this identifier can be confused with `Ě`
  |
  = note: `#[warn(confusable_idents)]` on by default

Explanation

This lint warns when different identifiers may appear visually similar, which can cause confusion.

The confusable detection algorithm is based on Unicode® Technical Standard #39 Unicode Security Mechanisms Section 4 Confusable Detection. For every distinct identifier X execute the function skeleton(X). If there exist two distinct identifiers X and Y in the same crate where skeleton(X) = skeleton(Y) report it. The compiler uses the same mechanism to check if an identifier is too similar to a keyword.

Note that the set of confusable characters may change over time. Beware that if you "forbid" this lint that existing code may fail in the future.

const-evaluatable-unchecked

The const_evaluatable_unchecked lint detects a generic constant used in a type.

Example

const fn foo<T>() -> usize {
    if std::mem::size_of::<*mut T>() < 8 { // size of *mut T does not depend on T
        4
    } else {
        8
    }
}

fn test<T>() {
    let _ = [0; foo::<T>()];
}

This will produce:

warning: cannot use constants which depend on generic parameters in types
  --> lint_example.rs:11:17
   |
11 |     let _ = [0; foo::<T>()];
   |                 ^^^^^^^^^^
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #76200 <https://github.com/rust-lang/rust/issues/76200>
   = note: `#[warn(const_evaluatable_unchecked)]` on by default

Explanation

In the 1.43 release, some uses of generic parameters in array repeat expressions were accidentally allowed. This is a future-incompatible lint to transition this to a hard error in the future. See issue #76200 for a more detailed description and possible fixes.

const-item-mutation

The const_item_mutation lint detects attempts to mutate a const item.

Example

const FOO: [i32; 1] = [0];

fn main() {
    FOO[0] = 1;
    // This will print "[0]".
    println!("{:?}", FOO);
}

This will produce:

warning: attempting to modify a `const` item
 --> lint_example.rs:4:5
  |
4 |     FOO[0] = 1;
  |     ^^^^^^^^^^
  |
  = note: each usage of a `const` item creates a new temporary; the original `const` item will not be modified
note: `const` item defined here
 --> lint_example.rs:1:1
  |
1 | const FOO: [i32; 1] = [0];
  | ^^^^^^^^^^^^^^^^^^^
  = note: `#[warn(const_item_mutation)]` on by default

Explanation

Trying to directly mutate a const item is almost always a mistake. What is happening in the example above is that a temporary copy of the const is mutated, but the original const is not. Each time you refer to the const by name (such as FOO in the example above), a separate copy of the value is inlined at that location.

This lint checks for writing directly to a field (FOO.field = some_value) or array entry (FOO[0] = val), or taking a mutable reference to the const item (&mut FOO), including through an autoderef (FOO.some_mut_self_method()).

There are various alternatives depending on what you are trying to accomplish:

• First, always reconsider using mutable globals, as they can be difficult to use correctly, and can make the code more difficult to use or understand.
• If you are trying to perform a one-time initialization of a global:
  • If the value can be computed at compile-time, consider using const-compatible values (see Constant Evaluation).
  • For more complex single-initialization cases, consider using std::sync::LazyLock.
• If you truly need a mutable global, consider using a static, which has a variety of options:
  • Simple data types can be directly defined and mutated with an atomic type.
  • More complex types can be placed in a synchronization primitive like a Mutex, which can be initialized with one of the options listed above.
  • A mutable static is a low-level primitive, requiring unsafe. Typically This should be avoided in preference of something higher-level like one of the above.

dangling-pointers-from-temporaries

The dangling_pointers_from_temporaries lint detects getting a pointer to data of a temporary that will immediately get dropped.

Example

#![allow(unused)]
unsafe fn use_data(ptr: *const u8) { }
fn gather_and_use(bytes: impl Iterator<Item = u8>) {
    let x: *const u8 = bytes.collect::<Vec<u8>>().as_ptr();
    unsafe { use_data(x) }
}

This will produce:

warning: a dangling pointer will be produced because the temporary `Vec<u8>` will be dropped
 --> lint_example.rs:5:51
  |
5 |     let x: *const u8 = bytes.collect::<Vec<u8>>().as_ptr();
  |                        -------------------------- ^^^^^^ this pointer will immediately be invalid
  |                        |
  |                        this `Vec<u8>` is deallocated at the end of the statement, bind it to a variable to extend its lifetime
  |
  = note: pointers do not have a lifetime; when calling `as_ptr` the `Vec<u8>` will be deallocated at the end of the statement because nothing is referencing it as far as the type system is concerned
  = help: for more information, see <https://doc.rust-lang.org/reference/destructors.html>
  = note: `#[warn(dangling_pointers_from_temporaries)]` on by default

Explanation

Getting a pointer from a temporary value will not prolong its lifetime, which means that the value can be dropped and the allocation freed while the pointer still exists, making the pointer dangling. This is not an error (as far as the type system is concerned) but probably is not what the user intended either.

If you need stronger guarantees, consider using references instead, as they are statically verified by the borrow-checker to never dangle.

dead-code

The dead_code lint detects unused, unexported items.

Example

fn foo() {}

This will produce:

warning: function `foo` is never used
 --> lint_example.rs:2:4
  |
2 | fn foo() {}
  |    ^^^
  |
  = note: `#[warn(dead_code)]` on by default

Explanation

Dead code may signal a mistake or unfinished code. To silence the warning for individual items, prefix the name with an underscore such as _foo. If it was intended to expose the item outside of the crate, consider adding a visibility modifier like pub.

To preserve the numbering of tuple structs with unused fields, change the unused fields to have unit type or use PhantomData.

Otherwise consider removing the unused code.

Limitations

Removing fields that are only used for side-effects and never read will result in behavioral changes. Examples of this include:

• If a field's value performs an action when it is dropped.
• If a field's type does not implement an auto trait (e.g. Send, Sync, Unpin).

For side-effects from dropping field values, this lint should be allowed on those fields. For side-effects from containing field types, PhantomData should be used.

dependency-on-unit-never-type-fallback

The dependency_on_unit_never_type_fallback lint detects cases where code compiles with never type fallback being (), but will stop compiling with fallback being !.

Example

#![deny(dependency_on_unit_never_type_fallback)]
fn main() {
    if true {
        // return has type `!` which, is some cases, causes never type fallback
        return
    } else {
        // the type produced by this call is not specified explicitly,
        // so it will be inferred from the previous branch
        Default::default()
    };
    // depending on the fallback, this may compile (because `()` implements `Default`),
    // or it may not (because `!` does not implement `Default`)
}

This will produce:

error: this function depends on never type fallback being `()`
 --> lint_example.rs:2:1
  |
2 | fn main() {
  | ^^^^^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #123748 <https://github.com/rust-lang/rust/issues/123748>
  = help: specify the types explicitly
note: in edition 2024, the requirement `!: Default` will fail
 --> lint_example.rs:9:9
  |
9 |         Default::default()
  |         ^^^^^^^^^^^^^^^^^^
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(dependency_on_unit_never_type_fallback)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: use `()` annotations to avoid fallback changes
  |
9 |         <() as Default>::default()
  |         ++++++        +

Explanation

Due to historic reasons never type fallback was (), meaning that ! got spontaneously coerced to (). There are plans to change that, but they may make the code such as above not compile. Instead of depending on the fallback, you should specify the type explicitly:

if true {
    return
} else {
    // type is explicitly specified, fallback can't hurt us no more
    <() as Default>::default()
};

See Tracking Issue for making ! fall back to !.

deprecated

The deprecated lint detects use of deprecated items.

Example

#[deprecated]
fn foo() {}

fn bar() {
    foo();
}

This will produce:

warning: use of deprecated function `main::foo`
 --> lint_example.rs:6:5
  |
6 |     foo();
  |     ^^^
  |
  = note: `#[warn(deprecated)]` on by default

Explanation

Items may be marked "deprecated" with the deprecated attribute to indicate that they should no longer be used. Usually the attribute should include a note on what to use instead, or check the documentation.

deprecated-where-clause-location

The deprecated_where_clause_location lint detects when a where clause in front of the equals in an associated type.

Example

trait Trait {
  type Assoc<'a> where Self: 'a;
}

impl Trait for () {
  type Assoc<'a> where Self: 'a = ();
}

This will produce:

warning: where clause not allowed here
 --> lint_example.rs:7:18
  |
7 |   type Assoc<'a> where Self: 'a = ();
  |                  ^^^^^^^^^^^^^^
  |
  = note: see issue #89122 <https://github.com/rust-lang/rust/issues/89122> for more information
  = note: `#[warn(deprecated_where_clause_location)]` on by default
help: move it to the end of the type declaration
  |
7 -   type Assoc<'a> where Self: 'a = ();
7 +   type Assoc<'a>  = () where Self: 'a;
  |

Explanation

The preferred location for where clauses on associated types is after the type. However, for most of generic associated types development, it was only accepted before the equals. To provide a transition period and further evaluate this change, both are currently accepted. At some point in the future, this may be disallowed at an edition boundary; but, that is undecided currently.

deref-into-dyn-supertrait

The deref_into_dyn_supertrait lint is output whenever there is a use of the Deref implementation with a dyn SuperTrait type as Output.

These implementations will become shadowed when the trait_upcasting feature is stabilized. The deref functions will no longer be called implicitly, so there might be behavior change.

Example

#![deny(deref_into_dyn_supertrait)]
#![allow(dead_code)]

use core::ops::Deref;

trait A {}
trait B: A {}
impl<'a> Deref for dyn 'a + B {
    type Target = dyn A;
    fn deref(&self) -> &Self::Target {
        todo!()
    }
}

fn take_a(_: &dyn A) { }

fn take_b(b: &dyn B) {
    take_a(b);
}

This will produce:

error: this `Deref` implementation is covered by an implicit supertrait coercion
  --> lint_example.rs:9:1
   |
9  | impl<'a> Deref for dyn 'a + B {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `dyn B` implements `Deref<Target = dyn A>` which conflicts with supertrait `A`
10 |     type Target = dyn A;
   |     -------------------- target type is a supertrait of `dyn B`
   |
   = warning: this will change its meaning in a future release!
   = note: for more information, see issue #89460 <https://github.com/rust-lang/rust/issues/89460>
note: the lint level is defined here
  --> lint_example.rs:1:9
   |
1  | #![deny(deref_into_dyn_supertrait)]
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

The dyn upcasting coercion feature adds new coercion rules, taking priority over certain other coercion rules, which will cause some behavior change.

deref-nullptr

The deref_nullptr lint detects when an null pointer is dereferenced, which causes undefined behavior.

Example

#![allow(unused)]
use std::ptr;
unsafe {
    let x = &*ptr::null::<i32>();
    let x = ptr::addr_of!(*ptr::null::<i32>());
    let x = *(0 as *const i32);
}

This will produce:

warning: dereferencing a null pointer
 --> lint_example.rs:5:14
  |
5 |     let x = &*ptr::null::<i32>();
  |              ^^^^^^^^^^^^^^^^^^^ this code causes undefined behavior when executed
  |
  = note: `#[warn(deref_nullptr)]` on by default


warning: dereferencing a null pointer
 --> lint_example.rs:7:13
  |
7 |     let x = *(0 as *const i32);
  |             ^^^^^^^^^^^^^^^^^^ this code causes undefined behavior when executed

Explanation

Dereferencing a null pointer causes undefined behavior if it is accessed (loaded from or stored to).

drop-bounds

The drop_bounds lint checks for generics with std::ops::Drop as bounds.

Example

fn foo<T: Drop>() {}

This will produce:

warning: bounds on `T: Drop` are most likely incorrect, consider instead using `std::mem::needs_drop` to detect whether a type can be trivially dropped
 --> lint_example.rs:2:11
  |
2 | fn foo<T: Drop>() {}
  |           ^^^^
  |
  = note: `#[warn(drop_bounds)]` on by default

Explanation

A generic trait bound of the form T: Drop is most likely misleading and not what the programmer intended (they probably should have used std::mem::needs_drop instead).

Drop bounds do not actually indicate whether a type can be trivially dropped or not, because a composite type containing Drop types does not necessarily implement Drop itself. Naïvely, one might be tempted to write an implementation that assumes that a type can be trivially dropped while also supplying a specialization for T: Drop that actually calls the destructor. However, this breaks down e.g. when T is String, which does not implement Drop itself but contains a Vec, which does implement Drop, so assuming T can be trivially dropped would lead to a memory leak here.

Furthermore, the Drop trait only contains one method, Drop::drop, which may not be called explicitly in user code (E0040), so there is really no use case for using Drop in trait bounds, save perhaps for some obscure corner cases, which can use #[allow(drop_bounds)].

dropping-copy-types

The dropping_copy_types lint checks for calls to std::mem::drop with a value that derives the Copy trait.

Example

let x: i32 = 42; // i32 implements Copy
std::mem::drop(x); // A copy of x is passed to the function, leaving the
                   // original unaffected

This will produce:

warning: calls to `std::mem::drop` with a value that implements `Copy` does nothing
 --> lint_example.rs:3:1
  |
3 | std::mem::drop(x); // A copy of x is passed to the function, leaving the
  | ^^^^^^^^^^^^^^^-^
  |                |
  |                argument has type `i32`
  |
  = note: `#[warn(dropping_copy_types)]` on by default
help: use `let _ = ...` to ignore the expression or result
  |
3 - std::mem::drop(x); // A copy of x is passed to the function, leaving the
3 + let _ = x; // A copy of x is passed to the function, leaving the
  |

Explanation

Calling std::mem::drop does nothing for types that implement Copy, since the value will be copied and moved into the function on invocation.

dropping-references

The dropping_references lint checks for calls to std::mem::drop with a reference instead of an owned value.

Example

fn operation_that_requires_mutex_to_be_unlocked() {} // just to make it compile
let mutex = std::sync::Mutex::new(1); // just to make it compile
let mut lock_guard = mutex.lock();
std::mem::drop(&lock_guard); // Should have been drop(lock_guard), mutex
// still locked
operation_that_requires_mutex_to_be_unlocked();

This will produce:

warning: calls to `std::mem::drop` with a reference instead of an owned value does nothing
 --> lint_example.rs:5:1
  |
5 | std::mem::drop(&lock_guard); // Should have been drop(lock_guard), mutex
  | ^^^^^^^^^^^^^^^-----------^
  |                |
  |                argument has type `&Result<MutexGuard<'_, i32>, PoisonError<MutexGuard<'_, i32>>>`
  |
  = note: `#[warn(dropping_references)]` on by default
help: use `let _ = ...` to ignore the expression or result
  |
5 - std::mem::drop(&lock_guard); // Should have been drop(lock_guard), mutex
5 + let _ = &lock_guard; // Should have been drop(lock_guard), mutex
  |

Explanation

Calling drop on a reference will only drop the reference itself, which is a no-op. It will not call the drop method (from the Drop trait implementation) on the underlying referenced value, which is likely what was intended.

duplicate-macro-attributes

The duplicate_macro_attributes lint detects when a #[test]-like built-in macro attribute is duplicated on an item. This lint may trigger on bench, cfg_eval, test and test_case.

Example

#[test]
#[test]
fn foo() {}

This will produce:

warning: duplicated attribute
 --> src/lib.rs:2:1
  |
2 | #[test]
  | ^^^^^^^
  |
  = note: `#[warn(duplicate_macro_attributes)]` on by default

Explanation

A duplicated attribute may erroneously originate from a copy-paste and the effect of it being duplicated may not be obvious or desirable.

For instance, doubling the #[test] attributes registers the test to be run twice with no change to its environment.

dyn-drop

The dyn_drop lint checks for trait objects with std::ops::Drop.

Example

fn foo(_x: Box<dyn Drop>) {}

This will produce:

warning: types that do not implement `Drop` can still have drop glue, consider instead using `std::mem::needs_drop` to detect whether a type is trivially dropped
 --> lint_example.rs:2:20
  |
2 | fn foo(_x: Box<dyn Drop>) {}
  |                    ^^^^
  |
  = note: `#[warn(dyn_drop)]` on by default

Explanation

A trait object bound of the form dyn Drop is most likely misleading and not what the programmer intended.

Drop bounds do not actually indicate whether a type can be trivially dropped or not, because a composite type containing Drop types does not necessarily implement Drop itself. Naïvely, one might be tempted to write a deferred drop system, to pull cleaning up memory out of a latency-sensitive code path, using dyn Drop trait objects. However, this breaks down e.g. when T is String, which does not implement Drop, but should probably be accepted.

To write a trait object bound that accepts anything, use a placeholder trait with a blanket implementation.

trait Placeholder {}
impl<T> Placeholder for T {}
fn foo(_x: Box<dyn Placeholder>) {}

elided-named-lifetimes

The elided_named_lifetimes lint detects when an elided lifetime ends up being a named lifetime, such as 'static or some lifetime parameter 'a.

Example

#![deny(elided_named_lifetimes)]
struct Foo;
impl Foo {
    pub fn get_mut(&'static self, x: &mut u8) -> &mut u8 {
        unsafe { &mut *(x as *mut _) }
    }
}

This will produce:

error: elided lifetime has a name
 --> lint_example.rs:5:50
  |
5 |     pub fn get_mut(&'static self, x: &mut u8) -> &mut u8 {
  |                                                  ^ this elided lifetime gets resolved as `'static`
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(elided_named_lifetimes)]
  |         ^^^^^^^^^^^^^^^^^^^^^^
help: consider specifying it explicitly
  |
5 |     pub fn get_mut(&'static self, x: &mut u8) -> &'static mut u8 {
  |                                                   +++++++

Explanation

Lifetime elision is quite useful, because it frees you from having to give each lifetime its own name, but sometimes it can produce somewhat surprising resolutions. In safe code, it is mostly okay, because the borrow checker prevents any unsoundness, so the worst case scenario is you get a confusing error message in some other place. But with unsafe code, such unexpected resolutions may lead to unsound code.

ellipsis-inclusive-range-patterns

The ellipsis_inclusive_range_patterns lint detects the ... range pattern, which is deprecated.

Example

let x = 123;
match x {
    0...100 => {}
    _ => {}
}

This will produce:

warning: `...` range patterns are deprecated
 --> lint_example.rs:4:6
  |
4 |     0...100 => {}
  |      ^^^ help: use `..=` for an inclusive range
  |
  = warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021!
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html>
  = note: `#[warn(ellipsis_inclusive_range_patterns)]` on by default

Explanation

The ... range pattern syntax was changed to ..= to avoid potential confusion with the .. range expression. Use the new form instead.

exported-private-dependencies

The exported_private_dependencies lint detects private dependencies that are exposed in a public interface.

Example

pub fn foo() -> Option<some_private_dependency::Thing> {
    None
}

This will produce:

warning: type `bar::Thing` from private dependency 'bar' in public interface
 --> src/lib.rs:3:1
  |
3 | pub fn foo() -> Option<bar::Thing> {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(exported_private_dependencies)]` on by default

Explanation

Dependencies can be marked as "private" to indicate that they are not exposed in the public interface of a crate. This can be used by Cargo to independently resolve those dependencies because it can assume it does not need to unify them with other packages using that same dependency. This lint is an indication of a violation of that contract.

To fix this, avoid exposing the dependency in your public interface. Or, switch the dependency to a public dependency.

Note that support for this is only available on the nightly channel. See RFC 1977 for more details, as well as the Cargo documentation.

for-loops-over-fallibles

The for_loops_over_fallibles lint checks for for loops over Option or Result values.

Example

let opt = Some(1);
for x in opt { /* ... */}

This will produce:

warning: for loop over an `Option`. This is more readably written as an `if let` statement
 --> lint_example.rs:3:10
  |
3 | for x in opt { /* ... */}
  |          ^^^
  |
  = note: `#[warn(for_loops_over_fallibles)]` on by default
help: to check pattern in a loop use `while let`
  |
3 | while let Some(x) = opt { /* ... */}
  | ~~~~~~~~~~~~~~~ ~~~
help: consider using `if let` to clear intent
  |
3 | if let Some(x) = opt { /* ... */}
  | ~~~~~~~~~~~~ ~~~

Explanation

Both Option and Result implement IntoIterator trait, which allows using them in a for loop. for loop over Option or Result will iterate either 0 (if the value is None/Err(_)) or 1 time (if the value is Some(_)/Ok(_)). This is not very useful and is more clearly expressed via if let.

for loop can also be accidentally written with the intention to call a function multiple times, while the function returns Some(_), in these cases while let loop should be used instead.

The "intended" use of IntoIterator implementations for Option and Result is passing them to generic code that expects something implementing IntoIterator. For example using .chain(option) to optionally add a value to an iterator.

forbidden-lint-groups

The forbidden_lint_groups lint detects violations of forbid applied to a lint group. Due to a bug in the compiler, these used to be overlooked entirely. They now generate a warning.

Example

#![forbid(warnings)]
#![warn(bad_style)]

fn main() {}

This will produce:

warning: warn(bad_style) incompatible with previous forbid
 --> lint_example.rs:2:9
  |
1 | #![forbid(warnings)]
  |           -------- `forbid` level set here
2 | #![warn(bad_style)]
  |         ^^^^^^^^^ overruled by previous forbid
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #81670 <https://github.com/rust-lang/rust/issues/81670>
  = note: `#[warn(forbidden_lint_groups)]` on by default

Recommended fix

If your crate is using #![forbid(warnings)], we recommend that you change to #![deny(warnings)].

Explanation

Due to a compiler bug, applying forbid to lint groups previously had no effect. The bug is now fixed but instead of enforcing forbid we issue this future-compatibility warning to avoid breaking existing crates.

forgetting-copy-types

The forgetting_copy_types lint checks for calls to std::mem::forget with a value that derives the Copy trait.

Example

let x: i32 = 42; // i32 implements Copy
std::mem::forget(x); // A copy of x is passed to the function, leaving the
                     // original unaffected

This will produce:

warning: calls to `std::mem::forget` with a value that implements `Copy` does nothing
 --> lint_example.rs:3:1
  |
3 | std::mem::forget(x); // A copy of x is passed to the function, leaving the
  | ^^^^^^^^^^^^^^^^^-^
  |                  |
  |                  argument has type `i32`
  |
  = note: `#[warn(forgetting_copy_types)]` on by default
help: use `let _ = ...` to ignore the expression or result
  |
3 - std::mem::forget(x); // A copy of x is passed to the function, leaving the
3 + let _ = x; // A copy of x is passed to the function, leaving the
  |

Explanation

Calling std::mem::forget does nothing for types that implement Copy since the value will be copied and moved into the function on invocation.

An alternative, but also valid, explanation is that Copy types do not implement the Drop trait, which means they have no destructors. Without a destructor, there is nothing for std::mem::forget to ignore.

forgetting-references

The forgetting_references lint checks for calls to std::mem::forget with a reference instead of an owned value.

Example

let x = Box::new(1);
std::mem::forget(&x); // Should have been forget(x), x will still be dropped

This will produce:

warning: calls to `std::mem::forget` with a reference instead of an owned value does nothing
 --> lint_example.rs:3:1
  |
3 | std::mem::forget(&x); // Should have been forget(x), x will still be dropped
  | ^^^^^^^^^^^^^^^^^--^
  |                  |
  |                  argument has type `&Box<i32>`
  |
  = note: `#[warn(forgetting_references)]` on by default
help: use `let _ = ...` to ignore the expression or result
  |
3 - std::mem::forget(&x); // Should have been forget(x), x will still be dropped
3 + let _ = &x; // Should have been forget(x), x will still be dropped
  |

Explanation

Calling forget on a reference will only forget the reference itself, which is a no-op. It will not forget the underlying referenced value, which is likely what was intended.

function-item-references

The function_item_references lint detects function references that are formatted with fmt::Pointer or transmuted.

Example

fn foo() { }

fn main() {
    println!("{:p}", &foo);
}

This will produce:

warning: taking a reference to a function item does not give a function pointer
 --> lint_example.rs:4:22
  |
4 |     println!("{:p}", &foo);
  |                      ^^^^ help: cast `foo` to obtain a function pointer: `foo as fn()`
  |
  = note: `#[warn(function_item_references)]` on by default

Explanation

Taking a reference to a function may be mistaken as a way to obtain a pointer to that function. This can give unexpected results when formatting the reference as a pointer or transmuting it. This lint is issued when function references are formatted as pointers, passed as arguments bound by fmt::Pointer or transmuted.

hidden-glob-reexports

The hidden_glob_reexports lint detects cases where glob re-export items are shadowed by private items.

Example

#![deny(hidden_glob_reexports)]

pub mod upstream {
    mod inner { pub struct Foo {}; pub struct Bar {}; }
    pub use self::inner::*;
    struct Foo {} // private item shadows `inner::Foo`
}

// mod downstream {
//     fn test() {
//         let _ = crate::upstream::Foo; // inaccessible
//     }
// }

pub fn main() {}

This will produce:

error: private item shadows public glob re-export
 --> lint_example.rs:6:5
  |
6 |     struct Foo {} // private item shadows `inner::Foo`
  |     ^^^^^^^^^^^^^
  |
note: the name `Foo` in the type namespace is supposed to be publicly re-exported here
 --> lint_example.rs:5:13
  |
5 |     pub use self::inner::*;
  |             ^^^^^^^^^^^^^^
note: but the private item here shadows it
 --> lint_example.rs:6:5
  |
6 |     struct Foo {} // private item shadows `inner::Foo`
  |     ^^^^^^^^^^^^^
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(hidden_glob_reexports)]
  |         ^^^^^^^^^^^^^^^^^^^^^

Explanation

This was previously accepted without any errors or warnings but it could silently break a crate's downstream user code. If the struct Foo was added, dep::inner::Foo would silently become inaccessible and trigger a "struct Foo is private" visibility error at the downstream use site.

impl-trait-redundant-captures

The impl_trait_redundant_captures lint warns against cases where use of the precise capturing use<...> syntax is not needed.

In the 2024 edition, impl Traits will capture all lifetimes in scope. If precise-capturing use<...> syntax is used, and the set of parameters that are captures are equal to the set of parameters in scope, then the syntax is redundant, and can be removed.

Example

#![feature(lifetime_capture_rules_2024)]
#![deny(impl_trait_redundant_captures)]
fn test<'a>(x: &'a i32) -> impl Sized + use<'a> { x }

This will produce:

error: all possible in-scope parameters are already captured, so `use<...>` syntax is redundant
 --> lint_example.rs:4:28
  |
4 | fn test<'a>(x: &'a i32) -> impl Sized + use<'a> { x }
  |                            ^^^^^^^^^^^^^-------
  |                                         |
  |                                         help: remove the `use<...>` syntax
  |
note: the lint level is defined here
 --> lint_example.rs:2:9
  |
2 | #![deny(impl_trait_redundant_captures)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

To fix this, remove the use<'a>, since the lifetime is already captured since it is in scope.

improper-ctypes

The improper_ctypes lint detects incorrect use of types in foreign modules.

Example

extern "C" {
    static STATIC: String;
}

This will produce:

warning: `extern` block uses type `String`, which is not FFI-safe
 --> lint_example.rs:3:20
  |
3 |     static STATIC: String;
  |                    ^^^^^^ not FFI-safe
  |
  = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct
  = note: this struct has unspecified layout
  = note: `#[warn(improper_ctypes)]` on by default

Explanation

The compiler has several checks to verify that types used in extern blocks are safe and follow certain rules to ensure proper compatibility with the foreign interfaces. This lint is issued when it detects a probable mistake in a definition. The lint usually should provide a description of the issue, along with possibly a hint on how to resolve it.

improper-ctypes-definitions

The improper_ctypes_definitions lint detects incorrect use of extern function definitions.

Example

#![allow(unused)]
pub extern "C" fn str_type(p: &str) { }

This will produce:

warning: `extern` fn uses type `str`, which is not FFI-safe
 --> lint_example.rs:3:31
  |
3 | pub extern "C" fn str_type(p: &str) { }
  |                               ^^^^ not FFI-safe
  |
  = help: consider using `*const u8` and a length instead
  = note: string slices have no C equivalent
  = note: `#[warn(improper_ctypes_definitions)]` on by default

Explanation

There are many parameter and return types that may be specified in an extern function that are not compatible with the given ABI. This lint is an alert that these types should not be used. The lint usually should provide a description of the issue, along with possibly a hint on how to resolve it.

incomplete-features

The incomplete_features lint detects unstable features enabled with the feature attribute that may function improperly in some or all cases.

Example

#![feature(generic_const_exprs)]

This will produce:

warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes
 --> lint_example.rs:1:12
  |
1 | #![feature(generic_const_exprs)]
  |            ^^^^^^^^^^^^^^^^^^^
  |
  = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information
  = note: `#[warn(incomplete_features)]` on by default

Explanation

Although it is encouraged for people to experiment with unstable features, some of them are known to be incomplete or faulty. This lint is a signal that the feature has not yet been finished, and you may experience problems with it.

inline-no-sanitize

The inline_no_sanitize lint detects incompatible use of #[inline(always)] and #[no_sanitize(...)].

Example

#![feature(no_sanitize)]

#[inline(always)]
#[no_sanitize(address)]
fn x() {}

fn main() {
    x()
}

This will produce:

warning: `no_sanitize` will have no effect after inlining
 --> lint_example.rs:4:1
  |
4 | #[no_sanitize(address)]
  | ^^^^^^^^^^^^^^^^^^^^^^^
  |
note: inlining requested here
 --> lint_example.rs:3:1
  |
3 | #[inline(always)]
  | ^^^^^^^^^^^^^^^^^
  = note: `#[warn(inline_no_sanitize)]` on by default

Explanation

The use of the #[inline(always)] attribute prevents the the #[no_sanitize(...)] attribute from working. Consider temporarily removing inline attribute.

internal-features

The internal_features lint detects unstable features enabled with the feature attribute that are internal to the compiler or standard library.

Example

#![feature(rustc_attrs)]

This will produce:

warning: the feature `rustc_attrs` is internal to the compiler or standard library
 --> lint_example.rs:1:12
  |
1 | #![feature(rustc_attrs)]
  |            ^^^^^^^^^^^
  |
  = note: using it is strongly discouraged
  = note: `#[warn(internal_features)]` on by default

Explanation

These features are an implementation detail of the compiler and standard library and are not supposed to be used in user code.

invalid-from-utf8

The invalid_from_utf8 lint checks for calls to std::str::from_utf8 and std::str::from_utf8_mut with a known invalid UTF-8 value.

Example

#[allow(unused)]
std::str::from_utf8(b"Ru\x82st");

This will produce:

warning: calls to `std::str::from_utf8` with a invalid literal always return an error
 --> lint_example.rs:3:1
  |
3 | std::str::from_utf8(b"Ru\x82st");
  | ^^^^^^^^^^^^^^^^^^^^-----------^
  |                     |
  |                     the literal was valid UTF-8 up to the 2 bytes
  |
  = note: `#[warn(invalid_from_utf8)]` on by default

Explanation

Trying to create such a str would always return an error as per documentation for std::str::from_utf8 and std::str::from_utf8_mut.

invalid-macro-export-arguments

The invalid_macro_export_arguments lint detects cases where #[macro_export] is being used with invalid arguments.

Example

#![deny(invalid_macro_export_arguments)]

#[macro_export(invalid_parameter)]
macro_rules! myMacro {
   () => {
        // [...]
   }
}

#[macro_export(too, many, items)]

This will produce:

error: `invalid_parameter` isn't a valid `#[macro_export]` argument
 --> lint_example.rs:4:16
  |
4 | #[macro_export(invalid_parameter)]
  |                ^^^^^^^^^^^^^^^^^
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(invalid_macro_export_arguments)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

The only valid argument is #[macro_export(local_inner_macros)] or no argument (#[macro_export]). You can't have multiple arguments in a #[macro_export(..)], or mention arguments other than local_inner_macros.

invalid-nan-comparisons

The invalid_nan_comparisons lint checks comparison with f32::NAN or f64::NAN as one of the operand.

Example

let a = 2.3f32;
if a == f32::NAN {}

This will produce:

warning: incorrect NaN comparison, NaN cannot be directly compared to itself
 --> lint_example.rs:3:4
  |
3 | if a == f32::NAN {}
  |    ^^^^^^^^^^^^^
  |
  = note: `#[warn(invalid_nan_comparisons)]` on by default
help: use `f32::is_nan()` or `f64::is_nan()` instead
  |
3 - if a == f32::NAN {}
3 + if a.is_nan() {}
  |

Explanation

NaN does not compare meaningfully to anything – not even itself – so those comparisons are always false.

invalid-value

The invalid_value lint detects creating a value that is not valid, such as a null reference.

Example

#![allow(unused)]
unsafe {
    let x: &'static i32 = std::mem::zeroed();
}

This will produce:

warning: the type `&i32` does not permit zero-initialization
 --> lint_example.rs:4:27
  |
4 |     let x: &'static i32 = std::mem::zeroed();
  |                           ^^^^^^^^^^^^^^^^^^
  |                           |
  |                           this code causes undefined behavior when executed
  |                           help: use `MaybeUninit<T>` instead, and only call `assume_init` after initialization is done
  |
  = note: references must be non-null
  = note: `#[warn(invalid_value)]` on by default

Explanation

In some situations the compiler can detect that the code is creating an invalid value, which should be avoided.

In particular, this lint will check for improper use of mem::zeroed, mem::uninitialized, mem::transmute, and MaybeUninit::assume_init that can cause undefined behavior. The lint should provide extra information to indicate what the problem is and a possible solution.

irrefutable-let-patterns

The irrefutable_let_patterns lint detects irrefutable patterns in if lets, while lets, and if let guards.

Example

if let _ = 123 {
    println!("always runs!");
}

This will produce:

warning: irrefutable `if let` pattern
 --> lint_example.rs:2:4
  |
2 | if let _ = 123 {
  |    ^^^^^^^^^^^
  |
  = note: this pattern will always match, so the `if let` is useless
  = help: consider replacing the `if let` with a `let`
  = note: `#[warn(irrefutable_let_patterns)]` on by default

Explanation

There usually isn't a reason to have an irrefutable pattern in an if let or while let statement, because the pattern will always match successfully. A let or loop statement will suffice. However, when generating code with a macro, forbidding irrefutable patterns would require awkward workarounds in situations where the macro doesn't know if the pattern is refutable or not. This lint allows macros to accept this form, while alerting for a possibly incorrect use in normal code.

See RFC 2086 for more details.

large-assignments

The large_assignments lint detects when objects of large types are being moved around.

Example

let x = [0; 50000];
let y = x;

produces:

warning: moving a large value
  --> $DIR/move-large.rs:1:3
  let y = x;
          - Copied large value here

Explanation

When using a large type in a plain assignment or in a function argument, idiomatic code can be inefficient. Ideally appropriate optimizations would resolve this, but such optimizations are only done in a best-effort manner. This lint will trigger on all sites of large moves and thus allow the user to resolve them in code.

late-bound-lifetime-arguments

The late_bound_lifetime_arguments lint detects generic lifetime arguments in path segments with late bound lifetime parameters.

Example

struct S;

impl S {
    fn late(self, _: &u8, _: &u8) {}
}

fn main() {
    S.late::<'static>(&0, &0);
}

This will produce:

warning: cannot specify lifetime arguments explicitly if late bound lifetime parameters are present
 --> lint_example.rs:8:14
  |
4 |     fn late(self, _: &u8, _: &u8) {}
  |                      - the late bound lifetime parameter is introduced here
...
8 |     S.late::<'static>(&0, &0);
  |              ^^^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #42868 <https://github.com/rust-lang/rust/issues/42868>
  = note: `#[warn(late_bound_lifetime_arguments)]` on by default

Explanation

It is not clear how to provide arguments for early-bound lifetime parameters if they are intermixed with late-bound parameters in the same list. For now, providing any explicit arguments will trigger this lint if late-bound parameters are present, so in the future a solution can be adopted without hitting backward compatibility issues. This is a future-incompatible lint to transition this to a hard error in the future. See issue #42868 for more details, along with a description of the difference between early and late-bound parameters.

legacy-derive-helpers

The legacy_derive_helpers lint detects derive helper attributes that are used before they are introduced.

Example

#[serde(rename_all = "camelCase")]
#[derive(Deserialize)]
struct S { /* fields */ }

produces:

warning: derive helper attribute is used before it is introduced
  --> $DIR/legacy-derive-helpers.rs:1:3
   |
 1 | #[serde(rename_all = "camelCase")]
   |   ^^^^^
...
 2 | #[derive(Deserialize)]
   |          ----------- the attribute is introduced here

Explanation

Attributes like this work for historical reasons, but attribute expansion works in left-to-right order in general, so, to resolve #[serde], compiler has to try to "look into the future" at not yet expanded part of the item , but such attempts are not always reliable.

To fix the warning place the helper attribute after its corresponding derive.

#[derive(Deserialize)]
#[serde(rename_all = "camelCase")]
struct S { /* fields */ }

map-unit-fn

The map_unit_fn lint checks for Iterator::map receive a callable that returns ().

Example

fn foo(items: &mut Vec<u8>) {
    items.sort();
}

fn main() {
    let mut x: Vec<Vec<u8>> = vec![
        vec![0, 2, 1],
        vec![5, 4, 3],
    ];
    x.iter_mut().map(foo);
}

This will produce:

warning: `Iterator::map` call that discard the iterator's values
  --> lint_example.rs:10:18
   |
1  | fn foo(items: &mut Vec<u8>) {
   | --------------------------- this function returns `()`, which is likely not what you wanted
...
10 |     x.iter_mut().map(foo);
   |                  ^^^^---^
   |                  |   |
   |                  |   called `Iterator::map` with callable that returns `()`
   |                  after this call to map, the resulting iterator is `impl Iterator<Item = ()>`, which means the only information carried by the iterator is the number of items
   |
   = note: `Iterator::map`, like many of the methods on `Iterator`, gets executed lazily, meaning that its effects won't be visible until it is iterated
   = note: `#[warn(map_unit_fn)]` on by default
help: you might have meant to use `Iterator::for_each`
   |
10 |     x.iter_mut().for_each(foo);
   |                  ~~~~~~~~

Explanation

Mapping to () is almost always a mistake.

mixed-script-confusables

The mixed_script_confusables lint detects visually confusable characters in identifiers between different scripts.

Example

// The Japanese katakana character エ can be confused with the Han character 工.
const エ: &'static str = "アイウ";

This will produce:

warning: the usage of Script Group `Japanese, Katakana` in this crate consists solely of mixed script confusables
 --> lint_example.rs:3:7
  |
3 | const エ: &'static str = "アイウ";
  |       ^^
  |
  = note: the usage includes 'エ' (U+30A8)
  = note: please recheck to make sure their usages are indeed what you want
  = note: `#[warn(mixed_script_confusables)]` on by default

Explanation

This lint warns when characters between different scripts may appear visually similar, which can cause confusion.

If the crate contains other identifiers in the same script that have non-confusable characters, then this lint will not be issued. For example, if the example given above has another identifier with katakana characters (such as let カタカナ = 123;), then this indicates that you are intentionally using katakana, and it will not warn about it.

Note that the set of confusable characters may change over time. Beware that if you "forbid" this lint that existing code may fail in the future.

named-arguments-used-positionally

The named_arguments_used_positionally lint detects cases where named arguments are only used positionally in format strings. This usage is valid but potentially very confusing.

Example

#![deny(named_arguments_used_positionally)]
fn main() {
    let _x = 5;
    println!("{}", _x = 1); // Prints 1, will trigger lint

    println!("{}", _x); // Prints 5, no lint emitted
    println!("{_x}", _x = _x); // Prints 5, no lint emitted
}

This will produce:

error: named argument `_x` is not used by name
 --> lint_example.rs:4:20
  |
4 |     println!("{}", _x = 1); // Prints 1, will trigger lint
  |               --   ^^ this named argument is referred to by position in formatting string
  |               |
  |               this formatting argument uses named argument `_x` by position
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(named_arguments_used_positionally)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: use the named argument by name to avoid ambiguity
  |
4 |     println!("{_x}", _x = 1); // Prints 1, will trigger lint
  |                ++

Explanation

Rust formatting strings can refer to named arguments by their position, but this usage is potentially confusing. In particular, readers can incorrectly assume that the declaration of named arguments is an assignment (which would produce the unit type). For backwards compatibility, this is not a hard error.

never-type-fallback-flowing-into-unsafe

The never_type_fallback_flowing_into_unsafe lint detects cases where never type fallback affects unsafe function calls.

Never type fallback

When the compiler sees a value of type ! it implicitly inserts a coercion (if possible), to allow type check to infer any type:

// this
let x: u8 = panic!();

// is (essentially) turned by the compiler into
let x: u8 = absurd(panic!());

// where absurd is a function with the following signature
// (it's sound, because `!` always marks unreachable code):
fn absurd<T>(never: !) -> T { ... }

While it's convenient to be able to use non-diverging code in one of the branches (like if a { b } else { return }) this could lead to compilation errors:

// this
{ panic!() };

// gets turned into this
{ absurd(panic!()) }; // error: can't infer the type of `absurd`

To prevent such errors, compiler remembers where it inserted absurd calls, and if it can't infer their type, it sets the type to fallback. { absurd::<Fallback>(panic!()) };. This is what is known as "never type fallback".

Example

#![deny(never_type_fallback_flowing_into_unsafe)]
fn main() {
    if true {
        // return has type `!` which, is some cases, causes never type fallback
        return
    } else {
        // `zeroed` is an unsafe function, which returns an unbounded type
        unsafe { std::mem::zeroed() }
    };
    // depending on the fallback, `zeroed` may create `()` (which is completely sound),
    // or `!` (which is instant undefined behavior)
}

This will produce:

error: never type fallback affects this call to an `unsafe` function
 --> lint_example.rs:8:18
  |
8 |         unsafe { std::mem::zeroed() }
  |                  ^^^^^^^^^^^^^^^^^^
  |
  = warning: this will change its meaning in a future release!
  = note: for more information, see issue #123748 <https://github.com/rust-lang/rust/issues/123748>
  = help: specify the type explicitly
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(never_type_fallback_flowing_into_unsafe)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: use `()` annotations to avoid fallback changes
  |
8 |         unsafe { std::mem::zeroed::<()>() }
  |                                  ++++++

Explanation

Due to historic reasons never type fallback was (), meaning that ! got spontaneously coerced to (). There are plans to change that, but they may make the code such as above unsound. Instead of depending on the fallback, you should specify the type explicitly:

if true {
    return
} else {
    // type is explicitly specified, fallback can't hurt us no more
    unsafe { std::mem::zeroed::<()>() }
};

See Tracking Issue for making ! fall back to !.

no-mangle-generic-items

The no_mangle_generic_items lint detects generic items that must be mangled.

Example

#[no_mangle]
fn foo<T>(t: T) {

}

This will produce:

warning: functions generic over types or consts must be mangled
 --> lint_example.rs:3:1
  |
2 |   #[no_mangle]
  |   ------------ help: remove this attribute
3 | / fn foo<T>(t: T) {
4 | |
5 | | }
  | |_^
  |
  = note: `#[warn(no_mangle_generic_items)]` on by default

Explanation

A function with generics must have its symbol mangled to accommodate the generic parameter. The no_mangle attribute has no effect in this situation, and should be removed.

non-fmt-panic

The lint non-fmt-panic has been renamed to non-fmt-panics.

non-camel-case-types

The non_camel_case_types lint detects types, variants, traits and type parameters that don't have camel case names.

Example

struct my_struct;

This will produce:

warning: type `my_struct` should have an upper camel case name
 --> lint_example.rs:2:8
  |
2 | struct my_struct;
  |        ^^^^^^^^^ help: convert the identifier to upper camel case: `MyStruct`
  |
  = note: `#[warn(non_camel_case_types)]` on by default

Explanation

The preferred style for these identifiers is to use "camel case", such as MyStruct, where the first letter should not be lowercase, and should not use underscores between letters. Underscores are allowed at the beginning and end of the identifier, as well as between non-letters (such as X86_64).

non-contiguous-range-endpoints

The non_contiguous_range_endpoints lint detects likely off-by-one errors when using exclusive range patterns.

Example

let x = 123u32;
match x {
    0..100 => { println!("small"); }
    101..1000 => { println!("large"); }
    _ => { println!("larger"); }
}

This will produce:

warning: multiple ranges are one apart
 --> lint_example.rs:4:5
  |
4 |     0..100 => { println!("small"); }
  |     ^^^^^^
  |     |
  |     this range doesn't match `100_u32` because `..` is an exclusive range
  |     help: use an inclusive range instead: `0_u32..=100_u32`
5 |     101..1000 => { println!("large"); }
  |     --------- this could appear to continue range `0_u32..100_u32`, but `100_u32` isn't matched by either of them
  |
  = note: `#[warn(non_contiguous_range_endpoints)]` on by default

Explanation

It is likely a mistake to have range patterns in a match expression that miss out a single number. Check that the beginning and end values are what you expect, and keep in mind that with ..= the right bound is inclusive, and with .. it is exclusive.

non-fmt-panics

The non_fmt_panics lint detects panic!(..) invocations where the first argument is not a formatting string.

Example

panic!("{}");
panic!(123);

This will produce:

warning: panic message contains an unused formatting placeholder
 --> lint_example.rs:2:9
  |
2 | panic!("{}");
  |         ^^
  |
  = note: this message is not used as a format string when given without arguments, but will be in Rust 2021
  = note: `#[warn(non_fmt_panics)]` on by default
help: add the missing argument
  |
2 | panic!("{}", ...);
  |            +++++
help: or add a "{}" format string to use the message literally
  |
2 | panic!("{}", "{}");
  |        +++++


warning: panic message is not a string literal
 --> lint_example.rs:3:8
  |
3 | panic!(123);
  |        ^^^
  |
  = note: this usage of `panic!()` is deprecated; it will be a hard error in Rust 2021
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/panic-macro-consistency.html>
help: add a "{}" format string to `Display` the message
  |
3 | panic!("{}", 123);
  |        +++++
help: or use std::panic::panic_any instead
  |
3 | std::panic::panic_any(123);
  | ~~~~~~~~~~~~~~~~~~~~~

Explanation

In Rust 2018 and earlier, panic!(x) directly uses x as the message. That means that panic!("{}") panics with the message "{}" instead of using it as a formatting string, and panic!(123) will panic with an i32 as message.

Rust 2021 always interprets the first argument as format string.

non-local-definitions

The non_local_definitions lint checks for impl blocks and #[macro_export] macro inside bodies (functions, enum discriminant, ...).

Example

#![warn(non_local_definitions)]
trait MyTrait {}
struct MyStruct;

fn foo() {
    impl MyTrait for MyStruct {}
}

This will produce:

warning: non-local `impl` definition, `impl` blocks should be written at the same level as their item
 --> lint_example.rs:7:5
  |
6 | fn foo() {
  | -------- move the `impl` block outside of this function `foo` and up 2 bodies
7 |     impl MyTrait for MyStruct {}
  |     ^^^^^-------^^^^^--------
  |          |           |
  |          |           `MyStruct` is not local
  |          `MyTrait` is not local
  |
  = note: an `impl` is never scoped, even when it is nested inside an item, as it may impact type checking outside of that item, which can be the case if neither the trait or the self type are at the same nesting level as the `impl`
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![warn(non_local_definitions)]
  |         ^^^^^^^^^^^^^^^^^^^^^

Explanation

Creating non-local definitions go against expectation and can create discrepancies in tooling. It should be avoided. It may become deny-by-default in edition 2024 and higher, see the tracking issue https://github.com/rust-lang/rust/issues/120363.

An impl definition is non-local if it is nested inside an item and neither the type nor the trait are at the same nesting level as the impl block.

All nested bodies (functions, enum discriminant, array length, consts) (expect for const _: Ty = { ... } in top-level module, which is still undecided) are checked.

non-shorthand-field-patterns

The non_shorthand_field_patterns lint detects using Struct { x: x } instead of Struct { x } in a pattern.

Example

struct Point {
    x: i32,
    y: i32,
}


fn main() {
    let p = Point {
        x: 5,
        y: 5,
    };

    match p {
        Point { x: x, y: y } => (),
    }
}

This will produce:

warning: the `x:` in this pattern is redundant
  --> lint_example.rs:14:17
   |
14 |         Point { x: x, y: y } => (),
   |                 ^^^^ help: use shorthand field pattern: `x`
   |
   = note: `#[warn(non_shorthand_field_patterns)]` on by default


warning: the `y:` in this pattern is redundant
  --> lint_example.rs:14:23
   |
14 |         Point { x: x, y: y } => (),
   |                       ^^^^ help: use shorthand field pattern: `y`

Explanation

The preferred style is to avoid the repetition of specifying both the field name and the binding name if both identifiers are the same.

non-snake-case

The non_snake_case lint detects variables, methods, functions, lifetime parameters and modules that don't have snake case names.

Example

let MY_VALUE = 5;

This will produce:

warning: variable `MY_VALUE` should have a snake case name
 --> lint_example.rs:2:5
  |
2 | let MY_VALUE = 5;
  |     ^^^^^^^^ help: convert the identifier to snake case: `my_value`
  |
  = note: `#[warn(non_snake_case)]` on by default

Explanation

The preferred style for these identifiers is to use "snake case", where all the characters are in lowercase, with words separated with a single underscore, such as my_value.

non-upper-case-globals

The non_upper_case_globals lint detects static items that don't have uppercase identifiers.

Example

static max_points: i32 = 5;

This will produce:

warning: static variable `max_points` should have an upper case name
 --> lint_example.rs:2:8
  |
2 | static max_points: i32 = 5;
  |        ^^^^^^^^^^ help: convert the identifier to upper case: `MAX_POINTS`
  |
  = note: `#[warn(non_upper_case_globals)]` on by default

Explanation

The preferred style is for static item names to use all uppercase letters such as MAX_POINTS.

noop-method-call

The noop_method_call lint detects specific calls to noop methods such as a calling <&T as Clone>::clone where T: !Clone.

Example

#![allow(unused)]
struct Foo;
let foo = &Foo;
let clone: &Foo = foo.clone();

This will produce:

warning: call to `.clone()` on a reference in this situation does nothing
 --> lint_example.rs:5:22
  |
5 | let clone: &Foo = foo.clone();
  |                      ^^^^^^^^
  |
  = note: the type `Foo` does not implement `Clone`, so calling `clone` on `&Foo` copies the reference, which does not do anything and can be removed
  = note: `#[warn(noop_method_call)]` on by default
help: remove this redundant call
  |
5 - let clone: &Foo = foo.clone();
5 + let clone: &Foo = foo;
  |
help: if you meant to clone `Foo`, implement `Clone` for it
  |
3 + #[derive(Clone)]
4 | struct Foo;
  |

Explanation

Some method calls are noops meaning that they do nothing. Usually such methods are the result of blanket implementations that happen to create some method invocations that end up not doing anything. For instance, Clone is implemented on all &T, but calling clone on a &T where T does not implement clone, actually doesn't do anything as references are copy. This lint detects these calls and warns the user about them.

opaque-hidden-inferred-bound

The opaque_hidden_inferred_bound lint detects cases in which nested impl Trait in associated type bounds are not written generally enough to satisfy the bounds of the associated type.

Explanation

This functionality was removed in #97346, but then rolled back in #99860 because it caused regressions.

We plan on reintroducing this as a hard error, but in the meantime, this lint serves to warn and suggest fixes for any use-cases which rely on this behavior.

Example

#![feature(type_alias_impl_trait)]

trait Duh {}

impl Duh for i32 {}

trait Trait {
    type Assoc: Duh;
}

impl<F: Duh> Trait for F {
    type Assoc = F;
}

type Tait = impl Sized;

fn test() -> impl Trait<Assoc = Tait> {
    42
}

fn main() {}

This will produce:

warning: opaque type `impl Trait<Assoc = Tait>` does not satisfy its associated type bounds
  --> lint_example.rs:17:25
   |
8  |     type Assoc: Duh;
   |                 --- this associated type bound is unsatisfied for `Tait`
...
17 | fn test() -> impl Trait<Assoc = Tait> {
   |                         ^^^^^^^^^^^^
   |
   = note: `#[warn(opaque_hidden_inferred_bound)]` on by default

In this example, test declares that the associated type Assoc for impl Trait is impl Sized, which does not satisfy the bound Duh on the associated type.

Although the hidden type, i32 does satisfy this bound, we do not consider the return type to be well-formed with this lint. It can be fixed by changing Tait = impl Sized into Tait = impl Sized + Duh.

out-of-scope-macro-calls

The out_of_scope_macro_calls lint detects macro_rules called when they are not in scope, above their definition, which may happen in key-value attributes.

Example

#![doc = in_root!()]

macro_rules! in_root { () => { "" } }

fn main() {}

This will produce:

warning: cannot find macro `in_root` in this scope
 --> lint_example.rs:1:10
  |
1 | #![doc = in_root!()]
  |          ^^^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #124535 <https://github.com/rust-lang/rust/issues/124535>
  = help: import `macro_rules` with `use` to make it callable above its definition
  = note: `#[warn(out_of_scope_macro_calls)]` on by default

Explanation

The scope in which a macro_rules item is visible starts at that item and continues below it. This is more similar to let than to other items, which are in scope both above and below their definition. Due to a bug macro_rules were accidentally in scope inside some key-value attributes above their definition. The lint catches such cases. To address the issue turn the macro_rules into a regularly scoped item by importing it with use.

This is a future-incompatible lint to transition this to a hard error in the future.

overlapping-patterns

The lint overlapping-patterns has been renamed to overlapping-range-endpoints.

overlapping-range-endpoints

The overlapping_range_endpoints lint detects match arms that have range patterns that overlap on their endpoints.

Example

let x = 123u8;
match x {
    0..=100 => { println!("small"); }
    100..=255 => { println!("large"); }
}

This will produce:

warning: multiple patterns overlap on their endpoints
 --> lint_example.rs:5:5
  |
4 |     0..=100 => { println!("small"); }
  |     ------- this range overlaps on `100_u8`...
5 |     100..=255 => { println!("large"); }
  |     ^^^^^^^^^ ... with this range
  |
  = note: you likely meant to write mutually exclusive ranges
  = note: `#[warn(overlapping_range_endpoints)]` on by default

Explanation

It is likely a mistake to have range patterns in a match expression that overlap in this way. Check that the beginning and end values are what you expect, and keep in mind that with ..= the left and right bounds are inclusive.

path-statements

The path_statements lint detects path statements with no effect.

Example

let x = 42;

x;

This will produce:

warning: path statement with no effect
 --> lint_example.rs:4:1
  |
4 | x;
  | ^^
  |
  = note: `#[warn(path_statements)]` on by default

Explanation

It is usually a mistake to have a statement that has no effect.

private-bounds

The private_bounds lint detects types in a secondary interface of an item, that are more private than the item itself. Secondary interface of an item consists of bounds on generic parameters and where clauses, including supertraits for trait items.

Example

#![allow(unused)]
#![deny(private_bounds)]

struct PrivTy;
pub struct S
    where PrivTy:
{}
fn main() {}

This will produce:

error: type `PrivTy` is more private than the item `S`
 --> lint_example.rs:5:1
  |
5 | pub struct S
  | ^^^^^^^^^^^^ struct `S` is reachable at visibility `pub`
  |
note: but type `PrivTy` is only usable at visibility `pub(crate)`
 --> lint_example.rs:4:1
  |
4 | struct PrivTy;
  | ^^^^^^^^^^^^^
note: the lint level is defined here
 --> lint_example.rs:2:9
  |
2 | #![deny(private_bounds)]
  |         ^^^^^^^^^^^^^^

Explanation

Having private types or traits in item bounds makes it less clear what interface the item actually provides.

private-interfaces

The private_interfaces lint detects types in a primary interface of an item, that are more private than the item itself. Primary interface of an item is all its interface except for bounds on generic parameters and where clauses.

Example

#![allow(unused)]
#![deny(private_interfaces)]
struct SemiPriv;

mod m1 {
    struct Priv;
    impl crate::SemiPriv {
        pub fn f(_: Priv) {}
    }
}

fn main() {}

This will produce:

error: type `Priv` is more private than the item `m1::<impl SemiPriv>::f`
 --> lint_example.rs:8:9
  |
8 |         pub fn f(_: Priv) {}
  |         ^^^^^^^^^^^^^^^^^ associated function `m1::<impl SemiPriv>::f` is reachable at visibility `pub(crate)`
  |
note: but type `Priv` is only usable at visibility `pub(self)`
 --> lint_example.rs:6:5
  |
6 |     struct Priv;
  |     ^^^^^^^^^^^
note: the lint level is defined here
 --> lint_example.rs:2:9
  |
2 | #![deny(private_interfaces)]
  |         ^^^^^^^^^^^^^^^^^^

Explanation

Having something private in primary interface guarantees that the item will be unusable from outer modules due to type privacy.

private-macro-use

The private_macro_use lint detects private macros that are imported with #[macro_use].

Example

// extern_macro.rs
macro_rules! foo_ { () => {}; }
use foo_ as foo;

// code.rs

#![deny(private_macro_use)]

#[macro_use]
extern crate extern_macro;

fn main() {
    foo!();
}

This will produce:

error: cannot find macro `foo` in this scope

Explanation

This lint arises from overlooking visibility checks for macros in an external crate.

This is a future-incompatible lint to transition this to a hard error in the future.

ptr-cast-add-auto-to-object

The ptr_cast_add_auto_to_object lint detects casts of raw pointers to trait objects, which add auto traits.

Example

let ptr: *const dyn core::any::Any = &();
_ = ptr as *const dyn core::any::Any + Send;

This will produce:

warning: adding an auto trait `Send` to a trait object in a pointer cast may cause UB later on
 --> lint_example.rs:3:5
  |
3 | _ = ptr as *const dyn core::any::Any + Send;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #127323 <https://github.com/rust-lang/rust/issues/127323>
  = note: `#[warn(ptr_cast_add_auto_to_object)]` on by default

Explanation

Adding an auto trait can make the vtable invalid, potentially causing UB in safe code afterwards. For example:

#![feature(arbitrary_self_types)]

trait Trait {
    fn f(self: *const Self)
    where
        Self: Send;
}

impl Trait for *const () {
    fn f(self: *const Self) {
        unreachable!()
    }
}

fn main() {
    let unsend: *const () = &();
    let unsend: *const dyn Trait = &unsend;
    let send_bad: *const (dyn Trait + Send) = unsend as _;
    send_bad.f(); // this crashes, since vtable for `*const ()` does not have an entry for `f`
}

Generally you must ensure that vtable is right for the pointer's type, before passing the pointer to safe code.

ptr-to-integer-transmute-in-consts

The ptr_to_integer_transmute_in_consts lint detects pointer to integer transmute in const functions and associated constants.

Example

const fn foo(ptr: *const u8) -> usize {
   unsafe {
       std::mem::transmute::<*const u8, usize>(ptr)
   }
}

This will produce:

warning: pointers cannot be transmuted to integers during const eval
 --> lint_example.rs:4:8
  |
4 |        std::mem::transmute::<*const u8, usize>(ptr)
  |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: at compile-time, pointers do not have an integer value
  = note: avoiding this restriction via `union` or raw pointers leads to compile-time undefined behavior
  = help: for more information, see https://doc.rust-lang.org/std/mem/fn.transmute.html
  = note: `#[warn(ptr_to_integer_transmute_in_consts)]` on by default

Explanation

Transmuting pointers to integers in a const context is undefined behavior. Any attempt to use the resulting integer will abort const-evaluation.

But sometimes the compiler might not emit an error for pointer to integer transmutes inside const functions and associated consts because they are evaluated only when referenced. Therefore, this lint serves as an extra layer of defense to prevent any undefined behavior from compiling without any warnings or errors.

See std::mem::transmute in the reference for more details.

redundant-semicolon

The lint redundant-semicolon has been renamed to redundant-semicolons.

redundant-semicolons

The redundant_semicolons lint detects unnecessary trailing semicolons.

Example

let _ = 123;;

This will produce:

warning: unnecessary trailing semicolon
 --> lint_example.rs:2:13
  |
2 | let _ = 123;;
  |             ^ help: remove this semicolon
  |
  = note: `#[warn(redundant_semicolons)]` on by default

Explanation

Extra semicolons are not needed, and may be removed to avoid confusion and visual clutter.

refining-impl-trait-internal

The refining_impl_trait_internal lint detects impl Trait return types in method signatures that are refined by a trait implementation, meaning the implementation adds information about the return type that is not present in the trait.

Example

#![deny(refining_impl_trait)]

use std::fmt::Display;

trait AsDisplay {
    fn as_display(&self) -> impl Display;
}

impl<'s> AsDisplay for &'s str {
    fn as_display(&self) -> Self {
        *self
    }
}

fn main() {
    // users can observe that the return type of
    // `<&str as AsDisplay>::as_display()` is `&str`.
    let _x: &str = "".as_display();
}

This will produce:

error: impl trait in impl method signature does not match trait method signature
  --> lint_example.rs:10:29
   |
6  |     fn as_display(&self) -> impl Display;
   |                             ------------ return type from trait method defined here
...
10 |     fn as_display(&self) -> Self {
   |                             ^^^^
   |
   = note: add `#[allow(refining_impl_trait)]` if it is intended for this to be part of the public API of this crate
   = note: we are soliciting feedback, see issue #121718 <https://github.com/rust-lang/rust/issues/121718> for more information
note: the lint level is defined here
  --> lint_example.rs:1:9
   |
1  | #![deny(refining_impl_trait)]
   |         ^^^^^^^^^^^^^^^^^^^
   = note: `#[deny(refining_impl_trait_internal)]` implied by `#[deny(refining_impl_trait)]`
help: replace the return type so that it matches the trait
   |
10 |     fn as_display(&self) -> impl std::fmt::Display {
   |                             ~~~~~~~~~~~~~~~~~~~~~~

Explanation

Callers of methods for types where the implementation is known are able to observe the types written in the impl signature. This may be intended behavior, but may also lead to implementation details being revealed unintentionally. In particular, it may pose a semver hazard for authors of libraries who do not wish to make stronger guarantees about the types than what is written in the trait signature.

refining_impl_trait is a lint group composed of two lints:

• refining_impl_trait_reachable, for refinements that are publically reachable outside a crate, and
• refining_impl_trait_internal, for refinements that are only visible within a crate.

We are seeking feedback on each of these lints; see issue #121718 for more information.

refining-impl-trait-reachable

The refining_impl_trait_reachable lint detects impl Trait return types in method signatures that are refined by a publically reachable trait implementation, meaning the implementation adds information about the return type that is not present in the trait.

Example

#![deny(refining_impl_trait)]

use std::fmt::Display;

pub trait AsDisplay {
    fn as_display(&self) -> impl Display;
}

impl<'s> AsDisplay for &'s str {
    fn as_display(&self) -> Self {
        *self
    }
}

fn main() {
    // users can observe that the return type of
    // `<&str as AsDisplay>::as_display()` is `&str`.
    let _x: &str = "".as_display();
}

This will produce:

error: impl trait in impl method signature does not match trait method signature
  --> lint_example.rs:10:29
   |
6  |     fn as_display(&self) -> impl Display;
   |                             ------------ return type from trait method defined here
...
10 |     fn as_display(&self) -> Self {
   |                             ^^^^
   |
   = note: add `#[allow(refining_impl_trait)]` if it is intended for this to be part of the public API of this crate
   = note: we are soliciting feedback, see issue #121718 <https://github.com/rust-lang/rust/issues/121718> for more information
note: the lint level is defined here
  --> lint_example.rs:1:9
   |
1  | #![deny(refining_impl_trait)]
   |         ^^^^^^^^^^^^^^^^^^^
   = note: `#[deny(refining_impl_trait_reachable)]` implied by `#[deny(refining_impl_trait)]`
help: replace the return type so that it matches the trait
   |
10 |     fn as_display(&self) -> impl std::fmt::Display {
   |                             ~~~~~~~~~~~~~~~~~~~~~~

Explanation

Callers of methods for types where the implementation is known are able to observe the types written in the impl signature. This may be intended behavior, but may also lead to implementation details being revealed unintentionally. In particular, it may pose a semver hazard for authors of libraries who do not wish to make stronger guarantees about the types than what is written in the trait signature.

refining_impl_trait is a lint group composed of two lints:

• refining_impl_trait_reachable, for refinements that are publically reachable outside a crate, and
• refining_impl_trait_internal, for refinements that are only visible within a crate.

We are seeking feedback on each of these lints; see issue #121718 for more information.

renamed-and-removed-lints

The renamed_and_removed_lints lint detects lints that have been renamed or removed.

Example

#![deny(raw_pointer_derive)]

This will produce:

warning: lint `raw_pointer_derive` has been removed: using derive with raw pointers is ok
 --> lint_example.rs:1:9
  |
1 | #![deny(raw_pointer_derive)]
  |         ^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(renamed_and_removed_lints)]` on by default

Explanation

To fix this, either remove the lint or use the new name. This can help avoid confusion about lints that are no longer valid, and help maintain consistency for renamed lints.

repr-transparent-external-private-fields

The repr_transparent_external_private_fields lint detects types marked #[repr(transparent)] that (transitively) contain an external ZST type marked #[non_exhaustive] or containing private fields

Example

#![deny(repr_transparent_external_private_fields)]
use foo::NonExhaustiveZst;

#[repr(transparent)]
struct Bar(u32, ([u32; 0], NonExhaustiveZst));

This will produce:

error: zero-sized fields in repr(transparent) cannot contain external non-exhaustive types
 --> src/main.rs:5:28
  |
5 | struct Bar(u32, ([u32; 0], NonExhaustiveZst));
  |                            ^^^^^^^^^^^^^^^^
  |
note: the lint level is defined here
 --> src/main.rs:1:9
  |
1 | #![deny(repr_transparent_external_private_fields)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #78586 <https://github.com/rust-lang/rust/issues/78586>
  = note: this struct contains `NonExhaustiveZst`, which is marked with `#[non_exhaustive]`, and makes it not a breaking change to become non-zero-sized in the future.

Explanation

Previous, Rust accepted fields that contain external private zero-sized types, even though it should not be a breaking change to add a non-zero-sized field to that private type.

This is a future-incompatible lint to transition this to a hard error in the future. See issue #78586 for more details.

self-constructor-from-outer-item

The self_constructor_from_outer_item lint detects cases where the Self constructor was silently allowed due to a bug in the resolver, and which may produce surprising and unintended behavior.

Using a Self type alias from an outer item was never intended, but was silently allowed. This is deprecated -- and is a hard error when the Self type alias references generics that are not in scope.

Example

#![deny(self_constructor_from_outer_item)]

struct S0(usize);

impl S0 {
    fn foo() {
        const C: S0 = Self(0);
        fn bar() -> S0 {
            Self(0)
        }
    }
}

This will produce:

error: can't reference `Self` constructor from outer item
 --> lint_example.rs:8:23
  |
6 | impl S0 {
  | ------- the inner item doesn't inherit generics from this impl, so `Self` is invalid to reference
7 |     fn foo() {
8 |         const C: S0 = Self(0);
  |                       ^^^^ help: replace `Self` with the actual type: `S0`
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #124186 <https://github.com/rust-lang/rust/issues/124186>
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(self_constructor_from_outer_item)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


error: can't reference `Self` constructor from outer item
  --> lint_example.rs:10:13
   |
6  | impl S0 {
   | ------- the inner item doesn't inherit generics from this impl, so `Self` is invalid to reference
...
10 |             Self(0)
   |             ^^^^ help: replace `Self` with the actual type: `S0`
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #124186 <https://github.com/rust-lang/rust/issues/124186>

Explanation

The Self type alias should not be reachable because nested items are not associated with the scope of the parameters from the parent item.

semicolon-in-expressions-from-macros

The semicolon_in_expressions_from_macros lint detects trailing semicolons in macro bodies when the macro is invoked in expression position. This was previous accepted, but is being phased out.

Example

#![deny(semicolon_in_expressions_from_macros)]
macro_rules! foo {
    () => { true; }
}

fn main() {
    let val = match true {
        true => false,
        _ => foo!()
    };
}

This will produce:

error: trailing semicolon in macro used in expression position
 --> lint_example.rs:3:17
  |
3 |     () => { true; }
  |                 ^
...
9 |         _ => foo!()
  |              ------ in this macro invocation
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(semicolon_in_expressions_from_macros)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = note: this error originates in the macro `foo` (in Nightly builds, run with -Z macro-backtrace for more info)

Explanation

Previous, Rust ignored trailing semicolon in a macro body when a macro was invoked in expression position. However, this makes the treatment of semicolons in the language inconsistent, and could lead to unexpected runtime behavior in some circumstances (e.g. if the macro author expects a value to be dropped).

This is a future-incompatible lint to transition this to a hard error in the future. See issue #79813 for more details.

special-module-name

The special_module_name lint detects module declarations for files that have a special meaning.

Example

mod lib;

fn main() {
    lib::run();
}

This will produce:

warning: found module declaration for lib.rs
 --> lint_example.rs:1:1
  |
1 | mod lib;
  | ^^^^^^^^
  |
  = note: lib.rs is the root of this crate's library target
  = help: to refer to it from other targets, use the library's name as the path
  = note: `#[warn(special_module_name)]` on by default

Explanation

Cargo recognizes lib.rs and main.rs as the root of a library or binary crate, so declaring them as modules will lead to miscompilation of the crate unless configured explicitly.

To access a library from a binary target within the same crate, use your_crate_name:: as the path instead of lib:::

// bar/src/lib.rs
fn run() {
    // ...
}

// bar/src/main.rs
fn main() {
    bar::run();
}

Binary targets cannot be used as libraries and so declaring one as a module is not allowed.

stable-features

The stable_features lint detects a feature attribute that has since been made stable.

Example

#![feature(test_accepted_feature)]
fn main() {}

This will produce:

warning: the feature `test_accepted_feature` has been stable since 1.0.0 and no longer requires an attribute to enable
 --> lint_example.rs:1:12
  |
1 | #![feature(test_accepted_feature)]
  |            ^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(stable_features)]` on by default

Explanation

When a feature is stabilized, it is no longer necessary to include a #![feature] attribute for it. To fix, simply remove the #![feature] attribute.

static-mut-ref

The lint static-mut-ref has been renamed to static-mut-refs.

static-mut-refs

The static_mut_refs lint checks for shared or mutable references of mutable static inside unsafe blocks and unsafe functions.

Example

fn main() {
    static mut X: i32 = 23;
    static mut Y: i32 = 24;

    unsafe {
        let y = &X;
        let ref x = X;
        let (x, y) = (&X, &Y);
        foo(&X);
    }
}

unsafe fn _foo() {
    static mut X: i32 = 23;
    static mut Y: i32 = 24;

    let y = &X;
    let ref x = X;
    let (x, y) = (&X, &Y);
    foo(&X);
}

fn foo<'a>(_x: &'a i32) {}

This will produce:

warning: creating a shared reference to mutable static is discouraged
 --> lint_example.rs:6:17
  |
6 |         let y = &X;
  |                 ^^ shared reference to mutable static
  |
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/static-mut-references.html>
  = note: shared references to mutable statics are dangerous; it's undefined behavior if the static is mutated or if a mutable reference is created for it while the shared reference lives
  = note: `#[warn(static_mut_refs)]` on by default
help: use `&raw const` instead to create a raw pointer
  |
6 |         let y = &raw const X;
  |                 ~~~~~~~~~~


warning: creating a shared reference to mutable static is discouraged
 --> lint_example.rs:7:21
  |
7 |         let ref x = X;
  |                     ^ shared reference to mutable static
  |
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/static-mut-references.html>
  = note: shared references to mutable statics are dangerous; it's undefined behavior if the static is mutated or if a mutable reference is created for it while the shared reference lives


warning: creating a shared reference to mutable static is discouraged
 --> lint_example.rs:8:23
  |
8 |         let (x, y) = (&X, &Y);
  |                       ^^ shared reference to mutable static
  |
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/static-mut-references.html>
  = note: shared references to mutable statics are dangerous; it's undefined behavior if the static is mutated or if a mutable reference is created for it while the shared reference lives
help: use `&raw const` instead to create a raw pointer
  |
8 |         let (x, y) = (&raw const X, &Y);
  |                       ~~~~~~~~~~


warning: creating a shared reference to mutable static is discouraged
 --> lint_example.rs:8:27
  |
8 |         let (x, y) = (&X, &Y);
  |                           ^^ shared reference to mutable static
  |
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/static-mut-references.html>
  = note: shared references to mutable statics are dangerous; it's undefined behavior if the static is mutated or if a mutable reference is created for it while the shared reference lives
help: use `&raw const` instead to create a raw pointer
  |
8 |         let (x, y) = (&X, &raw const Y);
  |                           ~~~~~~~~~~


warning: creating a shared reference to mutable static is discouraged
 --> lint_example.rs:9:13
  |
9 |         foo(&X);
  |             ^^ shared reference to mutable static
  |
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/static-mut-references.html>
  = note: shared references to mutable statics are dangerous; it's undefined behavior if the static is mutated or if a mutable reference is created for it while the shared reference lives
help: use `&raw const` instead to create a raw pointer
  |
9 |         foo(&raw const X);
  |             ~~~~~~~~~~


warning: creating a shared reference to mutable static is discouraged
  --> lint_example.rs:17:13
   |
17 |     let y = &X;
   |             ^^ shared reference to mutable static
   |
   = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/static-mut-references.html>
   = note: shared references to mutable statics are dangerous; it's undefined behavior if the static is mutated or if a mutable reference is created for it while the shared reference lives
help: use `&raw const` instead to create a raw pointer
   |
17 |     let y = &raw const X;
   |             ~~~~~~~~~~


warning: creating a shared reference to mutable static is discouraged
  --> lint_example.rs:18:17
   |
18 |     let ref x = X;
   |                 ^ shared reference to mutable static
   |
   = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/static-mut-references.html>
   = note: shared references to mutable statics are dangerous; it's undefined behavior if the static is mutated or if a mutable reference is created for it while the shared reference lives


warning: creating a shared reference to mutable static is discouraged
  --> lint_example.rs:19:19
   |
19 |     let (x, y) = (&X, &Y);
   |                   ^^ shared reference to mutable static
   |
   = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/static-mut-references.html>
   = note: shared references to mutable statics are dangerous; it's undefined behavior if the static is mutated or if a mutable reference is created for it while the shared reference lives
help: use `&raw const` instead to create a raw pointer
   |
19 |     let (x, y) = (&raw const X, &Y);
   |                   ~~~~~~~~~~


warning: creating a shared reference to mutable static is discouraged
  --> lint_example.rs:19:23
   |
19 |     let (x, y) = (&X, &Y);
   |                       ^^ shared reference to mutable static
   |
   = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/static-mut-references.html>
   = note: shared references to mutable statics are dangerous; it's undefined behavior if the static is mutated or if a mutable reference is created for it while the shared reference lives
help: use `&raw const` instead to create a raw pointer
   |
19 |     let (x, y) = (&X, &raw const Y);
   |                       ~~~~~~~~~~


warning: creating a shared reference to mutable static is discouraged
  --> lint_example.rs:20:9
   |
20 |     foo(&X);
   |         ^^ shared reference to mutable static
   |
   = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/static-mut-references.html>
   = note: shared references to mutable statics are dangerous; it's undefined behavior if the static is mutated or if a mutable reference is created for it while the shared reference lives
help: use `&raw const` instead to create a raw pointer
   |
20 |     foo(&raw const X);
   |         ~~~~~~~~~~

Explanation

Shared or mutable references of mutable static are almost always a mistake and can lead to undefined behavior and various other problems in your code.

This lint is "warn" by default on editions up to 2021, in 2024 is "deny".

suspicious-double-ref-op

The suspicious_double_ref_op lint checks for usage of .clone()/.borrow()/.deref() on an &&T when T: !Deref/Borrow/Clone, which means the call will return the inner &T, instead of performing the operation on the underlying T and can be confusing.

Example

#![allow(unused)]
struct Foo;
let foo = &&Foo;
let clone: &Foo = foo.clone();

This will produce:

warning: using `.clone()` on a double reference, which returns `&Foo` instead of cloning the inner type
 --> lint_example.rs:5:22
  |
5 | let clone: &Foo = foo.clone();
  |                      ^^^^^^^^
  |
  = note: `#[warn(suspicious_double_ref_op)]` on by default

Explanation

Since Foo doesn't implement Clone, running .clone() only dereferences the double reference, instead of cloning the inner type which should be what was intended.

trivial-bounds

The trivial_bounds lint detects trait bounds that don't depend on any type parameters.

Example

#![feature(trivial_bounds)]
pub struct A where i32: Copy;

This will produce:

warning: trait bound i32: Copy does not depend on any type or lifetime parameters
 --> lint_example.rs:3:25
  |
3 | pub struct A where i32: Copy;
  |                         ^^^^
  |
  = note: `#[warn(trivial_bounds)]` on by default

Explanation

Usually you would not write a trait bound that you know is always true, or never true. However, when using macros, the macro may not know whether or not the constraint would hold or not at the time when generating the code. Currently, the compiler does not alert you if the constraint is always true, and generates an error if it is never true. The trivial_bounds feature changes this to be a warning in both cases, giving macros more freedom and flexibility to generate code, while still providing a signal when writing non-macro code that something is amiss.

See RFC 2056 for more details. This feature is currently only available on the nightly channel, see tracking issue #48214.

type-alias-bounds

The type_alias_bounds lint detects bounds in type aliases.

Example

type SendVec<T: Send> = Vec<T>;

This will produce:

warning: bounds on generic parameters in type aliases are not enforced
 --> lint_example.rs:2:17
  |
2 | type SendVec<T: Send> = Vec<T>;
  |               --^^^^
  |               | |
  |               | will not be checked at usage sites of the type alias
  |               help: remove this bound
  |
  = note: this is a known limitation of the type checker that may be lifted in a future edition.
          see issue #112792 <https://github.com/rust-lang/rust/issues/112792> for more information
  = help: add `#![feature(lazy_type_alias)]` to the crate attributes to enable the desired semantics
  = note: `#[warn(type_alias_bounds)]` on by default

Explanation

Trait and lifetime bounds on generic parameters and in where clauses of type aliases are not checked at usage sites of the type alias. Moreover, they are not thoroughly checked for correctness at their definition site either similar to the aliased type.

This is a known limitation of the type checker that may be lifted in a future edition. Permitting such bounds in light of this was unintentional.

While these bounds may have secondary effects such as enabling the use of "shorthand" associated type paths¹ and affecting the default trait object lifetime² of trait object types passed to the type alias, this should not have been allowed until the aforementioned restrictions of the type checker have been lifted.

Using such bounds is highly discouraged as they are actively misleading.

tyvar-behind-raw-pointer

The tyvar_behind_raw_pointer lint detects raw pointer to an inference variable.

Example

// edition 2015
let data = std::ptr::null();
let _ = &data as *const *const ();

if data.is_null() {}

This will produce:

warning: type annotations needed
 --> lint_example.rs:6:9
  |
6 | if data.is_null() {}
  |         ^^^^^^^
  |
  = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018!
  = note: for more information, see issue #46906 <https://github.com/rust-lang/rust/issues/46906>
  = note: `#[warn(tyvar_behind_raw_pointer)]` on by default

Explanation

This kind of inference was previously allowed, but with the future arrival of arbitrary self types, this can introduce ambiguity. To resolve this, use an explicit type instead of relying on type inference.

This is a future-incompatible lint to transition this to a hard error in the 2018 edition. See issue #46906 for more details. This is currently a hard-error on the 2018 edition, and is "warn" by default in the 2015 edition.

uncommon-codepoints

The uncommon_codepoints lint detects uncommon Unicode codepoints in identifiers.

Example

#![allow(unused)]
const µ: f64 = 0.000001;

This will produce:

warning: identifier contains a non normalized (NFKC) character: 'µ'
 --> lint_example.rs:3:7
  |
3 | const µ: f64 = 0.000001;
  |       ^
  |
  = note: this character is included in the Not_NFKC Unicode general security profile
  = note: `#[warn(uncommon_codepoints)]` on by default

Explanation

This lint warns about using characters which are not commonly used, and may cause visual confusion.

This lint is triggered by identifiers that contain a codepoint that is not part of the set of "Allowed" codepoints as described by Unicode® Technical Standard #39 Unicode Security Mechanisms Section 3.1 General Security Profile for Identifiers.

Note that the set of uncommon codepoints may change over time. Beware that if you "forbid" this lint that existing code may fail in the future.

unconditional-recursion

The unconditional_recursion lint detects functions that cannot return without calling themselves.

Example

fn foo() {
    foo();
}

This will produce:

warning: function cannot return without recursing
 --> lint_example.rs:2:1
  |
2 | fn foo() {
  | ^^^^^^^^ cannot return without recursing
3 |     foo();
  |     ----- recursive call site
  |
  = help: a `loop` may express intention better if this is on purpose
  = note: `#[warn(unconditional_recursion)]` on by default

Explanation

It is usually a mistake to have a recursive call that does not have some condition to cause it to terminate. If you really intend to have an infinite loop, using a loop expression is recommended.

uncovered-param-in-projection

The uncovered_param_in_projection lint detects a violation of one of Rust's orphan rules for foreign trait implementations that concerns the use of type parameters inside trait associated type paths ("projections") whose output may not be a local type that is mistakenly considered to "cover" said parameters which is unsound and which may be rejected by a future version of the compiler.

Originally reported in #99554.

Example

// dependency.rs
#![crate_type = "lib"]

pub trait Trait<T, U> {}

// dependent.rs
trait Identity {
    type Output;
}

impl<T> Identity for T {
    type Output = T;
}

struct Local;

impl<T> dependency::Trait<Local, T> for <T as Identity>::Output {}

fn main() {}

This will produce:

warning[E0210]: type parameter `T` must be covered by another type when it appears before the first local type (`Local`)
  --> dependent.rs:11:6
   |
11 | impl<T> dependency::Trait<Local, T> for <T as Identity>::Output {}
   |      ^ type parameter `T` must be covered by another type when it appears before the first local type (`Local`)
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #124559 <https://github.com/rust-lang/rust/issues/124559>
   = note: implementing a foreign trait is only possible if at least one of the types for which it is implemented is local, and no uncovered type parameters appear before that first local type
   = note: in this case, 'before' refers to the following order: `impl<..> ForeignTrait<T1, ..., Tn> for T0`, where `T0` is the first and `Tn` is the last
   = note: `#[warn(uncovered_param_in_projection)]` on by default

Explanation

FIXME(fmease): Write explainer.

undefined-naked-function-abi

The undefined_naked_function_abi lint detects naked function definitions that either do not specify an ABI or specify the Rust ABI.

Example

#![feature(asm_experimental_arch, naked_functions)]

use std::arch::naked_asm;

#[naked]
pub fn default_abi() -> u32 {
    unsafe { naked_asm!(""); }
}

#[naked]
pub extern "Rust" fn rust_abi() -> u32 {
    unsafe { naked_asm!(""); }
}

This will produce:

warning: Rust ABI is unsupported in naked functions
 --> lint_example.rs:7:1
  |
7 | pub fn default_abi() -> u32 {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(undefined_naked_function_abi)]` on by default


warning: Rust ABI is unsupported in naked functions
  --> lint_example.rs:12:1
   |
12 | pub extern "Rust" fn rust_abi() -> u32 {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

The Rust ABI is currently undefined. Therefore, naked functions should specify a non-Rust ABI.

unexpected-cfgs

The unexpected_cfgs lint detects unexpected conditional compilation conditions.

Example

rustc --check-cfg 'cfg()'

#[cfg(widnows)]
fn foo() {}

This will produce:

warning: unexpected `cfg` condition name: `widnows`
 --> lint_example.rs:1:7
  |
1 | #[cfg(widnows)]
  |       ^^^^^^^
  |
  = note: `#[warn(unexpected_cfgs)]` on by default

Explanation

This lint is only active when --check-cfg arguments are being passed to the compiler and triggers whenever an unexpected condition name or value is used.

See the Checking Conditional Configurations section for more details.

See the Cargo Specifics section for configuring this lint in Cargo.toml.

unfulfilled-lint-expectations

The unfulfilled_lint_expectations lint detects when a lint expectation is unfulfilled.

Example

#[expect(unused_variables)]
let x = 10;
println!("{}", x);

This will produce:

warning: this lint expectation is unfulfilled
 --> lint_example.rs:2:10
  |
2 | #[expect(unused_variables)]
  |          ^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unfulfilled_lint_expectations)]` on by default

Explanation

The #[expect] attribute can be used to create a lint expectation. The expectation is fulfilled, if a #[warn] attribute at the same location would result in a lint emission. If the expectation is unfulfilled, because no lint was emitted, this lint will be emitted on the attribute.

ungated-async-fn-track-caller

The ungated_async_fn_track_caller lint warns when the #[track_caller] attribute is used on an async function without enabling the corresponding unstable feature flag.

Example

#[track_caller]
async fn foo() {}

This will produce:

warning: `#[track_caller]` on async functions is a no-op
 --> lint_example.rs:2:1
  |
2 | #[track_caller]
  | ^^^^^^^^^^^^^^^
3 | async fn foo() {}
  | ----------------- this function will not propagate the caller location
  |
  = note: see issue #110011 <https://github.com/rust-lang/rust/issues/110011> for more information
  = help: add `#![feature(async_fn_track_caller)]` to the crate attributes to enable
  = note: this compiler was built on 2024-11-10; consider upgrading it if it is out of date
  = note: `#[warn(ungated_async_fn_track_caller)]` on by default

Explanation

The attribute must be used in conjunction with the async_fn_track_caller feature flag. Otherwise, the #[track_caller] annotation will function as a no-op.

uninhabited-static

The uninhabited_static lint detects uninhabited statics.

Example

enum Void {}
extern {
    static EXTERN: Void;
}

This will produce:

warning: static of uninhabited type
 --> lint_example.rs:4:5
  |
4 |     static EXTERN: Void;
  |     ^^^^^^^^^^^^^^^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #74840 <https://github.com/rust-lang/rust/issues/74840>
  = note: uninhabited statics cannot be initialized, and any access would be an immediate error
  = note: `#[warn(uninhabited_static)]` on by default

Explanation

Statics with an uninhabited type can never be initialized, so they are impossible to define. However, this can be side-stepped with an extern static, leading to problems later in the compiler which assumes that there are no initialized uninhabited places (such as locals or statics). This was accidentally allowed, but is being phased out.

unknown-lints

The unknown_lints lint detects unrecognized lint attributes.

Example

#![allow(not_a_real_lint)]

This will produce:

warning: unknown lint: `not_a_real_lint`
 --> lint_example.rs:1:10
  |
1 | #![allow(not_a_real_lint)]
  |          ^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unknown_lints)]` on by default

Explanation

It is usually a mistake to specify a lint that does not exist. Check the spelling, and check the lint listing for the correct name. Also consider if you are using an old version of the compiler, and the lint is only available in a newer version.

unknown-or-malformed-diagnostic-attributes

The unknown_or_malformed_diagnostic_attributes lint detects unrecognized or otherwise malformed diagnostic attributes.

Example

#![feature(diagnostic_namespace)]
#[diagnostic::does_not_exist]
struct Foo;

This will produce:

warning: unknown diagnostic attribute
 --> lint_example.rs:3:15
  |
3 | #[diagnostic::does_not_exist]
  |               ^^^^^^^^^^^^^^
  |
  = note: `#[warn(unknown_or_malformed_diagnostic_attributes)]` on by default

Explanation

It is usually a mistake to specify a diagnostic attribute that does not exist. Check the spelling, and check the diagnostic attribute listing for the correct name. Also consider if you are using an old version of the compiler, and the attribute is only available in a newer version.

unnameable-test-items

The unnameable_test_items lint detects #[test] functions that are not able to be run by the test harness because they are in a position where they are not nameable.

Example

fn main() {
    #[test]
    fn foo() {
        // This test will not fail because it does not run.
        assert_eq!(1, 2);
    }
}

This will produce:

warning: cannot test inner items
 --> lint_example.rs:2:5
  |
2 |     #[test]
  |     ^^^^^^^
  |
  = note: `#[warn(unnameable_test_items)]` on by default
  = note: this warning originates in the attribute macro `test` (in Nightly builds, run with -Z macro-backtrace for more info)

Explanation

In order for the test harness to run a test, the test function must be located in a position where it can be accessed from the crate root. This generally means it must be defined in a module, and not anywhere else such as inside another function. The compiler previously allowed this without an error, so a lint was added as an alert that a test is not being used. Whether or not this should be allowed has not yet been decided, see RFC 2471 and issue #36629.

unreachable-code

The unreachable_code lint detects unreachable code paths.

Example

panic!("we never go past here!");

let x = 5;

This will produce:

warning: unreachable statement
 --> lint_example.rs:4:1
  |
2 | panic!("we never go past here!");
  | -------------------------------- any code following this expression is unreachable
3 |
4 | let x = 5;
  | ^^^^^^^^^^ unreachable statement
  |
  = note: `#[warn(unreachable_code)]` on by default

Explanation

Unreachable code may signal a mistake or unfinished code. If the code is no longer in use, consider removing it.

unreachable-patterns

The unreachable_patterns lint detects unreachable patterns.

Example

let x = 5;
match x {
    y => (),
    5 => (),
}

This will produce:

warning: unreachable pattern
 --> lint_example.rs:5:5
  |
4 |     y => (),
  |     - matches any value
5 |     5 => (),
  |     ^ no value can reach this
  |
  = note: `#[warn(unreachable_patterns)]` on by default

Explanation

This usually indicates a mistake in how the patterns are specified or ordered. In this example, the y pattern will always match, so the five is impossible to reach. Remember, match arms match in order, you probably wanted to put the 5 case above the y case.

unstable-name-collision

The lint unstable-name-collision has been renamed to unstable-name-collisions.

unstable-name-collisions

The unstable_name_collisions lint detects that you have used a name that the standard library plans to add in the future.

Example

trait MyIterator : Iterator {
    // is_partitioned is an unstable method that already exists on the Iterator trait
    fn is_partitioned<P>(self, predicate: P) -> bool
    where
        Self: Sized,
        P: FnMut(Self::Item) -> bool,
    {true}
}

impl<T: ?Sized> MyIterator for T where T: Iterator { }

let x = vec![1, 2, 3];
let _ = x.iter().is_partitioned(|_| true);

This will produce:

warning: a method with this name may be added to the standard library in the future
  --> lint_example.rs:14:18
   |
14 | let _ = x.iter().is_partitioned(|_| true);
   |                  ^^^^^^^^^^^^^^
   |
   = warning: once this associated item is added to the standard library, the ambiguity may cause an error or change in behavior!
   = note: for more information, see issue #48919 <https://github.com/rust-lang/rust/issues/48919>
   = help: call with fully qualified syntax `MyIterator::is_partitioned(...)` to keep using the current method
   = note: `#[warn(unstable_name_collisions)]` on by default
help: add `#![feature(iter_is_partitioned)]` to the crate attributes to enable `is_partitioned`
   |
1  + #![feature(iter_is_partitioned)]
   |

Explanation

When new methods are added to traits in the standard library, they are usually added in an "unstable" form which is only available on the nightly channel with a feature attribute. If there is any preexisting code which extends a trait to have a method with the same name, then the names will collide. In the future, when the method is stabilized, this will cause an error due to the ambiguity. This lint is an early-warning to let you know that there may be a collision in the future. This can be avoided by adding type annotations to disambiguate which trait method you intend to call, such as MyIterator::is_partitioned(my_iter, my_predicate) or renaming or removing the method.

unstable-syntax-pre-expansion

The unstable_syntax_pre_expansion lint detects the use of unstable syntax that is discarded during attribute expansion.

Example

#[cfg(FALSE)]
macro foo() {}

This will produce:

warning: `macro` is experimental
 --> lint_example.rs:3:1
  |
3 | macro foo() {}
  | ^^^^^^^^^^^^^^
  |
  = note: see issue #39412 <https://github.com/rust-lang/rust/issues/39412> for more information
  = help: add `#![feature(decl_macro)]` to the crate attributes to enable
  = note: this compiler was built on 2024-11-10; consider upgrading it if it is out of date
  = warning: unstable syntax can change at any point in the future, causing a hard error!
  = note: for more information, see issue #65860 <https://github.com/rust-lang/rust/issues/65860>

Explanation

The input to active attributes such as #[cfg] or procedural macro attributes is required to be valid syntax. Previously, the compiler only gated the use of unstable syntax features after resolving #[cfg] gates and expanding procedural macros.

To avoid relying on unstable syntax, move the use of unstable syntax into a position where the compiler does not parse the syntax, such as a functionlike macro.

#![deny(unstable_syntax_pre_expansion)]

macro_rules! identity {
   ( $($tokens:tt)* ) => { $($tokens)* }
}

#[cfg(FALSE)]
identity! {
   macro foo() {}
}

This is a future-incompatible lint to transition this to a hard error in the future. See issue #65860 for more details.

unsupported-fn-ptr-calling-conventions

The unsupported_fn_ptr_calling_conventions lint is output whenever there is a use of a target dependent calling convention on a target that does not support this calling convention on a function pointer.

For example stdcall does not make much sense for a x86_64 or, more apparently, powerpc code, because this calling convention was never specified for those targets.

Example

fn stdcall_ptr(f: extern "stdcall" fn ()) {
    f()
}

This will produce:

warning: the calling convention `"stdcall"` is not supported on this target
  --> $DIR/unsupported.rs:34:15
   |
LL | fn stdcall_ptr(f: extern "stdcall" fn()) {
   |               ^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #130260 <https://github.com/rust-lang/rust/issues/130260>
   = note: `#[warn(unsupported_fn_ptr_calling_conventions)]` on by default

Explanation

On most of the targets the behaviour of stdcall and similar calling conventions is not defined at all, but was previously accepted due to a bug in the implementation of the compiler.

unused-doc-comment

The lint unused-doc-comment has been renamed to unused-doc-comments.

unused-tuple-struct-fields

The lint unused-tuple-struct-fields has been renamed to dead-code.

unused-allocation

The unused_allocation lint detects unnecessary allocations that can be eliminated.

Example

fn main() {
    let a = Box::new([1, 2, 3]).len();
}

This will produce:

warning: unnecessary allocation, use `&` instead
 --> lint_example.rs:2:13
  |
2 |     let a = Box::new([1, 2, 3]).len();
  |             ^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_allocation)]` on by default

Explanation

When a box expression is immediately coerced to a reference, then the allocation is unnecessary, and a reference (using & or &mut) should be used instead to avoid the allocation.

unused-assignments

The unused_assignments lint detects assignments that will never be read.

Example

let mut x = 5;
x = 6;

This will produce:

warning: value assigned to `x` is never read
 --> lint_example.rs:3:1
  |
3 | x = 6;
  | ^
  |
  = help: maybe it is overwritten before being read?
  = note: `#[warn(unused_assignments)]` on by default

Explanation

Unused assignments may signal a mistake or unfinished code. If the variable is never used after being assigned, then the assignment can be removed. Variables with an underscore prefix such as _x will not trigger this lint.

unused-associated-type-bounds

The unused_associated_type_bounds lint is emitted when an associated type bound is added to a trait object, but the associated type has a where Self: Sized bound, and is thus unavailable on the trait object anyway.

Example

trait Foo {
    type Bar where Self: Sized;
}
type Mop = dyn Foo<Bar = ()>;

This will produce:

warning: unnecessary associated type bound for dyn-incompatible associated type
 --> lint_example.rs:5:20
  |
5 | type Mop = dyn Foo<Bar = ()>;
  |                    ^^^^^^^^ help: remove this bound
  |
  = note: this associated type has a `where Self: Sized` bound, and while the associated type can be specified, it cannot be used because trait objects are never `Sized`
  = note: `#[warn(unused_associated_type_bounds)]` on by default

Explanation

Just like methods with Self: Sized bounds are unavailable on trait objects, associated types can be removed from the trait object.

unused-attributes

The unused_attributes lint detects attributes that were not used by the compiler.

Example

#![ignore]

This will produce:

warning: `#[ignore]` only has an effect on functions
 --> lint_example.rs:1:1
  |
1 | #![ignore]
  | ^^^^^^^^^^
  |
  = note: `#[warn(unused_attributes)]` on by default

Explanation

Unused attributes may indicate the attribute is placed in the wrong position. Consider removing it, or placing it in the correct position. Also consider if you intended to use an inner attribute (with a ! such as #![allow(unused)]) which applies to the item the attribute is within, or an outer attribute (without a ! such as #[allow(unused)]) which applies to the item following the attribute.

unused-braces

The unused_braces lint detects unnecessary braces around an expression.

Example

if { true } {
    // ...
}

This will produce:

warning: unnecessary braces around `if` condition
 --> lint_example.rs:2:4
  |
2 | if { true } {
  |    ^^    ^^
  |
  = note: `#[warn(unused_braces)]` on by default
help: remove these braces
  |
2 - if { true } {
2 + if true {
  |

Explanation

The braces are not needed, and should be removed. This is the preferred style for writing these expressions.

unused-comparisons

The unused_comparisons lint detects comparisons made useless by limits of the types involved.

Example

fn foo(x: u8) {
    x >= 0;
}

This will produce:

warning: comparison is useless due to type limits
 --> lint_example.rs:3:5
  |
3 |     x >= 0;
  |     ^^^^^^
  |
  = note: `#[warn(unused_comparisons)]` on by default

Explanation

A useless comparison may indicate a mistake, and should be fixed or removed.

unused-doc-comments

The unused_doc_comments lint detects doc comments that aren't used by rustdoc.

Example

/// docs for x
let x = 12;

This will produce:

warning: unused doc comment
 --> lint_example.rs:2:1
  |
2 | /// docs for x
  | ^^^^^^^^^^^^^^
3 | let x = 12;
  | ----------- rustdoc does not generate documentation for statements
  |
  = help: use `//` for a plain comment
  = note: `#[warn(unused_doc_comments)]` on by default

Explanation

rustdoc does not use doc comments in all positions, and so the doc comment will be ignored. Try changing it to a normal comment with // to avoid the warning.

unused-features

The unused_features lint detects unused or unknown features found in crate-level feature attributes.

Note: This lint is currently not functional, see issue #44232 for more details.

unused-imports

The unused_imports lint detects imports that are never used.

Example

use std::collections::HashMap;

This will produce:

warning: unused import: `std::collections::HashMap`
 --> lint_example.rs:2:5
  |
2 | use std::collections::HashMap;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

Explanation

Unused imports may signal a mistake or unfinished code, and clutter the code, and should be removed. If you intended to re-export the item to make it available outside of the module, add a visibility modifier like pub.

unused-labels

The unused_labels lint detects labels that are never used.

Example

'unused_label: loop {}

This will produce:

warning: unused label
 --> lint_example.rs:2:1
  |
2 | 'unused_label: loop {}
  | ^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_labels)]` on by default

Explanation

Unused labels may signal a mistake or unfinished code. To silence the warning for the individual label, prefix it with an underscore such as '_my_label:.

unused-macros

The unused_macros lint detects macros that were not used.

Note that this lint is distinct from the unused_macro_rules lint, which checks for single rules that never match of an otherwise used macro, and thus never expand.

Example

macro_rules! unused {
    () => {};
}

fn main() {
}

This will produce:

warning: unused macro definition: `unused`
 --> lint_example.rs:1:14
  |
1 | macro_rules! unused {
  |              ^^^^^^
  |
  = note: `#[warn(unused_macros)]` on by default

Explanation

Unused macros may signal a mistake or unfinished code. To silence the warning for the individual macro, prefix the name with an underscore such as _my_macro. If you intended to export the macro to make it available outside of the crate, use the macro_export attribute.

unused-must-use

The unused_must_use lint detects unused result of a type flagged as #[must_use].

Example

fn returns_result() -> Result<(), ()> {
    Ok(())
}

fn main() {
    returns_result();
}

This will produce:

warning: unused `Result` that must be used
 --> lint_example.rs:6:5
  |
6 |     returns_result();
  |     ^^^^^^^^^^^^^^^^
  |
  = note: this `Result` may be an `Err` variant, which should be handled
  = note: `#[warn(unused_must_use)]` on by default
help: use `let _ = ...` to ignore the resulting value
  |
6 |     let _ = returns_result();
  |     +++++++

Explanation

The #[must_use] attribute is an indicator that it is a mistake to ignore the value. See the reference for more details.

unused-mut

The unused_mut lint detects mut variables which don't need to be mutable.

Example

let mut x = 5;

This will produce:

warning: variable does not need to be mutable
 --> lint_example.rs:2:5
  |
2 | let mut x = 5;
  |     ----^
  |     |
  |     help: remove this `mut`
  |
  = note: `#[warn(unused_mut)]` on by default

Explanation

The preferred style is to only mark variables as mut if it is required.

unused-parens

The unused_parens lint detects if, match, while and return with parentheses; they do not need them.

Examples

if(true) {}

This will produce:

warning: unnecessary parentheses around `if` condition
 --> lint_example.rs:2:3
  |
2 | if(true) {}
  |   ^    ^
  |
  = note: `#[warn(unused_parens)]` on by default
help: remove these parentheses
  |
2 - if(true) {}
2 + if true {}
  |

Explanation

The parentheses are not needed, and should be removed. This is the preferred style for writing these expressions.

unused-unsafe

The unused_unsafe lint detects unnecessary use of an unsafe block.

Example

unsafe {}

This will produce:

warning: unnecessary `unsafe` block
 --> lint_example.rs:2:1
  |
2 | unsafe {}
  | ^^^^^^ unnecessary `unsafe` block
  |
  = note: `#[warn(unused_unsafe)]` on by default

Explanation

If nothing within the block requires unsafe, then remove the unsafe marker because it is not required and may cause confusion.

unused-variables

The unused_variables lint detects variables which are not used in any way.

Example

let x = 5;

This will produce:

warning: unused variable: `x`
 --> lint_example.rs:2:5
  |
2 | let x = 5;
  |     ^ help: if this is intentional, prefix it with an underscore: `_x`
  |
  = note: `#[warn(unused_variables)]` on by default

Explanation

Unused variables may signal a mistake or unfinished code. To silence the warning for the individual variable, prefix it with an underscore such as _x.

useless-ptr-null-checks

The useless_ptr_null_checks lint checks for useless null checks against pointers obtained from non-null types.

Example

fn test() {}
let fn_ptr: fn() = /* somehow obtained nullable function pointer */
  test;

if (fn_ptr as *const ()).is_null() { /* ... */ }

This will produce:

warning: function pointers are not nullable, so checking them for null will always return false
 --> lint_example.rs:6:4
  |
6 | if (fn_ptr as *const ()).is_null() { /* ... */ }
  |    ^------^^^^^^^^^^^^^^^^^^^^^^^^
  |     |
  |     expression has type `fn()`
  |
  = help: wrap the function pointer inside an `Option` and use `Option::is_none` to check for null pointer value
  = note: `#[warn(useless_ptr_null_checks)]` on by default

Explanation

Function pointers and references are assumed to be non-null, checking them for null will always return false.

warnings

The warnings lint allows you to change the level of other lints which produce warnings.

Example

#![deny(warnings)]
fn foo() {}

This will produce:

error: function `foo` is never used
 --> lint_example.rs:3:4
  |
3 | fn foo() {}
  |    ^^^
  |
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(warnings)]
  |         ^^^^^^^^
  = note: `#[deny(dead_code)]` implied by `#[deny(warnings)]`

Explanation

The warnings lint is a bit special; by changing its level, you change every other warning that would produce a warning to whatever value you'd like. As such, you won't ever trigger this lint in your code directly.

while-true

The while_true lint detects while true { }.

Example

while true {

}

This will produce:

warning: denote infinite loops with `loop { ... }`
 --> lint_example.rs:2:1
  |
2 | while true {
  | ^^^^^^^^^^ help: use `loop`
  |
  = note: `#[warn(while_true)]` on by default

Explanation

while true should be replaced with loop. A loop expression is the preferred way to write an infinite loop because it more directly expresses the intent of the loop.

Deny-by-default Lints

These lints are all set to the 'deny' level by default.

• ambiguous_associated_items
• arithmetic_overflow
• binary_asm_labels
• bindings_with_variant_name
• cenum_impl_drop_cast
• conflicting_repr_hints
• elided_lifetimes_in_associated_constant
• enum_intrinsics_non_enums
• exceeding-bitshifts
• explicit_builtin_cfgs_in_flags
• ill_formed_attribute_input
• incomplete_include
• ineffective_unstable_trait_impl
• invalid_atomic_ordering
• invalid_doc_attributes
• invalid_from_utf8_unchecked
• invalid_reference_casting
• invalid_type_param_default
• let_underscore_lock
• long_running_const_eval
• macro_expanded_macro_exports_accessed_by_absolute_paths
• missing_fragment_specifier
• mutable_transmutes
• named_asm_labels
• no_mangle_const_items
• order_dependent_trait_objects
• overflowing_literals
• patterns_in_fns_without_body
• proc_macro_derive_resolution_fallback
• pub_use_of_private_extern_crate
• soft_unstable
• test_unstable_lint
• text_direction_codepoint_in_comment
• text_direction_codepoint_in_literal
• unconditional_panic
• undropped_manually_drops
• unknown_crate_types
• useless_deprecated
• wasm_c_abi

ambiguous-associated-items

The ambiguous_associated_items lint detects ambiguity between associated items and enum variants.

Example

enum E {
    V
}

trait Tr {
    type V;
    fn foo() -> Self::V;
}

impl Tr for E {
    type V = u8;
    // `Self::V` is ambiguous because it may refer to the associated type or
    // the enum variant.
    fn foo() -> Self::V { 0 }
}

This will produce:

error: ambiguous associated item
  --> lint_example.rs:15:17
   |
15 |     fn foo() -> Self::V { 0 }
   |                 ^^^^^^^ help: use fully-qualified syntax: `<E as Tr>::V`
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #57644 <https://github.com/rust-lang/rust/issues/57644>
note: `V` could refer to the variant defined here
  --> lint_example.rs:3:5
   |
3  |     V
   |     ^
note: `V` could also refer to the associated type defined here
  --> lint_example.rs:7:5
   |
7  |     type V;
   |     ^^^^^^
   = note: `#[deny(ambiguous_associated_items)]` on by default

Explanation

Previous versions of Rust did not allow accessing enum variants through type aliases. When this ability was added (see RFC 2338), this introduced some situations where it can be ambiguous what a type was referring to.

To fix this ambiguity, you should use a qualified path to explicitly state which type to use. For example, in the above example the function can be written as fn f() -> <Self as Tr>::V { 0 } to specifically refer to the associated type.

This is a future-incompatible lint to transition this to a hard error in the future. See issue #57644 for more details.

arithmetic-overflow

The arithmetic_overflow lint detects that an arithmetic operation will overflow.

Example

1_i32 << 32;

This will produce:

error: this arithmetic operation will overflow
 --> lint_example.rs:2:1
  |
2 | 1_i32 << 32;
  | ^^^^^^^^^^^ attempt to shift left by `32_i32`, which would overflow
  |
  = note: `#[deny(arithmetic_overflow)]` on by default

Explanation

It is very likely a mistake to perform an arithmetic operation that overflows its value. If the compiler is able to detect these kinds of overflows at compile-time, it will trigger this lint. Consider adjusting the expression to avoid overflow, or use a data type that will not overflow.

binary-asm-labels

The binary_asm_labels lint detects the use of numeric labels containing only binary digits in the inline asm! macro.

Example

#![cfg(target_arch = "x86_64")]

use std::arch::asm;

fn main() {
    unsafe {
        asm!("0: jmp 0b");
    }
}

This will produce:

error: avoid using labels containing only the digits `0` and `1` in inline assembly
 --> <source>:7:15
  |
7 |         asm!("0: jmp 0b");
  |               ^ use a different label that doesn't start with `0` or `1`
  |
  = help: start numbering with `2` instead
  = note: an LLVM bug makes these labels ambiguous with a binary literal number on x86
  = note: see <https://github.com/llvm/llvm-project/issues/99547> for more information
  = note: `#[deny(binary_asm_labels)]` on by default

Explanation

An LLVM bug causes this code to fail to compile because it interprets the 0b as a binary literal instead of a reference to the previous local label 0. To work around this bug, don't use labels that could be confused with a binary literal.

This behavior is platform-specific to x86 and x86-64.

See the explanation in Rust By Example for more details.

bindings-with-variant-name

The bindings_with_variant_name lint detects pattern bindings with the same name as one of the matched variants.

Example

pub enum Enum {
    Foo,
    Bar,
}

pub fn foo(x: Enum) {
    match x {
        Foo => {}
        Bar => {}
    }
}

This will produce:

error[E0170]: pattern binding `Foo` is named the same as one of the variants of the type `main::Enum`
 --> lint_example.rs:9:9
  |
9 |         Foo => {}
  |         ^^^ help: to match on the variant, qualify the path: `main::Enum::Foo`
  |
  = note: `#[deny(bindings_with_variant_name)]` on by default

Explanation

It is usually a mistake to specify an enum variant name as an identifier pattern. In the example above, the match arms are specifying a variable name to bind the value of x to. The second arm is ignored because the first one matches all values. The likely intent is that the arm was intended to match on the enum variant.

Two possible solutions are:

• Specify the enum variant using a path pattern, such as Enum::Foo.
• Bring the enum variants into local scope, such as adding use Enum::*; to the beginning of the foo function in the example above.

cenum-impl-drop-cast

The cenum_impl_drop_cast lint detects an as cast of a field-less enum that implements Drop.

Example

#![allow(unused)]
enum E {
    A,
}

impl Drop for E {
    fn drop(&mut self) {
        println!("Drop");
    }
}

fn main() {
    let e = E::A;
    let i = e as u32;
}

This will produce:

error: cannot cast enum `E` into integer `u32` because it implements `Drop`
  --> lint_example.rs:14:13
   |
14 |     let i = e as u32;
   |             ^^^^^^^^
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #73333 <https://github.com/rust-lang/rust/issues/73333>
   = note: `#[deny(cenum_impl_drop_cast)]` on by default

Explanation

Casting a field-less enum that does not implement Copy to an integer moves the value without calling drop. This can result in surprising behavior if it was expected that drop should be called. Calling drop automatically would be inconsistent with other move operations. Since neither behavior is clear or consistent, it was decided that a cast of this nature will no longer be allowed.

This is a future-incompatible lint to transition this to a hard error in the future. See issue #73333 for more details.

conflicting-repr-hints

The conflicting_repr_hints lint detects repr attributes with conflicting hints.

Example

#[repr(u32, u64)]
enum Foo {
    Variant1,
}

This will produce:

error[E0566]: conflicting representation hints
 --> lint_example.rs:2:8
  |
2 | #[repr(u32, u64)]
  |        ^^^  ^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #68585 <https://github.com/rust-lang/rust/issues/68585>
  = note: `#[deny(conflicting_repr_hints)]` on by default

Explanation

The compiler incorrectly accepted these conflicting representations in the past. This is a future-incompatible lint to transition this to a hard error in the future. See issue #68585 for more details.

To correct the issue, remove one of the conflicting hints.

elided-lifetimes-in-associated-constant

The elided_lifetimes_in_associated_constant lint detects elided lifetimes in associated constants when there are other lifetimes in scope. This was accidentally supported, and this lint was later relaxed to allow eliding lifetimes to 'static when there are no lifetimes in scope.

Example

#![deny(elided_lifetimes_in_associated_constant)]

struct Foo<'a>(&'a ());

impl<'a> Foo<'a> {
    const STR: &str = "hello, world";
}

This will produce:

error: `&` without an explicit lifetime name cannot be used here
 --> lint_example.rs:7:16
  |
7 |     const STR: &str = "hello, world";
  |                ^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #115010 <https://github.com/rust-lang/rust/issues/115010>
note: cannot automatically infer `'static` because of other lifetimes in scope
 --> lint_example.rs:6:6
  |
6 | impl<'a> Foo<'a> {
  |      ^^
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(elided_lifetimes_in_associated_constant)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: use the `'static` lifetime
  |
7 |     const STR: &'static str = "hello, world";
  |                 +++++++

Explanation

Previous version of Rust

Implicit static-in-const behavior was decided against for associated constants because of ambiguity. This, however, regressed and the compiler erroneously treats elided lifetimes in associated constants as lifetime parameters on the impl.

This is a future-incompatible lint to transition this to a hard error in the future.

enum-intrinsics-non-enums

The enum_intrinsics_non_enums lint detects calls to intrinsic functions that require an enum (core::mem::discriminant, core::mem::variant_count), but are called with a non-enum type.

Example

#![deny(enum_intrinsics_non_enums)]
core::mem::discriminant::<i32>(&123);

This will produce:

error: the return value of `mem::discriminant` is unspecified when called with a non-enum type
 --> lint_example.rs:3:1
  |
3 | core::mem::discriminant::<i32>(&123);
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
note: the argument to `discriminant` should be a reference to an enum, but it was passed a reference to a `i32`, which is not an enum
 --> lint_example.rs:3:32
  |
3 | core::mem::discriminant::<i32>(&123);
  |                                ^^^^
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(enum_intrinsics_non_enums)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^

Explanation

In order to accept any enum, the mem::discriminant and mem::variant_count functions are generic over a type T. This makes it technically possible for T to be a non-enum, in which case the return value is unspecified.

This lint prevents such incorrect usage of these functions.

exceeding-bitshifts

The lint exceeding-bitshifts has been renamed to arithmetic-overflow.

explicit-builtin-cfgs-in-flags

The explicit_builtin_cfgs_in_flags lint detects builtin cfgs set via the --cfg flag.

Example

rustc --cfg unix

fn main() {}

This will produce:

error: unexpected `--cfg unix` flag
  |
  = note: config `unix` is only supposed to be controlled by `--target`
  = note: manually setting a built-in cfg can and does create incoherent behaviors
  = note: `#[deny(explicit_builtin_cfgs_in_flags)]` on by default

Explanation

Setting builtin cfgs can and does produce incoherent behavior, it's better to the use the appropriate rustc flag that controls the config. For example setting the windows cfg but on Linux based target.

ill-formed-attribute-input

The ill_formed_attribute_input lint detects ill-formed attribute inputs that were previously accepted and used in practice.

Example

#[inline = "this is not valid"]
fn foo() {}

This will produce:

error: valid forms for the attribute are `#[inline]` and `#[inline(always|never)]`
 --> lint_example.rs:2:1
  |
2 | #[inline = "this is not valid"]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #57571 <https://github.com/rust-lang/rust/issues/57571>
  = note: `#[deny(ill_formed_attribute_input)]` on by default

Explanation

Previously, inputs for many built-in attributes weren't validated and nonsensical attribute inputs were accepted. After validation was added, it was determined that some existing projects made use of these invalid forms. This is a future-incompatible lint to transition this to a hard error in the future. See issue #57571 for more details.

Check the attribute reference for details on the valid inputs for attributes.

incomplete-include

The incomplete_include lint detects the use of the include! macro with a file that contains more than one expression.

Example

fn main() {
    include!("foo.txt");
}

where the file foo.txt contains:

println!("hi!");

produces:

error: include macro expected single expression in source
 --> foo.txt:1:14
  |
1 | println!("1");
  |              ^
  |
  = note: `#[deny(incomplete_include)]` on by default

Explanation

The include! macro is currently only intended to be used to include a single expression or multiple items. Historically it would ignore any contents after the first expression, but that can be confusing. In the example above, the println! expression ends just before the semicolon, making the semicolon "extra" information that is ignored. Perhaps even more surprising, if the included file had multiple print statements, the subsequent ones would be ignored!

One workaround is to place the contents in braces to create a block expression. Also consider alternatives, like using functions to encapsulate the expressions, or use proc-macros.

This is a lint instead of a hard error because existing projects were found to hit this error. To be cautious, it is a lint for now. The future semantics of the include! macro are also uncertain, see issue #35560.

ineffective-unstable-trait-impl

The ineffective_unstable_trait_impl lint detects #[unstable] attributes which are not used.

Example

#![feature(staged_api)]

#[derive(Clone)]
#[stable(feature = "x", since = "1")]
struct S {}

#[unstable(feature = "y", issue = "none")]
impl Copy for S {}

This will produce:

error: an `#[unstable]` annotation here has no effect
 --> lint_example.rs:8:1
  |
8 | #[unstable(feature = "y", issue = "none")]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: see issue #55436 <https://github.com/rust-lang/rust/issues/55436> for more information
  = note: `#[deny(ineffective_unstable_trait_impl)]` on by default

Explanation

staged_api does not currently support using a stability attribute on impl blocks. impls are always stable if both the type and trait are stable, and always unstable otherwise.

invalid-atomic-ordering

The invalid_atomic_ordering lint detects passing an Ordering to an atomic operation that does not support that ordering.

Example

use core::sync::atomic::{AtomicU8, Ordering};
let atom = AtomicU8::new(0);
let value = atom.load(Ordering::Release);
let _ = value;

This will produce:

error: atomic loads cannot have `Release` or `AcqRel` ordering
 --> lint_example.rs:4:23
  |
4 | let value = atom.load(Ordering::Release);
  |                       ^^^^^^^^^^^^^^^^^
  |
  = help: consider using ordering modes `Acquire`, `SeqCst` or `Relaxed`
  = note: `#[deny(invalid_atomic_ordering)]` on by default

Explanation

Some atomic operations are only supported for a subset of the atomic::Ordering variants. Passing an unsupported variant will cause an unconditional panic at runtime, which is detected by this lint.

This lint will trigger in the following cases: (where AtomicType is an atomic type from core::sync::atomic, such as AtomicBool, AtomicPtr, AtomicUsize, or any of the other integer atomics).

• Passing Ordering::Acquire or Ordering::AcqRel to AtomicType::store.

• Passing Ordering::Release or Ordering::AcqRel to AtomicType::load.

• Passing Ordering::Relaxed to core::sync::atomic::fence or core::sync::atomic::compiler_fence.

• Passing Ordering::Release or Ordering::AcqRel as the failure ordering for any of AtomicType::compare_exchange, AtomicType::compare_exchange_weak, or AtomicType::fetch_update.

invalid-doc-attributes

The invalid_doc_attributes lint detects when the #[doc(...)] is misused.

Example

#![deny(warnings)]

pub mod submodule {
    #![doc(test(no_crate_inject))]
}

This will produce:

error: this attribute can only be applied at the crate level
 --> lint_example.rs:5:12
  |
5 |     #![doc(test(no_crate_inject))]
  |            ^^^^^^^^^^^^^^^^^^^^^
  |
  = note: read <https://doc.rust-lang.org/nightly/rustdoc/the-doc-attribute.html#at-the-crate-level> for more information
  = note: `#[deny(invalid_doc_attributes)]` on by default

Explanation

Previously, incorrect usage of the #[doc(..)] attribute was not being validated. Usually these should be rejected as a hard error, but this lint was introduced to avoid breaking any existing crates which included them.

invalid-from-utf8-unchecked

The invalid_from_utf8_unchecked lint checks for calls to std::str::from_utf8_unchecked and std::str::from_utf8_unchecked_mut with a known invalid UTF-8 value.

Example

#[allow(unused)]
unsafe {
    std::str::from_utf8_unchecked(b"Ru\x82st");
}

This will produce:

error: calls to `std::str::from_utf8_unchecked` with a invalid literal are undefined behavior
 --> lint_example.rs:4:5
  |
4 |     std::str::from_utf8_unchecked(b"Ru\x82st");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^-----------^
  |                                   |
  |                                   the literal was valid UTF-8 up to the 2 bytes
  |
  = note: `#[deny(invalid_from_utf8_unchecked)]` on by default

Explanation

Creating such a str would result in undefined behavior as per documentation for std::str::from_utf8_unchecked and std::str::from_utf8_unchecked_mut.

invalid-reference-casting

The invalid_reference_casting lint checks for casts of &T to &mut T without using interior mutability.

Example

fn x(r: &i32) {
    unsafe {
        *(r as *const i32 as *mut i32) += 1;
    }
}

This will produce:

error: assigning to `&T` is undefined behavior, consider using an `UnsafeCell`
 --> lint_example.rs:4:9
  |
4 |         *(r as *const i32 as *mut i32) += 1;
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: for more information, visit <https://doc.rust-lang.org/book/ch15-05-interior-mutability.html>
  = note: `#[deny(invalid_reference_casting)]` on by default

Explanation

Casting &T to &mut T without using interior mutability is undefined behavior, as it's a violation of Rust reference aliasing requirements.

UnsafeCell is the only way to obtain aliasable data that is considered mutable.

invalid-type-param-default

The invalid_type_param_default lint detects type parameter defaults erroneously allowed in an invalid location.

Example

fn foo<T=i32>(t: T) {}

This will produce:

error: defaults for type parameters are only allowed in `struct`, `enum`, `type`, or `trait` definitions
 --> lint_example.rs:2:8
  |
2 | fn foo<T=i32>(t: T) {}
  |        ^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #36887 <https://github.com/rust-lang/rust/issues/36887>
  = note: `#[deny(invalid_type_param_default)]` on by default

Explanation

Default type parameters were only intended to be allowed in certain situations, but historically the compiler allowed them everywhere. This is a future-incompatible lint to transition this to a hard error in the future. See issue #36887 for more details.

let-underscore-lock

The let_underscore_lock lint checks for statements which don't bind a mutex to anything, causing the lock to be released immediately instead of at end of scope, which is typically incorrect.

Example

use std::sync::{Arc, Mutex};
use std::thread;
let data = Arc::new(Mutex::new(0));

thread::spawn(move || {
    // The lock is immediately released instead of at the end of the
    // scope, which is probably not intended.
    let _ = data.lock().unwrap();
    println!("doing some work");
    let mut lock = data.lock().unwrap();
    *lock += 1;
});

This will produce:

error: non-binding let on a synchronization lock
 --> lint_example.rs:9:9
  |
9 |     let _ = data.lock().unwrap();
  |         ^ this lock is not assigned to a binding and is immediately dropped
  |
  = note: `#[deny(let_underscore_lock)]` on by default
help: consider binding to an unused variable to avoid immediately dropping the value
  |
9 |     let _unused = data.lock().unwrap();
  |         ~~~~~~~
help: consider immediately dropping the value
  |
9 |     drop(data.lock().unwrap());
  |     ~~~~~                    +

Explanation

Statements which assign an expression to an underscore causes the expression to immediately drop instead of extending the expression's lifetime to the end of the scope. This is usually unintended, especially for types like MutexGuard, which are typically used to lock a mutex for the duration of an entire scope.

If you want to extend the expression's lifetime to the end of the scope, assign an underscore-prefixed name (such as _foo) to the expression. If you do actually want to drop the expression immediately, then calling std::mem::drop on the expression is clearer and helps convey intent.

long-running-const-eval

The long_running_const_eval lint is emitted when const eval is running for a long time to ensure rustc terminates even if you accidentally wrote an infinite loop.

Example

const FOO: () = loop {};

This will produce:

error: constant evaluation is taking a long time
 --> lint_example.rs:2:17
  |
2 | const FOO: () = loop {};
  |                 ^^^^^^^
  |
  = note: this lint makes sure the compiler doesn't get stuck due to infinite loops in const eval.
          If your compilation actually takes a long time, you can safely allow the lint.
help: the constant being evaluated
 --> lint_example.rs:2:1
  |
2 | const FOO: () = loop {};
  | ^^^^^^^^^^^^^
  = note: `#[deny(long_running_const_eval)]` on by default

Explanation

Loops allow const evaluation to compute arbitrary code, but may also cause infinite loops or just very long running computations. Users can enable long running computations by allowing the lint on individual constants or for entire crates.

Unconditional warnings

Note that regardless of whether the lint is allowed or set to warn, the compiler will issue warnings if constant evaluation runs significantly longer than this lint's limit. These warnings are also shown to downstream users from crates.io or similar registries. If you are above the lint's limit, both you and downstream users might be exposed to these warnings. They might also appear on compiler updates, as the compiler makes minor changes about how complexity is measured: staying below the limit ensures that there is enough room, and given that the lint is disabled for people who use your dependency it means you will be the only one to get the warning and can put out an update in your own time.

macro-expanded-macro-exports-accessed-by-absolute-paths

The macro_expanded_macro_exports_accessed_by_absolute_paths lint detects macro-expanded macro_export macros from the current crate that cannot be referred to by absolute paths.

Example

macro_rules! define_exported {
    () => {
        #[macro_export]
        macro_rules! exported {
            () => {};
        }
    };
}

define_exported!();

fn main() {
    crate::exported!();
}

This will produce:

error: macro-expanded `macro_export` macros from the current crate cannot be referred to by absolute paths
  --> lint_example.rs:13:5
   |
13 |     crate::exported!();
   |     ^^^^^^^^^^^^^^^
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #52234 <https://github.com/rust-lang/rust/issues/52234>
note: the macro is defined here
  --> lint_example.rs:4:9
   |
4  | /         macro_rules! exported {
5  | |             () => {};
6  | |         }
   | |_________^
...
10 |   define_exported!();
   |   ------------------ in this macro invocation
   = note: `#[deny(macro_expanded_macro_exports_accessed_by_absolute_paths)]` on by default
   = note: this error originates in the macro `define_exported` (in Nightly builds, run with -Z macro-backtrace for more info)

Explanation

The intent is that all macros marked with the #[macro_export] attribute are made available in the root of the crate. However, when a macro_rules! definition is generated by another macro, the macro expansion is unable to uphold this rule. This is a future-incompatible lint to transition this to a hard error in the future. See issue #53495 for more details.

missing-fragment-specifier

The missing_fragment_specifier lint is issued when an unused pattern in a macro_rules! macro definition has a meta-variable (e.g. $e) that is not followed by a fragment specifier (e.g. :expr).

This warning can always be fixed by removing the unused pattern in the macro_rules! macro definition.

Example

macro_rules! foo {
   () => {};
   ($name) => { };
}

fn main() {
   foo!();
}

This will produce:

error: missing fragment specifier
 --> lint_example.rs:3:5
  |
3 |    ($name) => { };
  |     ^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #40107 <https://github.com/rust-lang/rust/issues/40107>
  = note: `#[deny(missing_fragment_specifier)]` on by default

Explanation

To fix this, remove the unused pattern from the macro_rules! macro definition:

macro_rules! foo {
    () => {};
}
fn main() {
    foo!();
}

mutable-transmutes

The mutable_transmutes lint catches transmuting from &T to &mut T because it is undefined behavior.

Example

unsafe {
    let y = std::mem::transmute::<&i32, &mut i32>(&5);
}

This will produce:

error: transmuting &T to &mut T is undefined behavior, even if the reference is unused, consider instead using an UnsafeCell
 --> lint_example.rs:3:13
  |
3 |     let y = std::mem::transmute::<&i32, &mut i32>(&5);
  |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[deny(mutable_transmutes)]` on by default

Explanation

Certain assumptions are made about aliasing of data, and this transmute violates those assumptions. Consider using UnsafeCell instead.

named-asm-labels

The named_asm_labels lint detects the use of named labels in the inline asm! macro.

Example

#![feature(asm_experimental_arch)]
use std::arch::asm;

fn main() {
    unsafe {
        asm!("foo: bar");
    }
}

This will produce:

error: avoid using named labels in inline assembly
 --> lint_example.rs:6:15
  |
6 |         asm!("foo: bar");
  |               ^^^
  |
  = help: only local labels of the form `<number>:` should be used in inline asm
  = note: see the asm section of Rust By Example <https://doc.rust-lang.org/nightly/rust-by-example/unsafe/asm.html#labels> for more information
  = note: `#[deny(named_asm_labels)]` on by default

Explanation

LLVM is allowed to duplicate inline assembly blocks for any reason, for example when it is in a function that gets inlined. Because of this, GNU assembler local labels must be used instead of labels with a name. Using named labels might cause assembler or linker errors.

See the explanation in Rust By Example for more details.

no-mangle-const-items

The no_mangle_const_items lint detects any const items with the no_mangle attribute.

Example

#[no_mangle]
const FOO: i32 = 5;

This will produce:

error: const items should never be `#[no_mangle]`
 --> lint_example.rs:3:1
  |
3 | const FOO: i32 = 5;
  | -----^^^^^^^^^^^^^^
  | |
  | help: try a static value: `pub static`
  |
  = note: `#[deny(no_mangle_const_items)]` on by default

Explanation

Constants do not have their symbols exported, and therefore, this probably means you meant to use a static, not a const.

order-dependent-trait-objects

The order_dependent_trait_objects lint detects a trait coherency violation that would allow creating two trait impls for the same dynamic trait object involving marker traits.

Example

pub trait Trait {}

impl Trait for dyn Send + Sync { }
impl Trait for dyn Sync + Send { }

This will produce:

error: conflicting implementations of trait `Trait` for type `(dyn Send + Sync + 'static)`: (E0119)
 --> lint_example.rs:5:1
  |
4 | impl Trait for dyn Send + Sync { }
  | ------------------------------ first implementation here
5 | impl Trait for dyn Sync + Send { }
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `(dyn Send + Sync + 'static)`
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #56484 <https://github.com/rust-lang/rust/issues/56484>
  = note: `#[deny(order_dependent_trait_objects)]` on by default

Explanation

A previous bug caused the compiler to interpret traits with different orders (such as Send + Sync and Sync + Send) as distinct types when they were intended to be treated the same. This allowed code to define separate trait implementations when there should be a coherence error. This is a future-incompatible lint to transition this to a hard error in the future. See issue #56484 for more details.

overflowing-literals

The overflowing_literals lint detects literal out of range for its type.

Example

let x: u8 = 1000;

This will produce:

error: literal out of range for `u8`
 --> lint_example.rs:2:13
  |
2 | let x: u8 = 1000;
  |             ^^^^
  |
  = note: the literal `1000` does not fit into the type `u8` whose range is `0..=255`
  = note: `#[deny(overflowing_literals)]` on by default

Explanation

It is usually a mistake to use a literal that overflows the type where it is used. Either use a literal that is within range, or change the type to be within the range of the literal.

patterns-in-fns-without-body

The patterns_in_fns_without_body lint detects mut identifier patterns as a parameter in functions without a body.

Example

trait Trait {
    fn foo(mut arg: u8);
}

This will produce:

error: patterns aren't allowed in functions without bodies
 --> lint_example.rs:3:12
  |
3 |     fn foo(mut arg: u8);
  |            ^^^^^^^ help: remove `mut` from the parameter: `arg`
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #35203 <https://github.com/rust-lang/rust/issues/35203>
  = note: `#[deny(patterns_in_fns_without_body)]` on by default

Explanation

To fix this, remove mut from the parameter in the trait definition; it can be used in the implementation. That is, the following is OK:

trait Trait {
    fn foo(arg: u8); // Removed `mut` here
}

impl Trait for i32 {
    fn foo(mut arg: u8) { // `mut` here is OK

    }
}

Trait definitions can define functions without a body to specify a function that implementors must define. The parameter names in the body-less functions are only allowed to be _ or an identifier for documentation purposes (only the type is relevant). Previous versions of the compiler erroneously allowed identifier patterns with the mut keyword, but this was not intended to be allowed. This is a future-incompatible lint to transition this to a hard error in the future. See issue #35203 for more details.

proc-macro-derive-resolution-fallback

The proc_macro_derive_resolution_fallback lint detects proc macro derives using inaccessible names from parent modules.

Example

// foo.rs
#![crate_type = "proc-macro"]

extern crate proc_macro;

use proc_macro::*;

#[proc_macro_derive(Foo)]
pub fn foo1(a: TokenStream) -> TokenStream {
    drop(a);
    "mod __bar { static mut BAR: Option<Something> = None; }".parse().unwrap()
}

// bar.rs
#[macro_use]
extern crate foo;

struct Something;

#[derive(Foo)]
struct Another;

fn main() {}

This will produce:

warning: cannot find type `Something` in this scope
 --> src/main.rs:8:10
  |
8 | #[derive(Foo)]
  |          ^^^ names from parent modules are not accessible without an explicit import
  |
  = note: `#[warn(proc_macro_derive_resolution_fallback)]` on by default
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #50504 <https://github.com/rust-lang/rust/issues/50504>

Explanation

If a proc-macro generates a module, the compiler unintentionally allowed items in that module to refer to items in the crate root without importing them. This is a future-incompatible lint to transition this to a hard error in the future. See issue #50504 for more details.

pub-use-of-private-extern-crate

The pub_use_of_private_extern_crate lint detects a specific situation of re-exporting a private extern crate.

Example

extern crate core;
pub use core as reexported_core;

This will produce:

error[E0365]: extern crate `core` is private and cannot be re-exported
 --> lint_example.rs:3:9
  |
3 | pub use core as reexported_core;
  |         ^^^^^^^^^^^^^^^^^^^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #127909 <https://github.com/rust-lang/rust/issues/127909>
  = note: `#[deny(pub_use_of_private_extern_crate)]` on by default
help: consider making the `extern crate` item publicly accessible
  |
2 | pub extern crate core;
  | +++

Explanation

A public use declaration should not be used to publicly re-export a private extern crate. pub extern crate should be used instead.

This was historically allowed, but is not the intended behavior according to the visibility rules. This is a future-incompatible lint to transition this to a hard error in the future. See issue #127909 for more details.

soft-unstable

The soft_unstable lint detects unstable features that were unintentionally allowed on stable.

Example

#[cfg(test)]
extern crate test;

#[bench]
fn name(b: &mut test::Bencher) {
    b.iter(|| 123)
}

This will produce:

error: use of unstable library feature `test`: `bench` is a part of custom test frameworks which are unstable
 --> lint_example.rs:5:3
  |
5 | #[bench]
  |   ^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #64266 <https://github.com/rust-lang/rust/issues/64266>
  = note: `#[deny(soft_unstable)]` on by default

Explanation

The bench attribute was accidentally allowed to be specified on the stable release channel. Turning this to a hard error would have broken some projects. This lint allows those projects to continue to build correctly when --cap-lints is used, but otherwise signal an error that #[bench] should not be used on the stable channel. This is a future-incompatible lint to transition this to a hard error in the future. See issue #64266 for more details.

test-unstable-lint

The test_unstable_lint lint tests unstable lints and is perma-unstable.

Example

#![allow(test_unstable_lint)]

This will produce:

warning: unknown lint: `test_unstable_lint`
 --> lint_example.rs:1:1
  |
1 | #![allow(test_unstable_lint)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: the `test_unstable_lint` lint is unstable
  = help: add `#![feature(test_unstable_lint)]` to the crate attributes to enable
  = note: this compiler was built on 2024-11-10; consider upgrading it if it is out of date
  = note: `#[warn(unknown_lints)]` on by default

Explanation

In order to test the behavior of unstable lints, a permanently-unstable lint is required. This lint can be used to trigger warnings and errors from the compiler related to unstable lints.

text-direction-codepoint-in-comment

The text_direction_codepoint_in_comment lint detects Unicode codepoints in comments that change the visual representation of text on screen in a way that does not correspond to their on memory representation.

Example

#![deny(text_direction_codepoint_in_comment)]
fn main() {
    println!("{:?}"); // '‮');
}

This will produce:

error: unicode codepoint changing visible direction of text present in comment
 --> lint_example.rs:3:23
  |
3 |     println!("{:?}"); // '�');
  |                       ^^^^-^^^
  |                       |   |
  |                       |   '\u{202e}'
  |                       this comment contains an invisible unicode text flow control codepoint
  |
  = note: these kind of unicode codepoints change the way text flows on applications that support them, but can cause confusion because they change the order of characters on the screen
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(text_direction_codepoint_in_comment)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = help: if their presence wasn't intentional, you can remove them

Explanation

Unicode allows changing the visual flow of text on screen in order to support scripts that are written right-to-left, but a specially crafted comment can make code that will be compiled appear to be part of a comment, depending on the software used to read the code. To avoid potential problems or confusion, such as in CVE-2021-42574, by default we deny their use.

text-direction-codepoint-in-literal

The text_direction_codepoint_in_literal lint detects Unicode codepoints that change the visual representation of text on screen in a way that does not correspond to their on memory representation.

Explanation

The unicode characters \u{202A}, \u{202B}, \u{202D}, \u{202E}, \u{2066}, \u{2067}, \u{2068}, \u{202C} and \u{2069} make the flow of text on screen change its direction on software that supports these codepoints. This makes the text "abc" display as "cba" on screen. By leveraging software that supports these, people can write specially crafted literals that make the surrounding code seem like it's performing one action, when in reality it is performing another. Because of this, we proactively lint against their presence to avoid surprises.

Example

#![deny(text_direction_codepoint_in_literal)]
fn main() {
    println!("{:?}", '‮');
}

This will produce:

error: unicode codepoint changing visible direction of text present in literal
 --> lint_example.rs:3:22
  |
3 |     println!("{:?}", '�');
  |                      ^-^
  |                      ||
  |                      |'\u{202e}'
  |                      this literal contains an invisible unicode text flow control codepoint
  |
  = note: these kind of unicode codepoints change the way text flows on applications that support them, but can cause confusion because they change the order of characters on the screen
note: the lint level is defined here
 --> lint_example.rs:1:9
  |
1 | #![deny(text_direction_codepoint_in_literal)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = help: if their presence wasn't intentional, you can remove them
help: if you want to keep them but make them visible in your source code, you can escape them
  |
3 |     println!("{:?}", '\u{202e}');
  |                       ~~~~~~~~

unconditional-panic

The unconditional_panic lint detects an operation that will cause a panic at runtime.

Example

#![allow(unused)]
let x = 1 / 0;

This will produce:

error: this operation will panic at runtime
 --> lint_example.rs:3:9
  |
3 | let x = 1 / 0;
  |         ^^^^^ attempt to divide `1_i32` by zero
  |
  = note: `#[deny(unconditional_panic)]` on by default

Explanation

This lint detects code that is very likely incorrect because it will always panic, such as division by zero and out-of-bounds array accesses. Consider adjusting your code if this is a bug, or using the panic! or unreachable! macro instead in case the panic is intended.

undropped-manually-drops

The undropped_manually_drops lint check for calls to std::mem::drop with a value of std::mem::ManuallyDrop which doesn't drop.

Example

struct S;
drop(std::mem::ManuallyDrop::new(S));

This will produce:

error: calls to `std::mem::drop` with `std::mem::ManuallyDrop` instead of the inner value does nothing
 --> lint_example.rs:3:1
  |
3 | drop(std::mem::ManuallyDrop::new(S));
  | ^^^^^------------------------------^
  |      |
  |      argument has type `ManuallyDrop<S>`
  |
  = note: `#[deny(undropped_manually_drops)]` on by default
help: use `std::mem::ManuallyDrop::into_inner` to get the inner value
  |
3 | drop(std::mem::ManuallyDrop::into_inner(std::mem::ManuallyDrop::new(S)));
  |      +++++++++++++++++++++++++++++++++++                              +

Explanation

ManuallyDrop does not drop it's inner value so calling std::mem::drop will not drop the inner value of the ManuallyDrop either.

unknown-crate-types

The unknown_crate_types lint detects an unknown crate type found in a crate_type attribute.

Example

#![crate_type="lol"]
fn main() {}

This will produce:

error: invalid `crate_type` value
 --> lint_example.rs:1:15
  |
1 | #![crate_type="lol"]
  |               ^^^^^
  |
  = note: `#[deny(unknown_crate_types)]` on by default

Explanation

An unknown value give to the crate_type attribute is almost certainly a mistake.

useless-deprecated

The useless_deprecated lint detects deprecation attributes with no effect.

Example

struct X;

#[deprecated = "message"]
impl Default for X {
    fn default() -> Self {
        X
    }
}

This will produce:

error: this `#[deprecated]` annotation has no effect
 --> lint_example.rs:4:1
  |
4 | #[deprecated = "message"]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the unnecessary deprecation attribute
  |
  = note: `#[deny(useless_deprecated)]` on by default

Explanation

Deprecation attributes have no effect on trait implementations.

wasm-c-abi

The wasm_c_abi lint detects crate dependencies that are incompatible with future versions of Rust that will emit spec-compliant C ABI.

Example

#![deny(wasm_c_abi)]

This will produce:

error: the following packages contain code that will be rejected by a future version of Rust: wasm-bindgen v0.2.87
  |
note: the lint level is defined here
 --> src/lib.rs:1:9
  |
1 | #![deny(wasm_c_abi)]
  |         ^^^^^^^^^^

Explanation

Rust has historically emitted non-spec-compliant C ABI. This has caused incompatibilities between other compilers and Wasm targets. In a future version of Rust this will be fixed and therefore dependencies relying on the non-spec-compliant C ABI will stop functioning.

JSON Output

This chapter documents the JSON structures emitted by rustc. JSON may be enabled with the --error-format=json flag. Additional options may be specified with the --json flag which can change which messages are generated, and the format of the messages.

JSON messages are emitted one per line to stderr.

If parsing the output with Rust, the cargo_metadata crate provides some support for parsing the messages.

Each type of message has a $message_type field which can be used to distinguish the different formats. When parsing, care should be taken to be forwards-compatible with future changes to the format. Optional values may be null. New fields may be added. Enumerated fields like "level" or "suggestion_applicability" may add new values.

Diagnostics

Diagnostic messages provide errors or possible concerns generated during compilation. rustc provides detailed information about where the diagnostic originates, along with hints and suggestions.

Diagnostics are arranged in a parent/child relationship where the parent diagnostic value is the core of the diagnostic, and the attached children provide additional context, help, and information.

Diagnostics have the following format:

{
    /* Type of this message */
    "$message_type": "diagnostic",
    /* The primary message. */
    "message": "unused variable: `x`",
    /* The diagnostic code.
       Some messages may set this value to null.
    */
    "code": {
        /* A unique string identifying which diagnostic triggered. */
        "code": "unused_variables",
        /* An optional string explaining more detail about the diagnostic code. */
        "explanation": null
    },
    /* The severity of the diagnostic.
       Values may be:
       - "error": A fatal error that prevents compilation.
       - "warning": A possible error or concern.
       - "note": Additional information or context about the diagnostic.
       - "help": A suggestion on how to resolve the diagnostic.
       - "failure-note": A note attached to the message for further information.
       - "error: internal compiler error": Indicates a bug within the compiler.
    */
    "level": "warning",
    /* An array of source code locations to point out specific details about
       where the diagnostic originates from. This may be empty, for example
       for some global messages, or child messages attached to a parent.

       Character offsets are offsets of Unicode Scalar Values.
    */
    "spans": [
        {
            /* The file where the span is located.
               Note that this path may not exist. For example, if the path
               points to the standard library, and the rust src is not
               available in the sysroot, then it may point to a nonexistent
               file. Beware that this may also point to the source of an
               external crate.
            */
            "file_name": "lib.rs",
            /* The byte offset where the span starts (0-based, inclusive). */
            "byte_start": 21,
            /* The byte offset where the span ends (0-based, exclusive). */
            "byte_end": 22,
            /* The first line number of the span (1-based, inclusive). */
            "line_start": 2,
            /* The last line number of the span (1-based, inclusive). */
            "line_end": 2,
            /* The first character offset of the line_start (1-based, inclusive). */
            "column_start": 9,
            /* The last character offset of the line_end (1-based, exclusive). */
            "column_end": 10,
            /* Whether or not this is the "primary" span.

               This indicates that this span is the focal point of the
               diagnostic.

               There are rare cases where multiple spans may be marked as
               primary. For example, "immutable borrow occurs here" and
               "mutable borrow ends here" can be two separate primary spans.

               The top (parent) message should always have at least one
               primary span, unless it has zero spans. Child messages may have
               zero or more primary spans.
            */
            "is_primary": true,
            /* An array of objects showing the original source code for this
               span. This shows the entire lines of text where the span is
               located. A span across multiple lines will have a separate
               value for each line.
            */
            "text": [
                {
                    /* The entire line of the original source code. */
                    "text": "    let x = 123;",
                    /* The first character offset of the line of
                       where the span covers this line (1-based, inclusive). */
                    "highlight_start": 9,
                    /* The last character offset of the line of
                       where the span covers this line (1-based, exclusive). */
                    "highlight_end": 10
                }
            ],
            /* An optional message to display at this span location.
               This is typically null for primary spans.
            */
            "label": null,
            /* An optional string of a suggested replacement for this span to
               solve the issue. Tools may try to replace the contents of the
               span with this text.
            */
            "suggested_replacement": null,
            /* An optional string that indicates the confidence of the
               "suggested_replacement". Tools may use this value to determine
               whether or not suggestions should be automatically applied.

               Possible values may be:
               - "MachineApplicable": The suggestion is definitely what the
                 user intended. This suggestion should be automatically
                 applied.
               - "MaybeIncorrect": The suggestion may be what the user
                 intended, but it is uncertain. The suggestion should result
                 in valid Rust code if it is applied.
               - "HasPlaceholders": The suggestion contains placeholders like
                 `(...)`. The suggestion cannot be applied automatically
                 because it will not result in valid Rust code. The user will
                 need to fill in the placeholders.
               - "Unspecified": The applicability of the suggestion is unknown.
            */
            "suggestion_applicability": null,
            /* An optional object indicating the expansion of a macro within
               this span.

               If a message occurs within a macro invocation, this object will
               provide details of where within the macro expansion the message
               is located.
            */
            "expansion": {
                /* The span of the macro invocation.
                   Uses the same span definition as the "spans" array.
                */
                "span": {/*...*/}
                /* Name of the macro, such as "foo!" or "#[derive(Eq)]". */
                "macro_decl_name": "some_macro!",
                /* Optional span where the relevant part of the macro is
                  defined. */
                "def_site_span": {/*...*/},
            }
        }
    ],
    /* Array of attached diagnostic messages.
       This is an array of objects using the same format as the parent
       message. Children are not nested (children do not themselves
       contain "children" definitions).
    */
    "children": [
        {
            "message": "`#[warn(unused_variables)]` on by default",
            "code": null,
            "level": "note",
            "spans": [],
            "children": [],
            "rendered": null
        },
        {
            "message": "if this is intentional, prefix it with an underscore",
            "code": null,
            "level": "help",
            "spans": [
                {
                    "file_name": "lib.rs",
                    "byte_start": 21,
                    "byte_end": 22,
                    "line_start": 2,
                    "line_end": 2,
                    "column_start": 9,
                    "column_end": 10,
                    "is_primary": true,
                    "text": [
                        {
                            "text": "    let x = 123;",
                            "highlight_start": 9,
                            "highlight_end": 10
                        }
                    ],
                    "label": null,
                    "suggested_replacement": "_x",
                    "suggestion_applicability": "MachineApplicable",
                    "expansion": null
                }
            ],
            "children": [],
            "rendered": null
        }
    ],
    /* Optional string of the rendered version of the diagnostic as displayed
       by rustc. Note that this may be influenced by the `--json` flag.
    */
    "rendered": "warning: unused variable: `x`\n --> lib.rs:2:9\n  |\n2 |     let x = 123;\n  |         ^ help: if this is intentional, prefix it with an underscore: `_x`\n  |\n  = note: `#[warn(unused_variables)]` on by default\n\n"
}

Artifact notifications

Artifact notifications are emitted when the --json=artifacts flag is used. They indicate that a file artifact has been saved to disk. More information about emit kinds may be found in the --emit flag documentation. Notifications can contain more than one file for each type, for example when using multiple codegen units.

{
    /* Type of this message */
    "$message_type": "artifact",
    /* The filename that was generated. */
    "artifact": "libfoo.rlib",
    /* The kind of artifact that was generated. Possible values:
       - "link": The generated crate as specified by the crate-type.
       - "dep-info": The `.d` file with dependency information in a Makefile-like syntax.
       - "metadata": The Rust `.rmeta` file containing metadata about the crate.
       - "asm": The `.s` file with generated assembly
       - "llvm-ir": The `.ll` file with generated textual LLVM IR
       - "llvm-bc": The `.bc` file with generated LLVM bitcode
       - "mir": The `.mir` file with rustc's mid-level intermediate representation.
       - "obj": The `.o` file with generated native object code
    */
    "emit": "link"
}

Future-incompatible reports

If the --json=future-incompat flag is used, then a separate JSON structure will be emitted if the crate may stop compiling in the future. This contains diagnostic information about the particular warnings that may be turned into a hard error in the future. This will include the diagnostic information, even if the diagnostics have been suppressed (such as with an #[allow] attribute or the --cap-lints option).

{
    /* Type of this message */
    "$message_type": "future_incompat",
    /* An array of objects describing a warning that will become a hard error
       in the future.
    */
    "future_incompat_report":
    [
        {
            /* A diagnostic structure as defined in
               https://doc.rust-lang.org/rustc/json.html#diagnostics
            */
            "diagnostic": {...},
        }
    ]
}

Unused Dependency Notifications

The options --json=unused-externs and --json=unused-externs-silent in conjunction with the unused-crate-dependencies lint will emit JSON structures reporting any crate dependencies (specified with --extern) which never had any symbols referenced. These are intended to be consumed by the build system which can then emit diagnostics telling the user to remove the unused dependencies from Cargo.toml (or whatever build-system file defines dependencies).

The JSON structure is:

{
    "lint_level": "deny", /* Level of the warning */
    "unused_names": [
        "foo"  /* Names of unused crates, as specified with --extern foo=libfoo.rlib */
    ],
}

The warn/deny/forbid lint level (as defined either on the command line or in the source) dictates the lint_level in the JSON. With unused-externs, a deny or forbid level diagnostic will also cause rustc to exit with a failure exit code.

unused-externs-silent will report the diagnostic the same way, but will not cause rustc to exit with failure - it's up to the consumer to flag failure appropriately. (This is needed by Cargo which shares the same dependencies across multiple build targets, so it should only report an unused dependency if its not used by any of the targets.)

Tests

rustc has a built-in facility for building and running tests for a crate. More information about writing and running tests may be found in the Testing Chapter of the Rust Programming Language book.

Tests are written as free functions with the #[test] attribute. For example:

#[test]
fn it_works() {
    assert_eq!(2 + 2, 4);
}

Tests "pass" if they return without an error. They "fail" if they panic, or return a type such as Result that implements the Termination trait with a non-zero value.

By passing the --test option to rustc, the compiler will build the crate in a special mode to construct an executable that will run the tests in the crate. The --test flag will make the following changes:

• The crate will be built as a bin crate type, forcing it to be an executable.
• Links the executable with libtest, the test harness that is part of the standard library, which handles running the tests.
• Synthesizes a main function which will process command-line arguments and run the tests. This new main function will replace any existing main function as the entry point of the executable, though the existing main will still be compiled.
• Enables the test cfg option, which allows your code to use conditional compilation to detect if it is being built as a test.
• Enables building of functions annotated with the test and bench attributes, which will be run by the test harness.

After the executable is created, you can run it to execute the tests and receive a report on what passes and fails. If you are using Cargo to manage your project, it has a built-in cargo test command which handles all of this automatically. An example of the output looks like this:

running 4 tests
test it_works ... ok
test check_valid_args ... ok
test invalid_characters ... ok
test walks_the_dog ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Note: Tests must be built with the unwind panic strategy. This is because all tests run in the same process, and they are intended to catch panics, which is not possible with the abort strategy. See the unstable -Z panic-abort-tests option for experimental support of the abort strategy by spawning tests in separate processes.

Test attributes

Tests are indicated using attributes on free functions. The following attributes are used for testing, see the linked documentation for more details:

• #[test] — Indicates a function is a test to be run.
• #[bench] — Indicates a function is a benchmark to be run. Benchmarks are currently unstable and only available in the nightly channel, see the unstable docs for more details.
• #[should_panic] — Indicates that the test function will only pass if the function panics.
• #[ignore] — Indicates that the test function will be compiled, but not run by default. See the --ignored and --include-ignored options to run these tests.

CLI arguments

The libtest harness has several command-line arguments to control its behavior.

Note: When running with cargo test, the libtest CLI arguments must be passed after the -- argument to differentiate between flags for Cargo and those for the harness. For example: cargo test -- --nocapture

Filters

Positional arguments (those without a - prefix) are treated as filters which will only run tests whose name matches one of those strings. The filter will match any substring found in the full path of the test function. For example, if the test function it_works is located in the module utils::paths::tests, then any of the filters works, path, utils::, or utils::paths::tests::it_works will match that test.

See Selection options for more options to control which tests are run.

Action options

The following options perform different actions other than running tests.

--list

Prints a list of all tests and benchmarks. Does not run any of the tests. Filters can be used to list only matching tests.

-h, --help

Displays usage information and command-line options.

Selection options

The following options change how tests are selected.

--test

This is the default mode where all tests will be run as well as running all benchmarks with only a single iteration (to ensure the benchmark works, without taking the time to actually perform benchmarking). This can be combined with the --bench flag to run both tests and perform full benchmarking.

--bench

This runs in a mode where tests are ignored, and only runs benchmarks. This can be combined with --test to run both benchmarks and tests.

--exact

This forces filters to match the full path of the test exactly. For example, if the test it_works is in the module utils::paths::tests, then only the string utils::paths::tests::it_works will match that test.

--skip FILTER

Skips any tests whose name contains the given FILTER string. This flag may be passed multiple times.

--ignored

Runs only tests that are marked with the ignore attribute.

--include-ignored

Runs both ignored and non-ignored tests.

--exclude-should-panic

Excludes tests marked with the should_panic attribute.

⚠️ 🚧 This option is unstable, and requires the -Z unstable-options flag. See tracking issue #82348 for more information.

Execution options

The following options affect how tests are executed.

--test-threads NUM_THREADS

Sets the number of threads to use for running tests in parallel. By default, uses the amount of concurrency available on the hardware as indicated by available_parallelism.

This can also be specified with the RUST_TEST_THREADS environment variable.

--force-run-in-process

Forces the tests to run in a single process when using the abort panic strategy.

⚠️ 🚧 This only works with the unstable -Z panic-abort-tests option, and requires the -Z unstable-options flag. See tracking issue #67650 for more information.

--ensure-time

⚠️ 🚧 This option is unstable, and requires the -Z unstable-options flag. See tracking issue #64888 and the unstable docs for more information.

--shuffle

Runs the tests in random order, as opposed to the default alphabetical order.

This may also be specified by setting the RUST_TEST_SHUFFLE environment variable to anything but 0.

The random number generator seed that is output can be passed to --shuffle-seed to run the tests in the same order again.

Note that --shuffle does not affect whether the tests are run in parallel. To run the tests in random order sequentially, use --shuffle --test-threads 1.

⚠️ 🚧 This option is unstable, and requires the -Z unstable-options flag. See tracking issue #89583 for more information.

--shuffle-seed SEED

Like --shuffle, but seeds the random number generator with SEED. Thus, calling the test harness with --shuffle-seed SEED twice runs the tests in the same order both times.

SEED is any 64-bit unsigned integer, for example, one produced by --shuffle.

This can also be specified with the RUST_TEST_SHUFFLE_SEED environment variable.

⚠️ 🚧 This option is unstable, and requires the -Z unstable-options flag. See tracking issue #89583 for more information.

Output options

The following options affect the output behavior.

-q, --quiet

Displays one character per test instead of one line per test. This is an alias for --format=terse.

--nocapture

Does not capture the stdout and stderr of the test, and allows tests to print to the console. Usually the output is captured, and only displayed if the test fails.

This may also be specified by setting the RUST_TEST_NOCAPTURE environment variable to anything but 0.

--show-output

Displays the stdout and stderr of successful tests after all tests have run.

Contrast this with --nocapture which allows tests to print while they are running, which can cause interleaved output if there are multiple tests running in parallel, --show-output ensures the output is contiguous, but requires waiting for all tests to finish.

--color COLOR

Control when colored terminal output is used. Valid options:

• auto: Colorize if stdout is a tty and --nocapture is not used. This is the default.
• always: Always colorize the output.
• never: Never colorize the output.

--format FORMAT

Controls the format of the output. Valid options:

• pretty: This is the default format, with one line per test.
• terse: Displays only a single character per test. --quiet is an alias for this option.
• json: Emits JSON objects, one per line. ⚠️ 🚧 This option is unstable, and requires the -Z unstable-options flag. See tracking issue #49359 for more information.

--logfile PATH

Writes the results of the tests to the given file.

--report-time

⚠️ 🚧 This option is unstable, and requires the -Z unstable-options flag. See tracking issue #64888 and the unstable docs for more information.

Unstable options

Some CLI options are added in an "unstable" state, where they are intended for experimentation and testing to determine if the option works correctly, has the right design, and is useful. The option may not work correctly, break, or change at any time. To signal that you acknowledge that you are using an unstable option, they require passing the -Z unstable-options command-line flag.

Benchmarks

The libtest harness supports running benchmarks for functions annotated with the #[bench] attribute. Benchmarks are currently unstable, and only available on the nightly channel. More information may be found in the unstable book.

Custom test frameworks

Experimental support for using custom test harnesses is available on the nightly channel. See tracking issue #50297 and the custom_test_frameworks documentation for more information.

Platform Support

Support for different platforms ("targets") are organized into three tiers, each with a different set of guarantees. For more information on the policies for targets at each tier, see the Target Tier Policy.

Targets are identified by their "target triple" which is the string to inform the compiler what kind of output should be produced.

Component availability is tracked here.

Tier 1 with Host Tools

Tier 1 targets can be thought of as "guaranteed to work". The Rust project builds official binary releases for each tier 1 target, and automated testing ensures that each tier 1 target builds and passes tests after each change.

Tier 1 targets with host tools additionally support running tools like rustc and cargo natively on the target, and automated testing ensures that tests pass for the host tools as well. This allows the target to be used as a development platform, not just a compilation target. For the full requirements, see Tier 1 with Host Tools in the Target Tier Policy.

All tier 1 targets with host tools support the full standard library.

Tier 1

Tier 1 targets can be thought of as "guaranteed to work". The Rust project builds official binary releases for each tier 1 target, and automated testing ensures that each tier 1 target builds and passes tests after each change. For the full requirements, see Tier 1 target policy in the Target Tier Policy.

At this time, all Tier 1 targets are Tier 1 with Host Tools.

Tier 2 with Host Tools

Tier 2 targets can be thought of as "guaranteed to build". The Rust project builds official binary releases of the standard library (or, in some cases, only the core library) for each tier 2 target, and automated builds ensure that each tier 2 target can be used as build target after each change. Automated tests are not always run so it's not guaranteed to produce a working build, but tier 2 targets often work to quite a good degree and patches are always welcome!

Tier 2 target-specific code is not closely scrutinized by Rust team(s) when modifications are made. Bugs are possible in all code, but the level of quality control for these targets is likely to be lower. See library team policy for details on the review practices for standard library code.

Tier 2 targets with host tools additionally support running tools like rustc and cargo natively on the target, and automated builds ensure that the host tools build as well. This allows the target to be used as a development platform, not just a compilation target. For the full requirements, see Tier 2 with Host Tools in the Target Tier Policy.

All tier 2 targets with host tools support the full standard library.

NOTE: The rust-docs component is not usually built for tier 2 targets, so Rustup may install the documentation for a similar tier 1 target instead.

Tier 2 without Host Tools

Tier 2 targets can be thought of as "guaranteed to build". The Rust project builds official binary releases of the standard library (or, in some cases, only the core library) for each tier 2 target, and automated builds ensure that each tier 2 target can be used as build target after each change. Automated tests are not always run so it's not guaranteed to produce a working build, but tier 2 targets often work to quite a good degree and patches are always welcome! For the full requirements, see Tier 2 target policy in the Target Tier Policy.

The std column in the table below has the following meanings:

• ✓ indicates the full standard library is available.
• * indicates the target only supports no_std development.
• ? indicates the standard library support is a work-in-progress.

Tier 2 target-specific code is not closely scrutinized by Rust team(s) when modifications are made. Bugs are possible in all code, but the level of quality control for these targets is likely to be lower. See library team policy for details on the review practices for standard library code.

NOTE: The rust-docs component is not usually built for tier 2 targets, so Rustup may install the documentation for a similar tier 1 target instead.

Tier 3

Tier 3 targets are those which the Rust codebase has support for, but which the Rust project does not build or test automatically, so they may or may not work. Official builds are not available. For the full requirements, see Tier 3 target policy in the Target Tier Policy.

The std column in the table below has the following meanings:

• ✓ indicates the full standard library is available.
• * indicates the target only supports no_std development.
• ? indicates the standard library support is unknown or a work-in-progress.

Tier 3 target-specific code is not closely scrutinized by Rust team(s) when modifications are made. Bugs are possible in all code, but the level of quality control for these targets is likely to be lower. See library team policy for details on the review practices for standard library code.

The host column indicates whether the codebase includes support for building host tools.