# Warn-by-default lints

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

- `array_into_iter`
- `asm_sub_register`
- `bare_trait_objects`
- `bindings_with_variant_name`
- `broken_intra_doc_links`
- `cenum_impl_drop_cast`
- `clashing_extern_declarations`
- `coherence_leak_check`
- `confusable_idents`
- `const_evaluatable_unchecked`
- `const_item_mutation`
- `dead_code`
- `deprecated`
- `drop_bounds`
- `ellipsis_inclusive_range_patterns`
- `exported_private_dependencies`
- `forbidden_lint_groups`
- `function_item_references`
- `illegal_floating_point_literal_pattern`
- `improper_ctypes`
- `improper_ctypes_definitions`
- `incomplete_features`
- `indirect_structural_match`
- `inline_no_sanitize`
- `invalid_codeblock_attributes`
- `invalid_value`
- `irrefutable_let_patterns`
- `late_bound_lifetime_arguments`
- `mixed_script_confusables`
- `mutable_borrow_reservation_conflict`
- `no_mangle_generic_items`
- `non_autolinks`
- `non_camel_case_types`
- `non_fmt_panic`
- `non_shorthand_field_patterns`
- `non_snake_case`
- `non_upper_case_globals`
- `nontrivial_structural_match`
- `overlapping_range_endpoints`
- `path_statements`
- `private_in_public`
- `private_intra_doc_links`
- `proc_macro_derive_resolution_fallback`
- `redundant_semicolons`
- `renamed_and_removed_lints`
- `safe_packed_borrows`
- `stable_features`
- `temporary_cstring_as_ptr`
- `trivial_bounds`
- `type_alias_bounds`
- `tyvar_behind_raw_pointer`
- `uncommon_codepoints`
- `unconditional_recursion`
- `uninhabited_static`
- `unknown_lints`
- `unnameable_test_items`
- `unreachable_code`
- `unreachable_patterns`
- `unstable_name_collisions`
- `unsupported_naked_functions`
- `unused_allocation`
- `unused_assignments`
- `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`
- `warnings`
- `where_clauses_object_safety`
- `while_true`

## array-into-iter

The `array_into_iter` lint detects calling `into_iter` on arrays.

### Example

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

This will produce:

    warning: this method call currently resolves to `<&[T; N] as IntoIterator>::into_iter` (due to autoref coercions), but that might change in the future when `IntoIterator` impls for arrays are added.
     --> lint_example.rs:3:11
      |
    3 | [1, 2, 3].into_iter().for_each(|n| { *n; });
      |           ^^^^^^^^^ help: use `.iter()` instead of `.into_iter()` to avoid ambiguity: `iter`
      |
      = note: `#[warn(array_into_iter)]` 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 #66145 <https://github.com/rust-lang/rust/issues/66145>

### Explanation

In the future, it is planned to add an `IntoIter` implementation for arrays such that it will iterate over values of the array instead of references. Due to how method resolution works, this will change existing code that uses `into_iter` on arrays. The solution to avoid this warning is to use `iter()` instead of `into_iter()`.

This is a future-incompatible lint to transition this to a hard error in the future. See issue #66145 for more details and a more thorough description of the lint.

## asm-sub-register

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

### Example

    #![feature(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:6:19
      |
    6 |         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 for more details.

## bare-trait-objects

The `bare_trait_objects` lint suggests using `dyn Trait` for trait objects.

### Example

    #![allow(unused)]
    fn main() {
    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>) {
      |                              ^^^^^ help: use `dyn`: `dyn Trait`
      |
      = note: `#[warn(bare_trait_objects)]` on by default

### 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`.

## bindings-with-variant-name

The `bindings_with_variant_name` lint detects pattern bindings with the same name as one of the matched variants.

### Example

    #![allow(unused)]
    fn main() {
    pub enum Enum {
        Foo,
        Bar,
    }

    pub fn foo(x: Enum) {
        match x {
            Foo => {}
            Bar => {}
        }
    }
    }

This will produce:

    warning[E0170]: pattern binding `Foo` is named the same as one of the variants of the type `Enum`
     --> lint_example.rs:9:9
      |
    9 |         Foo => {}
      |         ^^^ help: to match on the variant, qualify the path: `Enum::Foo`
      |
      = note: `#[warn(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.

## broken-intra-doc-links

The `broken_intra_doc_links` lint detects failures in resolving intra-doc link targets. This is a `rustdoc` only lint, see the documentation in the rustdoc book.

## 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:

    warning: cannot cast enum `E` into integer `u32` because it implements `Drop`
      --> lint_example.rs:14:13
       |
    14 |     let i = e as u32;
       |             ^^^^^^^^
       |
       = note: `#[warn(cenum_impl_drop_cast)]` 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 #73333 <https://github.com/rust-lang/rust/issues/73333>

### 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.

## clashing-extern-declarations

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

### Example

    #![allow(unused)]
    fn main() {
    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: `#[warn(clashing_extern_declarations)]` on by default
      = note: expected `unsafe extern "C" fn()`
                 found `unsafe extern "C" fn(u32)`

### 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

    #![allow(unused)]
    fn main() {
    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 `main::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)`
      |
      = note: `#[warn(coherence_leak_check)]` 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 #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

### 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

    #![allow(unused)]
    #![feature(non_ascii_idents)]

    fn main() {
    // Latin Capital Letter E With Caron
    pub const Ě: i32 = 1;
    // Latin Capital Letter E With Breve
    pub const Ĕ: i32 = 2;
    }

This will produce:

    warning: identifier pair considered confusable between `Ě` and `Ĕ`
     --> lint_example.rs:7:11
      |
    5 | pub const Ě: i32 = 1;
      |           - this is where the previous identifier occurred
    6 | // Latin Capital Letter E With Breve
    7 | pub const Ĕ: i32 = 2;
      |           ^
      |
      = note: `#[warn(confusable_idents)]` on by default

### Explanation

With the `non_ascii_idents` nightly-only feature enabled, identifiers are allowed to use non-ASCII characters. 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

    #![allow(unused)]
    fn main() {
    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>()];
       |                 ^^^^^^^^^^
       |
       = note: `#[warn(const_evaluatable_unchecked)]` 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 #76200 <https://github.com/rust-lang/rust/issues/76200>

### 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: `#[warn(const_item_mutation)]` on by default
      = 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];
      | ^^^^^^^^^^^^^^^^^^^^^^^^^^

### 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 a third-party crate, such as `lazy_static` or `once_cell`.
  - If you are using the nightly channel, consider the new `lazy` module in the standard library.
- 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.

## dead-code

The `dead_code` lint detects unused, unexported items.

### Example

    #![allow(unused)]
    fn main() {
    fn foo() {}
    }

This will produce:

    warning: function is never used: `foo`
     --> 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`. Otherwise consider removing the unused code.

## deprecated

The `deprecated` lint detects use of deprecated items.

### Example

    #![allow(unused)]
    fn main() {
    #[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.

## drop-bounds

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

### Example

    #![allow(unused)]
    fn main() {
    fn foo<T: Drop>() {}
    }

This will produce:

    warning: bounds on `T: Drop` are useless, consider instead using `std::mem::needs_drop` to detect if a type has a destructor
     --> lint_example.rs:2:11
      |
    2 | fn foo<T: Drop>() {}
      |           ^^^^
      |
      = note: `#[warn(drop_bounds)]` on by default

### Explanation

`Drop` bounds do not really accomplish anything. A type may have compiler-generated drop glue without implementing the `Drop` trait itself. The `Drop` trait also only has one method, `Drop::drop`, and that function is by fiat not callable in user code. So there is really no use case for using `Drop` in trait bounds.

The most likely use case of a drop bound is to distinguish between types that have destructors and types that don't. Combined with specialization, a naive coder would write an implementation that assumed a type could be trivially dropped, then write a specialization for `T: Drop` that actually calls the destructor. Except that doing so is not correct; String, for example, doesn't actually implement Drop, but because String contains a Vec, assuming it can be trivially dropped will leak memory.

## ellipsis-inclusive-range-patterns

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

### Example

    #![allow(unused)]
    fn main() {
    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
      |
      = 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.

## 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)]
    #![deny(bad_style)]

    fn main() {}

This will produce:

    warning: deny(bad_style) incompatible with previous forbid
     --> lint_example.rs:2:9
      |
    1 | #![forbid(warnings)]
      |           -------- `forbid` level set here
    2 | #![deny(bad_style)]
      |         ^^^^^^^^^ overruled by previous forbid
      |
      = note: `#[warn(forbidden_lint_groups)]` 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 #81670 <https://github.com/rust-lang/rust/issues/81670>

### 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.

## 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.

## illegal-floating-point-literal-pattern

The `illegal_floating_point_literal_pattern` lint detects floating-point literals used in patterns.

### Example

    #![allow(unused)]
    fn main() {
    let x = 42.0;

    match x {
        5.0 => {}
        _ => {}
    }
    }

This will produce:

    warning: floating-point types cannot be used in patterns
     --> lint_example.rs:5:5
      |
    5 |     5.0 => {}
      |     ^^^
      |
      = note: `#[warn(illegal_floating_point_literal_pattern)]` 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 #41620 <https://github.com/rust-lang/rust/issues/41620>

### Explanation

Previous versions of the compiler accepted floating-point literals in patterns, but it was later determined this was a mistake. The semantics of comparing floating-point values may not be clear in a pattern when contrasted with "structural equality". Typically you can work around this by using a match guard, such as:

    #![allow(unused)]
    fn main() {
    let x = 42.0;

    match x {
        y if y == 5.0 => {}
        _ => {}
    }
    }

This is a future-incompatible lint to transition this to a hard error in the future. See issue #41620 for more details.

## improper-ctypes

The `improper_ctypes` lint detects incorrect use of types in foreign modules.

### Example

    #![allow(unused)]
    fn main() {
    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
      |
      = note: `#[warn(improper_ctypes)]` on by default
      = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct
      = note: this struct has unspecified layout

### 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)]
    fn main() {
    #![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
      |
      = note: `#[warn(improper_ctypes_definitions)]` on by default
      = help: consider using `*const u8` and a length instead
      = note: string slices have no C equivalent

### 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

    #![allow(unused)]
    #![feature(generic_associated_types)]
    fn main() {
    }

This will produce:

    warning: the feature `generic_associated_types` is incomplete and may not be safe to use and/or cause compiler crashes
     --> lint_example.rs:1:12
      |
    1 | #![feature(generic_associated_types)]
      |            ^^^^^^^^^^^^^^^^^^^^^^^^
      |
      = note: `#[warn(incomplete_features)]` on by default
      = note: see issue #44265 <https://github.com/rust-lang/rust/issues/44265> for more information

### 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.

## indirect-structural-match

The `indirect_structural_match` lint detects a `const` in a pattern that manually implements `PartialEq` and `Eq`.

### Example

    #![deny(indirect_structural_match)]

    struct NoDerive(i32);
    impl PartialEq for NoDerive { fn eq(&self, _: &Self) -> bool { false } }
    impl Eq for NoDerive { }
    #[derive(PartialEq, Eq)]
    struct WrapParam<T>(T);
    const WRAP_INDIRECT_PARAM: & &WrapParam<NoDerive> = & &WrapParam(NoDerive(0));
    fn main() {
        match WRAP_INDIRECT_PARAM {
            WRAP_INDIRECT_PARAM => { }
            _ => { }
        }
    }

This will produce:

    error: to use a constant of type `NoDerive` in a pattern, `NoDerive` must be annotated with `#[derive(PartialEq, Eq)]`
      --> lint_example.rs:11:9
       |
    11 |         WRAP_INDIRECT_PARAM => { }
       |         ^^^^^^^^^^^^^^^^^^^
       |
    note: the lint level is defined here
      --> lint_example.rs:1:9
       |
    1  | #![deny(indirect_structural_match)]
       |         ^^^^^^^^^^^^^^^^^^^^^^^^^
       = 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 #62411 <https://github.com/rust-lang/rust/issues/62411>

### Explanation

The compiler unintentionally accepted this form in the past. This is a future-incompatible lint to transition this to a hard error in the future. See issue #62411 for a complete description of the problem, and some possible solutions.

## 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: `#[warn(inline_no_sanitize)]` on by default
    note: inlining requested here
     --> lint_example.rs:3:1
      |
    3 | #[inline(always)]
      | ^^^^^^^^^^^^^^^^^

### Explanation

The use of the `#[inline(always)]` attribute prevents the the `#[no_sanitize(...)]` attribute from working. Consider temporarily removing `inline` attribute.

## invalid-codeblock-attributes

The `invalid_codeblock_attributes` lint detects code block attributes in documentation examples that have potentially mis-typed values. This is a `rustdoc` only lint, see the documentation in the rustdoc book.

## invalid-value

The `invalid_value` lint detects creating a value that is not valid, such as a NULL reference.

### Example

    #![allow(unused)]
    fn main() {
    #![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: `#[warn(invalid_value)]` on by default
      = note: references must be non-null

### 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 detects irrefutable patterns in if-let and while-let statements.

### Example

    #![allow(unused)]
    fn main() {
    if let _ = 123 {
        println!("always runs!");
    }
    }

This will produce:

    warning: irrefutable if-let pattern
     --> lint_example.rs:2:1
      |
    2 | / if let _ = 123 {
    3 | |     println!("always runs!");
    4 | | }
      | |_^
      |
      = 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.

## 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<'a, 'b>(self, _: &'a u8, _: &'b 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<'a, 'b>(self, _: &'a u8, _: &'b u8) {}
      |             -- the late bound lifetime parameter is introduced here
    ...
    8 |     S.late::<'static>(&0, &0);
      |              ^^^^^^^
      |
      = note: `#[warn(late_bound_lifetime_arguments)]` 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 #42868 <https://github.com/rust-lang/rust/issues/42868>

### 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.

## mixed-script-confusables

The `mixed_script_confusables` lint detects visually confusable characters in identifiers between different scripts.

### Example

    #![allow(unused)]
    #![feature(non_ascii_idents)]

    fn main() {
    // 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:5:7
      |
    5 | const エ: &'static str = "アイウ";
      |       ^^
      |
      = note: `#[warn(mixed_script_confusables)]` on by default
      = note: The usage includes 'エ' (U+30A8).
      = note: Please recheck to make sure their usages are indeed what you want.

### Explanation

With the `non_ascii_idents` nightly-only feature enabled, identifiers are allowed to use non-ASCII characters. 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.

## mutable-borrow-reservation-conflict

The `mutable_borrow_reservation_conflict` lint detects the reservation of a two-phased borrow that conflicts with other shared borrows.

### Example

    #![allow(unused)]
    fn main() {
    let mut v = vec![0, 1, 2];
    let shared = &v;
    v.push(shared.len());
    }

This will produce:

    warning: cannot borrow `v` as mutable because it is also borrowed as immutable
     --> lint_example.rs:4:1
      |
    3 | let shared = &v;
      |              -- immutable borrow occurs here
    4 | v.push(shared.len());
      | ^      ------ immutable borrow later used here
      | |
      | mutable borrow occurs here
      |
      = note: `#[warn(mutable_borrow_reservation_conflict)]` on by default
      = warning: this borrowing pattern was not meant to be accepted, and may become a hard error in the future
      = note: for more information, see issue #59159 <https://github.com/rust-lang/rust/issues/59159>

### Explanation

This is a future-incompatible lint to transition this to a hard error in the future. See issue #59159 for a complete description of the problem, and some possible solutions.

## no-mangle-generic-items

The `no_mangle_generic_items` lint detects generic items that must be mangled.

### Example

    #![allow(unused)]
    fn main() {
    #[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

An 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-autolinks

The `non_autolinks` lint detects when a URL could be written using only angle brackets. This is a `rustdoc` only lint, see the documentation in the rustdoc book.

## 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

    #![allow(unused)]
    fn main() {
    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-fmt-panic

The `non_fmt_panic` lint detects `panic!(..)` invocations where the first argument is not a formatting string.

### Example

    #![allow(unused)]
    fn main() {
    panic!("{}");
    panic!(123);
    }

This will produce:

    warning: panic message contains an unused formatting placeholder
     --> lint_example.rs:2:9
      |
    2 | panic!("{}");
      |         ^^
      |
      = note: `#[warn(non_fmt_panic)]` on by default
      = note: this message is not used as a format string when given without arguments, but will be in Rust 2021
    help: add the missing argument
      |
    2 | panic!("{}", ...);
      |            ^^^^^
    help: or add a "{}" format string to use the message literally
      |
    2 | panic!("{}", "{}");
      |        ^^^^^

### 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-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

### 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

    #![allow(unused)]
    fn main() {
    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

    #![allow(unused)]
    fn main() {
    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`.

## nontrivial-structural-match

The `nontrivial_structural_match` lint detects constants that are used in patterns, whose type is not structural-match and whose initializer body actually uses values that are not structural-match. So `Option<NotStruturalMatch>` is ok if the constant is just `None`.

### Example

    #![deny(nontrivial_structural_match)]

    #[derive(Copy, Clone, Debug)]
    struct NoDerive(u32);
    impl PartialEq for NoDerive { fn eq(&self, _: &Self) -> bool { false } }
    impl Eq for NoDerive { }
    fn main() {
        const INDEX: Option<NoDerive> = [None, Some(NoDerive(10))][0];
        match None { Some(_) => panic!("whoops"), INDEX => dbg!(INDEX), };
    }

This will produce:

    error: to use a constant of type `NoDerive` in a pattern, the constant's initializer must be trivial or `NoDerive` must be annotated with `#[derive(PartialEq, Eq)]`
     --> lint_example.rs:9:47
      |
    9 |     match None { Some(_) => panic!("whoops"), INDEX => dbg!(INDEX), };
      |                                               ^^^^^
      |
    note: the lint level is defined here
     --> lint_example.rs:1:9
      |
    1 | #![deny(nontrivial_structural_match)]
      |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
      = 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 #73448 <https://github.com/rust-lang/rust/issues/73448>

### Explanation

Previous versions of Rust accepted constants in patterns, even if those constants's types did not have `PartialEq` derived. Thus the compiler falls back to runtime execution of `PartialEq`, which can report that two constants are not equal even if they are bit-equivalent.

## overlapping-range-endpoints

The `overlapping_range_endpoints` lint detects `match` arms that have range patterns that overlap on their endpoints.

### Example

    #![allow(unused)]
    fn main() {
    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: `#[warn(overlapping_range_endpoints)]` on by default
      = note: you likely meant to write mutually exclusive ranges

### 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

    #![allow(unused)]
    fn main() {
    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-in-public

The `private_in_public` lint detects private items in public interfaces not caught by the old implementation.

### Example

    #![allow(unused)]
    struct SemiPriv;

    mod m1 {
        struct Priv;
        impl super::SemiPriv {
            pub fn f(_: Priv) {}
        }
    }
    fn main() {}

This will produce:

    warning: private type `Priv` in public interface (error E0446)
     --> lint_example.rs:7:9
      |
    7 |         pub fn f(_: Priv) {}
      |         ^^^^^^^^^^^^^^^^^
      |
      = note: `#[warn(private_in_public)]` 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 #34537 <https://github.com/rust-lang/rust/issues/34537>

### Explanation

The visibility rules are intended to prevent exposing private items in public interfaces. This is a future-incompatible lint to transition this to a hard error in the future. See issue #34537 for more details.

## private-intra-doc-links

This is a subset of `broken_intra_doc_links` that warns when linking from a public item to a private one. This is a `rustdoc` only lint, see the documentation in the rustdoc book.

## 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.

## redundant-semicolons

The `redundant_semicolons` lint detects unnecessary trailing semicolons.

### Example

    #![allow(unused)]
    fn main() {
    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.

## renamed-and-removed-lints

The `renamed_and_removed_lints` lint detects lints that have been renamed or removed.

### Example

    #![allow(unused)]
    #![deny(raw_pointer_derive)]
    fn main() {
    }

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.

## safe-packed-borrows

The `safe_packed_borrows` lint detects borrowing a field in the interior of a packed structure with alignment other than 1.

### Example

    #[repr(packed)]
    pub struct Unaligned<T>(pub T);

    pub struct Foo {
        start: u8,
        data: Unaligned<u32>,
    }

    fn main() {
        let x = Foo { start: 0, data: Unaligned(1) };
        let y = &x.data.0;
    }

This will produce:

    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

### Explanation

This type of borrow is unsafe and can cause errors on some platforms and violates some assumptions made by the compiler. This was previously allowed unintentionally. This is a future-incompatible lint to transition this to a hard error in the future. See issue #46043 for more details, including guidance on how to solve the problem.

## 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.

## temporary-cstring-as-ptr

The `temporary_cstring_as_ptr` lint detects getting the inner pointer of a temporary `CString`.

### Example

    #![allow(unused)]
    fn main() {
    #![allow(unused)]
    use std::ffi::CString;
    let c_str = CString::new("foo").unwrap().as_ptr();
    }

This will produce:

    warning: getting the inner pointer of a temporary `CString`
     --> lint_example.rs:4:42
      |
    4 | let c_str = CString::new("foo").unwrap().as_ptr();
      |             ---------------------------- ^^^^^^ this pointer will be invalid
      |             |
      |             this `CString` is deallocated at the end of the statement, bind it to a variable to extend its lifetime
      |
      = note: `#[warn(temporary_cstring_as_ptr)]` on by default
      = note: pointers do not have a lifetime; when calling `as_ptr` the `CString` 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

### Explanation

The inner pointer of a `CString` lives only as long as the `CString` it points to. Getting the inner pointer of a temporary `CString` allows the `CString` to be dropped at the end of the statement, as it is not being referenced as far as the typesystem is concerned. This means outside of the statement the pointer will point to freed memory, which causes undefined behavior if the pointer is later dereferenced.

## trivial-bounds

The `trivial_bounds` lint detects trait bounds that don't depend on any type parameters.

### Example

    #![allow(unused)]
    #![feature(trivial_bounds)]
    fn main() {
    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

    #![allow(unused)]
    fn main() {
    type SendVec<T: Send> = Vec<T>;
    }

This will produce:

    warning: bounds on generic parameters are not enforced in type aliases
     --> lint_example.rs:2:17
      |
    2 | type SendVec<T: Send> = Vec<T>;
      |                 ^^^^
      |
      = note: `#[warn(type_alias_bounds)]` on by default
    help: the bound will not be checked when the type alias is used, and should be removed
      |
    2 | type SendVec<T> = Vec<T>;
      |              --

### Explanation

The trait bounds in a type alias are currently ignored, and should not be included to avoid confusion. This was previously allowed unintentionally; this may become a hard error in the future.

## tyvar-behind-raw-pointer

The `tyvar_behind_raw_pointer` lint detects raw pointer to an inference variable.

### Example

    #![allow(unused)]
    fn main() {
    // 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() {}
      |         ^^^^^^^
      |
      = note: `#[warn(tyvar_behind_raw_pointer)]` on by default
      = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in the 2018 edition!
      = note: for more information, see issue #46906 <https://github.com/rust-lang/rust/issues/46906>

### 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)]
    fn main() {
    #![allow(unused)]
    #![feature(non_ascii_idents)]
    const µ: f64 = 0.000001;
    }

This will produce:

    warning: identifier contains uncommon Unicode codepoints
     --> lint_example.rs:4:7
      |
    4 | const µ: f64 = 0.000001;
      |       ^
      |
      = note: `#[warn(uncommon_codepoints)]` on by default

### Explanation

With the `non_ascii_idents` nightly-only feature enabled, identifiers are allowed to use non-ASCII characters. 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

    #![allow(unused)]
    fn main() {
    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
      |
      = note: `#[warn(unconditional_recursion)]` on by default
      = help: a `loop` may express intention better if this is on purpose

### 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.

## uninhabited-static

The `uninhabited_static` lint detects uninhabited statics.

### Example

    #![allow(unused)]
    fn main() {
    enum Void {}
    extern {
        static EXTERN: Void;
    }
    }

This will produce:

    warning: static of uninhabited type
     --> lint_example.rs:4:5
      |
    4 |     static EXTERN: Void;
      |     ^^^^^^^^^^^^^^^^^^^^
      |
      = note: `#[warn(uninhabited_static)]` 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 #74840 <https://github.com/rust-lang/rust/issues/74840>
      = note: uninhabited statics cannot be initialized, and any access would be an immediate error

### 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 accientally allowed, but is being phased out.

## unknown-lints

The `unknown_lints` lint detects unrecognized lint attribute.

### Example

    #![allow(unused)]
    #![allow(not_a_real_lint)]
    fn main() {
    }

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.

## 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 an attribute macro (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

    #![allow(unused)]
    fn main() {
    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

    #![allow(unused)]
    fn main() {
    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 => (),
      |     ^ unreachable pattern
      |
      = 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-collisions

The `unstable_name_collisions` lint detects that you have used a name that the standard library plans to add in the future.

### Example

    #![allow(unused)]
    fn main() {
    trait MyIterator : Iterator {
        // is_sorted is an unstable method that already exists on the Iterator trait
        fn is_sorted(self) -> bool where Self: Sized {true}
    }

    impl<T: ?Sized> MyIterator for T where T: Iterator { }

    let x = vec![1, 2, 3];
    let _ = x.iter().is_sorted();
    }

This will produce:

    warning: a method with this name may be added to the standard library in the future
      --> lint_example.rs:10:18
       |
    10 | let _ = x.iter().is_sorted();
       |                  ^^^^^^^^^
       |
       = note: `#[warn(unstable_name_collisions)]` on by default
       = warning: once this method 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_sorted(...)` to keep using the current method
       = help: add `#![feature(is_sorted)]` to the crate attributes to enable `is_sorted`

### 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 pre-existing 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_sorted(my_iter)` or renaming or removing the method.

## unsupported-naked-functions

The `unsupported_naked_functions` lint detects naked function definitions that are unsupported but were previously accepted.

### Example

    #![allow(unused)]
    #![feature(naked_functions)]

    fn main() {
    #[naked]
    pub fn f() -> u32 {
        42
    }
    }

This will produce:

    warning: Rust ABI is unsupported in naked functions
     --> lint_example.rs:5:8
      |
    5 | pub fn f() -> u32 {
      |        ^
      |
      = note: `#[warn(unsupported_naked_functions)]` 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 #32408 <https://github.com/rust-lang/rust/issues/32408>

### Explanation

The naked functions must be defined using a single inline assembly block.

The execution must never fall through past the end of the assembly code so the block must use `noreturn` option. The asm block can also use `att_syntax` option, but other options are not allowed.

The asm block must not contain any operands other than `const` and `sym`. Additionally, naked function should specify a non-Rust ABI.

While other definitions of naked functions were previously accepted, they are unsupported and might not work reliably. This is a future-incompatible lint that will transition into hard error in the future.

## unused-allocation

The `unused_allocation` lint detects unnecessary allocations that can be eliminated.

### Example

    #![feature(box_syntax)]
    fn main() {
        let a = (box [1, 2, 3]).len();
    }

This will produce:

    warning: unnecessary allocation, use `&` instead
     --> lint_example.rs:3:13
      |
    3 |     let a = (box [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

    #![allow(unused)]
    fn main() {
    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;
      | ^
      |
      = note: `#[warn(unused_assignments)]` on by default
      = help: maybe it is overwritten before being read?

### 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-attributes

The `unused_attributes` lint detects attributes that were not used by the compiler.

### Example

    #![allow(unused)]
    #![ignore]
    fn main() {
    }

This will produce:

    warning: unused attribute
     --> 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(unsued)]`) which applies to the item following the attribute.

## unused-braces

The `unused_braces` lint detects unnecessary braces around an expression.

### Example

    #![allow(unused)]
    fn main() {
    if { true } {
        // ...
    }
    }

This will produce:

    warning: unnecessary braces around `if` condition
     --> lint_example.rs:2:4
      |
    2 | if { true } {
      |    ^^^^^^^^ help: remove these braces
      |
      = note: `#[warn(unused_braces)]` on by default

### 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

    #![allow(unused)]
    fn main() {
    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

    #![allow(unused)]
    fn main() {
    /// 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
      |
      = 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

    #![allow(unused)]
    fn main() {
    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

    #![allow(unused)]
    fn main() {
    '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.

### Example

    macro_rules! unused {
        () => {};
    }

    fn main() {
    }

This will produce:

    warning: unused macro definition
     --> lint_example.rs:1:1
      |
    1 | / macro_rules! unused {
    2 | |     () => {};
    3 | | }
      | |_^
      |
      = 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 `std::result::Result` that must be used
     --> lint_example.rs:6:5
      |
    6 |     returns_result();
      |     ^^^^^^^^^^^^^^^^^
      |
      = note: `#[warn(unused_must_use)]` on by default
      = note: this `Result` may be an `Err` variant, which should be handled

### 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

    #![allow(unused)]
    fn main() {
    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

    #![allow(unused)]
    fn main() {
    if(true) {}
    }

This will produce:

    warning: unnecessary parentheses around `if` condition
     --> lint_example.rs:2:3
      |
    2 | if(true) {}
      |   ^^^^^^ help: remove these parentheses
      |
      = note: `#[warn(unused_parens)]` on by default

### Explanation

The parenthesis 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

    #![allow(unused)]
    fn main() {
    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

    #![allow(unused)]
    fn main() {
    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`.

## warnings

The `warnings` lint allows you to change the level of other lints which produce warnings.

### Example

    #![allow(unused)]
    #![deny(warnings)]
    fn main() {
    fn foo() {}
    }

This will produce:

    error: function is never used: `foo`
     --> 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.

## where-clauses-object-safety

The `where_clauses_object_safety` lint detects for object safety of where clauses.

### Example

    trait Trait {}

    trait X { fn foo(&self) where Self: Trait; }

    impl X for () { fn foo(&self) {} }

    impl Trait for dyn X {}

    // Segfault at opt-level 0, SIGILL otherwise.
    pub fn main() { <dyn X as X>::foo(&()); }

This will produce:

    warning: the trait `X` cannot be made into an object
     --> lint_example.rs:3:14
      |
    3 | trait X { fn foo(&self) where Self: Trait; }
      |              ^^^
      |
      = note: `#[warn(where_clauses_object_safety)]` 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 #51443 <https://github.com/rust-lang/rust/issues/51443>
    note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety>
     --> lint_example.rs:3:14
      |
    3 | trait X { fn foo(&self) where Self: Trait; }
      |       -      ^^^ ...because method `foo` references the `Self` type in its `where` clause
      |       |
      |       this trait cannot be made into an object...
      = help: consider moving `foo` to another trait

### Explanation

The compiler previously allowed these object-unsafe bounds, which was incorrect. This is a future-incompatible lint to transition this to a hard error in the future. See issue #51443 for more details.

## while-true

The `while_true` lint detects `while true { }`.

### Example

    #![allow(unused)]
    fn main() {
    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.