1 //! Some lints that are built in to the compiler.
3 //! These are the built-in lints that are emitted direct in the main
4 //! compiler code, rather than using their own custom pass. Those
5 //! lints are all available in `rustc_lint::builtin`.
7 use crate::{declare_lint, declare_lint_pass, declare_tool_lint};
8 use rustc_span::edition::Edition;
9 use rustc_span::symbol::sym;
12 /// The `ill_formed_attribute_input` lint detects ill-formed attribute
13 /// inputs that were previously accepted and used in practice.
17 /// ```rust,compile_fail
18 /// #[inline = "this is not valid"]
26 /// Previously, inputs for many built-in attributes weren't validated and
27 /// nonsensical attribute inputs were accepted. After validation was
28 /// added, it was determined that some existing projects made use of these
29 /// invalid forms. This is a [future-incompatible] lint to transition this
30 /// to a hard error in the future. See [issue #57571] for more details.
32 /// Check the [attribute reference] for details on the valid inputs for
35 /// [issue #57571]: https://github.com/rust-lang/rust/issues/57571
36 /// [attribute reference]: https://doc.rust-lang.org/nightly/reference/attributes.html
37 /// [future-incompatible]: ../index.md#future-incompatible-lints
38 pub ILL_FORMED_ATTRIBUTE_INPUT,
40 "ill-formed attribute inputs that were previously accepted and used in practice",
41 @future_incompatible = FutureIncompatibleInfo {
42 reference: "issue #57571 <https://github.com/rust-lang/rust/issues/57571>",
49 /// The `conflicting_repr_hints` lint detects [`repr` attributes] with
50 /// conflicting hints.
52 /// [`repr` attributes]: https://doc.rust-lang.org/reference/type-layout.html#representations
56 /// ```rust,compile_fail
67 /// The compiler incorrectly accepted these conflicting representations in
68 /// the past. This is a [future-incompatible] lint to transition this to a
69 /// hard error in the future. See [issue #68585] for more details.
71 /// To correct the issue, remove one of the conflicting hints.
73 /// [issue #68585]: https://github.com/rust-lang/rust/issues/68585
74 /// [future-incompatible]: ../index.md#future-incompatible-lints
75 pub CONFLICTING_REPR_HINTS,
77 "conflicts between `#[repr(..)]` hints that were previously accepted and used in practice",
78 @future_incompatible = FutureIncompatibleInfo {
79 reference: "issue #68585 <https://github.com/rust-lang/rust/issues/68585>",
85 /// The `meta_variable_misuse` lint detects possible meta-variable misuse
86 /// in macro definitions.
90 /// ```rust,compile_fail
91 /// #![deny(meta_variable_misuse)]
93 /// macro_rules! foo {
95 /// ($( $i:ident = $($j:ident),+ );*) => { $( $( $i = $k; )+ )* };
107 /// There are quite a few different ways a [`macro_rules`] macro can be
108 /// improperly defined. Many of these errors were previously only detected
109 /// when the macro was expanded or not at all. This lint is an attempt to
110 /// catch some of these problems when the macro is *defined*.
112 /// This lint is "allow" by default because it may have false positives
113 /// and other issues. See [issue #61053] for more details.
115 /// [`macro_rules`]: https://doc.rust-lang.org/reference/macros-by-example.html
116 /// [issue #61053]: https://github.com/rust-lang/rust/issues/61053
117 pub META_VARIABLE_MISUSE,
119 "possible meta-variable misuse at macro definition"
123 /// The `incomplete_include` lint detects the use of the [`include!`]
124 /// macro with a file that contains more than one expression.
126 /// [`include!`]: https://doc.rust-lang.org/std/macro.include.html
130 /// ```rust,ignore (needs separate file)
132 /// include!("foo.txt");
136 /// where the file `foo.txt` contains:
145 /// error: include macro expected single expression in source
148 /// 1 | println!("1");
151 /// = note: `#[deny(incomplete_include)]` on by default
156 /// The [`include!`] macro is currently only intended to be used to
157 /// include a single [expression] or multiple [items]. Historically it
158 /// would ignore any contents after the first expression, but that can be
159 /// confusing. In the example above, the `println!` expression ends just
160 /// before the semicolon, making the semicolon "extra" information that is
161 /// ignored. Perhaps even more surprising, if the included file had
162 /// multiple print statements, the subsequent ones would be ignored!
164 /// One workaround is to place the contents in braces to create a [block
165 /// expression]. Also consider alternatives, like using functions to
166 /// encapsulate the expressions, or use [proc-macros].
168 /// This is a lint instead of a hard error because existing projects were
169 /// found to hit this error. To be cautious, it is a lint for now. The
170 /// future semantics of the `include!` macro are also uncertain, see
173 /// [items]: https://doc.rust-lang.org/reference/items.html
174 /// [expression]: https://doc.rust-lang.org/reference/expressions.html
175 /// [block expression]: https://doc.rust-lang.org/reference/expressions/block-expr.html
176 /// [proc-macros]: https://doc.rust-lang.org/reference/procedural-macros.html
177 /// [issue #35560]: https://github.com/rust-lang/rust/issues/35560
178 pub INCOMPLETE_INCLUDE,
180 "trailing content in included file"
184 /// The `arithmetic_overflow` lint detects that an arithmetic operation
187 /// [overflow]: https://doc.rust-lang.org/reference/expressions/operator-expr.html#overflow
191 /// ```rust,compile_fail
199 /// It is very likely a mistake to perform an arithmetic operation that
200 /// overflows its value. If the compiler is able to detect these kinds of
201 /// overflows at compile-time, it will trigger this lint. Consider
202 /// adjusting the expression to avoid overflow, or use a data type that
203 /// will not overflow.
204 pub ARITHMETIC_OVERFLOW,
206 "arithmetic operation overflows"
210 /// The `unconditional_panic` lint detects an operation that will cause a
211 /// panic at runtime.
215 /// ```rust,compile_fail
216 /// # #![allow(unused)]
224 /// This lint detects code that is very likely incorrect because it will
225 /// always panic, such as division by zero and out-of-bounds array
226 /// accesses. Consider adjusting your code if this is a bug, or using the
227 /// `panic!` or `unreachable!` macro instead in case the panic is intended.
228 pub UNCONDITIONAL_PANIC,
230 "operation will cause a panic at runtime"
234 /// The `const_err` lint detects an erroneous expression while doing
235 /// constant evaluation.
239 /// ```rust,compile_fail
240 /// #![allow(unconditional_panic)]
241 /// let x: &'static i32 = &(1 / 0);
248 /// This lint detects code that is very likely incorrect. If this lint is
249 /// allowed, then the code will not be evaluated at compile-time, and
250 /// instead continue to generate code to evaluate at runtime, which may
251 /// panic during runtime.
253 /// Note that this lint may trigger in either inside or outside of a
254 /// [const context]. Outside of a [const context], the compiler can
255 /// sometimes evaluate an expression at compile-time in order to generate
256 /// more efficient code. As the compiler becomes better at doing this, it
257 /// needs to decide what to do when it encounters code that it knows for
258 /// certain will panic or is otherwise incorrect. Making this a hard error
259 /// would prevent existing code that exhibited this behavior from
260 /// compiling, breaking backwards-compatibility. However, this is almost
261 /// certainly incorrect code, so this is a deny-by-default lint. For more
262 /// details, see [RFC 1229] and [issue #28238].
264 /// Note that there are several other more specific lints associated with
265 /// compile-time evaluation, such as [`arithmetic_overflow`],
266 /// [`unconditional_panic`].
268 /// [const context]: https://doc.rust-lang.org/reference/const_eval.html#const-context
269 /// [RFC 1229]: https://github.com/rust-lang/rfcs/blob/master/text/1229-compile-time-asserts.md
270 /// [issue #28238]: https://github.com/rust-lang/rust/issues/28238
271 /// [`arithmetic_overflow`]: deny-by-default.html#arithmetic-overflow
272 /// [`unconditional_panic`]: deny-by-default.html#unconditional-panic
275 "constant evaluation detected erroneous expression",
276 report_in_external_macro
280 /// The `unused_imports` lint detects imports that are never used.
285 /// use std::collections::HashMap;
292 /// Unused imports may signal a mistake or unfinished code, and clutter
293 /// the code, and should be removed. If you intended to re-export the item
294 /// to make it available outside of the module, add a visibility modifier
298 "imports that are never used"
302 /// The `unused_extern_crates` lint guards against `extern crate` items
303 /// that are never used.
307 /// ```rust,compile_fail
308 /// #![deny(unused_extern_crates)]
309 /// extern crate proc_macro;
316 /// `extern crate` items that are unused have no effect and should be
317 /// removed. Note that there are some cases where specifying an `extern
318 /// crate` is desired for the side effect of ensuring the given crate is
319 /// linked, even though it is not otherwise directly referenced. The lint
320 /// can be silenced by aliasing the crate to an underscore, such as
321 /// `extern crate foo as _`. Also note that it is no longer idiomatic to
322 /// use `extern crate` in the [2018 edition], as extern crates are now
323 /// automatically added in scope.
325 /// This lint is "allow" by default because it can be noisy, and produce
326 /// false-positives. If a dependency is being removed from a project, it
327 /// is recommended to remove it from the build configuration (such as
328 /// `Cargo.toml`) to ensure stale build entries aren't left behind.
330 /// [2018 edition]: https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html#no-more-extern-crate
331 pub UNUSED_EXTERN_CRATES,
333 "extern crates that are never used"
337 /// The `unused_crate_dependencies` lint detects crate dependencies that
342 /// ```rust,ignore (needs extern crate)
343 /// #![deny(unused_crate_dependencies)]
346 /// This will produce:
349 /// error: external crate `regex` unused in `lint_example`: remove the dependency or add `use regex as _;`
351 /// note: the lint level is defined here
352 /// --> src/lib.rs:1:9
354 /// 1 | #![deny(unused_crate_dependencies)]
355 /// | ^^^^^^^^^^^^^^^^^^^^^^^^^
360 /// After removing the code that uses a dependency, this usually also
361 /// requires removing the dependency from the build configuration.
362 /// However, sometimes that step can be missed, which leads to time wasted
363 /// building dependencies that are no longer used. This lint can be
364 /// enabled to detect dependencies that are never used (more specifically,
365 /// any dependency passed with the `--extern` command-line flag that is
366 /// never referenced via [`use`], [`extern crate`], or in any [path]).
368 /// This lint is "allow" by default because it can provide false positives
369 /// depending on how the build system is configured. For example, when
370 /// using Cargo, a "package" consists of multiple crates (such as a
371 /// library and a binary), but the dependencies are defined for the
372 /// package as a whole. If there is a dependency that is only used in the
373 /// binary, but not the library, then the lint will be incorrectly issued
376 /// [path]: https://doc.rust-lang.org/reference/paths.html
377 /// [`use`]: https://doc.rust-lang.org/reference/items/use-declarations.html
378 /// [`extern crate`]: https://doc.rust-lang.org/reference/items/extern-crates.html
379 pub UNUSED_CRATE_DEPENDENCIES,
381 "crate dependencies that are never used",
386 /// The `unused_qualifications` lint detects unnecessarily qualified
391 /// ```rust,compile_fail
392 /// #![deny(unused_qualifications)]
407 /// If an item from another module is already brought into scope, then
408 /// there is no need to qualify it in this case. You can call `bar()`
409 /// directly, without the `foo::`.
411 /// This lint is "allow" by default because it is somewhat pedantic, and
412 /// doesn't indicate an actual problem, but rather a stylistic choice, and
413 /// can be noisy when refactoring or moving around code.
414 pub UNUSED_QUALIFICATIONS,
416 "detects unnecessarily qualified names"
420 /// The `unknown_lints` lint detects unrecognized lint attribute.
425 /// #![allow(not_a_real_lint)]
432 /// It is usually a mistake to specify a lint that does not exist. Check
433 /// the spelling, and check the lint listing for the correct name. Also
434 /// consider if you are using an old version of the compiler, and the lint
435 /// is only available in a newer version.
438 "unrecognized lint attribute"
442 /// The `unused_variables` lint detects variables which are not used in
455 /// Unused variables may signal a mistake or unfinished code. To silence
456 /// the warning for the individual variable, prefix it with an underscore
458 pub UNUSED_VARIABLES,
460 "detect variables which are not used in any way"
464 /// The `unused_assignments` lint detects assignments that will never be read.
477 /// Unused assignments may signal a mistake or unfinished code. If the
478 /// variable is never used after being assigned, then the assignment can
479 /// be removed. Variables with an underscore prefix such as `_x` will not
480 /// trigger this lint.
481 pub UNUSED_ASSIGNMENTS,
483 "detect assignments that will never be read"
487 /// The `dead_code` lint detects unused, unexported items.
499 /// Dead code may signal a mistake or unfinished code. To silence the
500 /// warning for individual items, prefix the name with an underscore such
501 /// as `_foo`. If it was intended to expose the item outside of the crate,
502 /// consider adding a visibility modifier like `pub`. Otherwise consider
503 /// removing the unused code.
506 "detect unused, unexported items"
510 /// The `unused_attributes` lint detects attributes that were not used by
523 /// Unused [attributes] may indicate the attribute is placed in the wrong
524 /// position. Consider removing it, or placing it in the correct position.
525 /// Also consider if you intended to use an _inner attribute_ (with a `!`
526 /// such as `#![allow(unused)]`) which applies to the item the attribute
527 /// is within, or an _outer attribute_ (without a `!` such as
528 /// `#[allow(unsued)]`) which applies to the item *following* the
531 /// [attributes]: https://doc.rust-lang.org/reference/attributes.html
532 pub UNUSED_ATTRIBUTES,
534 "detects attributes that were not used by the compiler"
538 /// The `unreachable_code` lint detects unreachable code paths.
543 /// panic!("we never go past here!");
552 /// Unreachable code may signal a mistake or unfinished code. If the code
553 /// is no longer in use, consider removing it.
554 pub UNREACHABLE_CODE,
556 "detects unreachable code paths",
557 report_in_external_macro
561 /// The `unreachable_patterns` lint detects unreachable patterns.
577 /// This usually indicates a mistake in how the patterns are specified or
578 /// ordered. In this example, the `y` pattern will always match, so the
579 /// five is impossible to reach. Remember, match arms match in order, you
580 /// probably wanted to put the `5` case above the `y` case.
581 pub UNREACHABLE_PATTERNS,
583 "detects unreachable patterns"
587 /// The `overlapping_range_endpoints` lint detects `match` arms that have [range patterns] that
588 /// overlap on their endpoints.
590 /// [range patterns]: https://doc.rust-lang.org/nightly/reference/patterns.html#range-patterns
597 /// 0..=100 => { println!("small"); }
598 /// 100..=255 => { println!("large"); }
606 /// It is likely a mistake to have range patterns in a match expression that overlap in this
607 /// way. Check that the beginning and end values are what you expect, and keep in mind that
608 /// with `..=` the left and right bounds are inclusive.
609 pub OVERLAPPING_RANGE_ENDPOINTS,
611 "detects range patterns with overlapping endpoints"
615 /// The `bindings_with_variant_name` lint detects pattern bindings with
616 /// the same name as one of the matched variants.
626 /// pub fn foo(x: Enum) {
638 /// It is usually a mistake to specify an enum variant name as an
639 /// [identifier pattern]. In the example above, the `match` arms are
640 /// specifying a variable name to bind the value of `x` to. The second arm
641 /// is ignored because the first one matches *all* values. The likely
642 /// intent is that the arm was intended to match on the enum variant.
644 /// Two possible solutions are:
646 /// * Specify the enum variant using a [path pattern], such as
648 /// * Bring the enum variants into local scope, such as adding `use
649 /// Enum::*;` to the beginning of the `foo` function in the example
652 /// [identifier pattern]: https://doc.rust-lang.org/reference/patterns.html#identifier-patterns
653 /// [path pattern]: https://doc.rust-lang.org/reference/patterns.html#path-patterns
654 pub BINDINGS_WITH_VARIANT_NAME,
656 "detects pattern bindings with the same name as one of the matched variants"
660 /// The `unused_macros` lint detects macros that were not used.
665 /// macro_rules! unused {
677 /// Unused macros may signal a mistake or unfinished code. To silence the
678 /// warning for the individual macro, prefix the name with an underscore
679 /// such as `_my_macro`. If you intended to export the macro to make it
680 /// available outside of the crate, use the [`macro_export` attribute].
682 /// [`macro_export` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
685 "detects macros that were not used"
689 /// The `warnings` lint allows you to change the level of other
690 /// lints which produce warnings.
695 /// #![deny(warnings)]
703 /// The `warnings` lint is a bit special; by changing its level, you
704 /// change every other warning that would produce a warning to whatever
705 /// value you'd like. As such, you won't ever trigger this lint in your
709 "mass-change the level for lints which produce warnings"
713 /// The `unused_features` lint detects unused or unknown features found in
714 /// crate-level [`feature` attributes].
716 /// [`feature` attributes]: https://doc.rust-lang.org/nightly/unstable-book/
718 /// Note: This lint is currently not functional, see [issue #44232] for
721 /// [issue #44232]: https://github.com/rust-lang/rust/issues/44232
724 "unused features found in crate-level `#[feature]` directives"
728 /// The `stable_features` lint detects a [`feature` attribute] that
729 /// has since been made stable.
731 /// [`feature` attribute]: https://doc.rust-lang.org/nightly/unstable-book/
736 /// #![feature(test_accepted_feature)]
744 /// When a feature is stabilized, it is no longer necessary to include a
745 /// `#![feature]` attribute for it. To fix, simply remove the
746 /// `#![feature]` attribute.
749 "stable features found in `#[feature]` directive"
753 /// The `unknown_crate_types` lint detects an unknown crate type found in
754 /// a [`crate_type` attribute].
758 /// ```rust,compile_fail
759 /// #![crate_type="lol"]
767 /// An unknown value give to the `crate_type` attribute is almost
768 /// certainly a mistake.
770 /// [`crate_type` attribute]: https://doc.rust-lang.org/reference/linkage.html
771 pub UNKNOWN_CRATE_TYPES,
773 "unknown crate type found in `#[crate_type]` directive",
778 /// The `trivial_casts` lint detects trivial casts which could be replaced
779 /// with coercion, which may require [type ascription] or a temporary
784 /// ```rust,compile_fail
785 /// #![deny(trivial_casts)]
786 /// let x: &u32 = &42;
787 /// let y = x as *const u32;
794 /// A trivial cast is a cast `e as T` where `e` has type `U` and `U` is a
795 /// subtype of `T`. This type of cast is usually unnecessary, as it can be
796 /// usually be inferred.
798 /// This lint is "allow" by default because there are situations, such as
799 /// with FFI interfaces or complex type aliases, where it triggers
800 /// incorrectly, or in situations where it will be more difficult to
801 /// clearly express the intent. It may be possible that this will become a
802 /// warning in the future, possibly with [type ascription] providing a
803 /// convenient way to work around the current issues. See [RFC 401] for
804 /// historical context.
806 /// [type ascription]: https://github.com/rust-lang/rust/issues/23416
807 /// [RFC 401]: https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md
810 "detects trivial casts which could be removed"
814 /// The `trivial_numeric_casts` lint detects trivial numeric casts of types
815 /// which could be removed.
819 /// ```rust,compile_fail
820 /// #![deny(trivial_numeric_casts)]
821 /// let x = 42_i32 as i32;
828 /// A trivial numeric cast is a cast of a numeric type to the same numeric
829 /// type. This type of cast is usually unnecessary.
831 /// This lint is "allow" by default because there are situations, such as
832 /// with FFI interfaces or complex type aliases, where it triggers
833 /// incorrectly, or in situations where it will be more difficult to
834 /// clearly express the intent. It may be possible that this will become a
835 /// warning in the future, possibly with [type ascription] providing a
836 /// convenient way to work around the current issues. See [RFC 401] for
837 /// historical context.
839 /// [type ascription]: https://github.com/rust-lang/rust/issues/23416
840 /// [RFC 401]: https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md
841 pub TRIVIAL_NUMERIC_CASTS,
843 "detects trivial casts of numeric types which could be removed"
847 /// The `private_in_public` lint detects private items in public
848 /// interfaces not caught by the old implementation.
853 /// # #![allow(unused)]
858 /// impl super::SemiPriv {
859 /// pub fn f(_: Priv) {}
869 /// The visibility rules are intended to prevent exposing private items in
870 /// public interfaces. This is a [future-incompatible] lint to transition
871 /// this to a hard error in the future. See [issue #34537] for more
874 /// [issue #34537]: https://github.com/rust-lang/rust/issues/34537
875 /// [future-incompatible]: ../index.md#future-incompatible-lints
876 pub PRIVATE_IN_PUBLIC,
878 "detect private items in public interfaces not caught by the old implementation",
879 @future_incompatible = FutureIncompatibleInfo {
880 reference: "issue #34537 <https://github.com/rust-lang/rust/issues/34537>",
886 /// The `exported_private_dependencies` lint detects private dependencies
887 /// that are exposed in a public interface.
891 /// ```rust,ignore (needs-dependency)
892 /// pub fn foo() -> Option<some_private_dependency::Thing> {
897 /// This will produce:
900 /// warning: type `bar::Thing` from private dependency 'bar' in public interface
901 /// --> src/lib.rs:3:1
903 /// 3 | pub fn foo() -> Option<bar::Thing> {
904 /// | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
906 /// = note: `#[warn(exported_private_dependencies)]` on by default
911 /// Dependencies can be marked as "private" to indicate that they are not
912 /// exposed in the public interface of a crate. This can be used by Cargo
913 /// to independently resolve those dependencies because it can assume it
914 /// does not need to unify them with other packages using that same
915 /// dependency. This lint is an indication of a violation of that
918 /// To fix this, avoid exposing the dependency in your public interface.
919 /// Or, switch the dependency to a public dependency.
921 /// Note that support for this is only available on the nightly channel.
922 /// See [RFC 1977] for more details, as well as the [Cargo documentation].
924 /// [RFC 1977]: https://github.com/rust-lang/rfcs/blob/master/text/1977-public-private-dependencies.md
925 /// [Cargo documentation]: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#public-dependency
926 pub EXPORTED_PRIVATE_DEPENDENCIES,
928 "public interface leaks type from a private dependency"
932 /// The `pub_use_of_private_extern_crate` lint detects a specific
933 /// situation of re-exporting a private `extern crate`.
937 /// ```rust,compile_fail
938 /// extern crate core;
939 /// pub use core as reexported_core;
946 /// A public `use` declaration should not be used to publicly re-export a
947 /// private `extern crate`. `pub extern crate` should be used instead.
949 /// This was historically allowed, but is not the intended behavior
950 /// according to the visibility rules. This is a [future-incompatible]
951 /// lint to transition this to a hard error in the future. See [issue
952 /// #34537] for more details.
954 /// [issue #34537]: https://github.com/rust-lang/rust/issues/34537
955 /// [future-incompatible]: ../index.md#future-incompatible-lints
956 pub PUB_USE_OF_PRIVATE_EXTERN_CRATE,
958 "detect public re-exports of private extern crates",
959 @future_incompatible = FutureIncompatibleInfo {
960 reference: "issue #34537 <https://github.com/rust-lang/rust/issues/34537>",
966 /// The `invalid_type_param_default` lint detects type parameter defaults
967 /// erroneously allowed in an invalid location.
971 /// ```rust,compile_fail
972 /// fn foo<T=i32>(t: T) {}
979 /// Default type parameters were only intended to be allowed in certain
980 /// situations, but historically the compiler allowed them everywhere.
981 /// This is a [future-incompatible] lint to transition this to a hard
982 /// error in the future. See [issue #36887] for more details.
984 /// [issue #36887]: https://github.com/rust-lang/rust/issues/36887
985 /// [future-incompatible]: ../index.md#future-incompatible-lints
986 pub INVALID_TYPE_PARAM_DEFAULT,
988 "type parameter default erroneously allowed in invalid location",
989 @future_incompatible = FutureIncompatibleInfo {
990 reference: "issue #36887 <https://github.com/rust-lang/rust/issues/36887>",
996 /// The `renamed_and_removed_lints` lint detects lints that have been
997 /// renamed or removed.
1002 /// #![deny(raw_pointer_derive)]
1009 /// To fix this, either remove the lint or use the new name. This can help
1010 /// avoid confusion about lints that are no longer valid, and help
1011 /// maintain consistency for renamed lints.
1012 pub RENAMED_AND_REMOVED_LINTS,
1014 "lints that have been renamed or removed"
1018 /// The `unaligned_references` lint detects unaligned references to fields
1019 /// of [packed] structs.
1021 /// [packed]: https://doc.rust-lang.org/reference/type-layout.html#the-alignment-modifiers
1025 /// ```rust,compile_fail
1026 /// #![deny(unaligned_references)]
1029 /// pub struct Foo {
1036 /// let foo = Foo { field1: 0, field2: 0 };
1037 /// let _ = &foo.field1;
1046 /// Creating a reference to an insufficiently aligned packed field is
1047 /// [undefined behavior] and should be disallowed.
1049 /// This lint is "allow" by default because there is no stable
1050 /// alternative, and it is not yet certain how widespread existing code
1051 /// will trigger this lint.
1053 /// See [issue #27060] for more discussion.
1055 /// [undefined behavior]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html
1056 /// [issue #27060]: https://github.com/rust-lang/rust/issues/27060
1057 pub UNALIGNED_REFERENCES,
1059 "detects unaligned references to fields of packed structs",
1063 /// The `const_item_mutation` lint detects attempts to mutate a `const`
1069 /// const FOO: [i32; 1] = [0];
1073 /// // This will print "[0]".
1074 /// println!("{:?}", FOO);
1082 /// Trying to directly mutate a `const` item is almost always a mistake.
1083 /// What is happening in the example above is that a temporary copy of the
1084 /// `const` is mutated, but the original `const` is not. Each time you
1085 /// refer to the `const` by name (such as `FOO` in the example above), a
1086 /// separate copy of the value is inlined at that location.
1088 /// This lint checks for writing directly to a field (`FOO.field =
1089 /// some_value`) or array entry (`FOO[0] = val`), or taking a mutable
1090 /// reference to the const item (`&mut FOO`), including through an
1091 /// autoderef (`FOO.some_mut_self_method()`).
1093 /// There are various alternatives depending on what you are trying to
1096 /// * First, always reconsider using mutable globals, as they can be
1097 /// difficult to use correctly, and can make the code more difficult to
1098 /// use or understand.
1099 /// * If you are trying to perform a one-time initialization of a global:
1100 /// * If the value can be computed at compile-time, consider using
1101 /// const-compatible values (see [Constant Evaluation]).
1102 /// * For more complex single-initialization cases, consider using a
1103 /// third-party crate, such as [`lazy_static`] or [`once_cell`].
1104 /// * If you are using the [nightly channel], consider the new
1105 /// [`lazy`] module in the standard library.
1106 /// * If you truly need a mutable global, consider using a [`static`],
1107 /// which has a variety of options:
1108 /// * Simple data types can be directly defined and mutated with an
1109 /// [`atomic`] type.
1110 /// * More complex types can be placed in a synchronization primitive
1111 /// like a [`Mutex`], which can be initialized with one of the options
1113 /// * A [mutable `static`] is a low-level primitive, requiring unsafe.
1114 /// Typically This should be avoided in preference of something
1115 /// higher-level like one of the above.
1117 /// [Constant Evaluation]: https://doc.rust-lang.org/reference/const_eval.html
1118 /// [`static`]: https://doc.rust-lang.org/reference/items/static-items.html
1119 /// [mutable `static`]: https://doc.rust-lang.org/reference/items/static-items.html#mutable-statics
1120 /// [`lazy`]: https://doc.rust-lang.org/nightly/std/lazy/index.html
1121 /// [`lazy_static`]: https://crates.io/crates/lazy_static
1122 /// [`once_cell`]: https://crates.io/crates/once_cell
1123 /// [`atomic`]: https://doc.rust-lang.org/std/sync/atomic/index.html
1124 /// [`Mutex`]: https://doc.rust-lang.org/std/sync/struct.Mutex.html
1125 pub CONST_ITEM_MUTATION,
1127 "detects attempts to mutate a `const` item",
1131 /// The `safe_packed_borrows` lint detects borrowing a field in the
1132 /// interior of a packed structure with alignment other than 1.
1138 /// pub struct Unaligned<T>(pub T);
1140 /// pub struct Foo {
1142 /// data: Unaligned<u32>,
1146 /// let x = Foo { start: 0, data: Unaligned(1) };
1147 /// let y = &x.data.0;
1155 /// This type of borrow is unsafe and can cause errors on some platforms
1156 /// and violates some assumptions made by the compiler. This was
1157 /// previously allowed unintentionally. This is a [future-incompatible]
1158 /// lint to transition this to a hard error in the future. See [issue
1159 /// #46043] for more details, including guidance on how to solve the
1162 /// [issue #46043]: https://github.com/rust-lang/rust/issues/46043
1163 /// [future-incompatible]: ../index.md#future-incompatible-lints
1164 pub SAFE_PACKED_BORROWS,
1166 "safe borrows of fields of packed structs were erroneously allowed",
1167 @future_incompatible = FutureIncompatibleInfo {
1168 reference: "issue #46043 <https://github.com/rust-lang/rust/issues/46043>",
1174 /// The `patterns_in_fns_without_body` lint detects `mut` identifier
1175 /// patterns as a parameter in functions without a body.
1179 /// ```rust,compile_fail
1181 /// fn foo(mut arg: u8);
1189 /// To fix this, remove `mut` from the parameter in the trait definition;
1190 /// it can be used in the implementation. That is, the following is OK:
1194 /// fn foo(arg: u8); // Removed `mut` here
1197 /// impl Trait for i32 {
1198 /// fn foo(mut arg: u8) { // `mut` here is OK
1204 /// Trait definitions can define functions without a body to specify a
1205 /// function that implementors must define. The parameter names in the
1206 /// body-less functions are only allowed to be `_` or an [identifier] for
1207 /// documentation purposes (only the type is relevant). Previous versions
1208 /// of the compiler erroneously allowed [identifier patterns] with the
1209 /// `mut` keyword, but this was not intended to be allowed. This is a
1210 /// [future-incompatible] lint to transition this to a hard error in the
1211 /// future. See [issue #35203] for more details.
1213 /// [identifier]: https://doc.rust-lang.org/reference/identifiers.html
1214 /// [identifier patterns]: https://doc.rust-lang.org/reference/patterns.html#identifier-patterns
1215 /// [issue #35203]: https://github.com/rust-lang/rust/issues/35203
1216 /// [future-incompatible]: ../index.md#future-incompatible-lints
1217 pub PATTERNS_IN_FNS_WITHOUT_BODY,
1219 "patterns in functions without body were erroneously allowed",
1220 @future_incompatible = FutureIncompatibleInfo {
1221 reference: "issue #35203 <https://github.com/rust-lang/rust/issues/35203>",
1227 /// The `missing_fragment_specifier` lint is issued when an unused pattern in a
1228 /// `macro_rules!` macro definition has a meta-variable (e.g. `$e`) that is not
1229 /// followed by a fragment specifier (e.g. `:expr`).
1231 /// This warning can always be fixed by removing the unused pattern in the
1232 /// `macro_rules!` macro definition.
1236 /// ```rust,compile_fail
1237 /// macro_rules! foo {
1251 /// To fix this, remove the unused pattern from the `macro_rules!` macro definition:
1254 /// macro_rules! foo {
1261 pub MISSING_FRAGMENT_SPECIFIER,
1263 "detects missing fragment specifiers in unused `macro_rules!` patterns",
1264 @future_incompatible = FutureIncompatibleInfo {
1265 reference: "issue #40107 <https://github.com/rust-lang/rust/issues/40107>",
1271 /// The `late_bound_lifetime_arguments` lint detects generic lifetime
1272 /// arguments in path segments with late bound lifetime parameters.
1280 /// fn late<'a, 'b>(self, _: &'a u8, _: &'b u8) {}
1284 /// S.late::<'static>(&0, &0);
1292 /// It is not clear how to provide arguments for early-bound lifetime
1293 /// parameters if they are intermixed with late-bound parameters in the
1294 /// same list. For now, providing any explicit arguments will trigger this
1295 /// lint if late-bound parameters are present, so in the future a solution
1296 /// can be adopted without hitting backward compatibility issues. This is
1297 /// a [future-incompatible] lint to transition this to a hard error in the
1298 /// future. See [issue #42868] for more details, along with a description
1299 /// of the difference between early and late-bound parameters.
1301 /// [issue #42868]: https://github.com/rust-lang/rust/issues/42868
1302 /// [future-incompatible]: ../index.md#future-incompatible-lints
1303 pub LATE_BOUND_LIFETIME_ARGUMENTS,
1305 "detects generic lifetime arguments in path segments with late bound lifetime parameters",
1306 @future_incompatible = FutureIncompatibleInfo {
1307 reference: "issue #42868 <https://github.com/rust-lang/rust/issues/42868>",
1313 /// The `order_dependent_trait_objects` lint detects a trait coherency
1314 /// violation that would allow creating two trait impls for the same
1315 /// dynamic trait object involving marker traits.
1319 /// ```rust,compile_fail
1320 /// pub trait Trait {}
1322 /// impl Trait for dyn Send + Sync { }
1323 /// impl Trait for dyn Sync + Send { }
1330 /// A previous bug caused the compiler to interpret traits with different
1331 /// orders (such as `Send + Sync` and `Sync + Send`) as distinct types
1332 /// when they were intended to be treated the same. This allowed code to
1333 /// define separate trait implementations when there should be a coherence
1334 /// error. This is a [future-incompatible] lint to transition this to a
1335 /// hard error in the future. See [issue #56484] for more details.
1337 /// [issue #56484]: https://github.com/rust-lang/rust/issues/56484
1338 /// [future-incompatible]: ../index.md#future-incompatible-lints
1339 pub ORDER_DEPENDENT_TRAIT_OBJECTS,
1341 "trait-object types were treated as different depending on marker-trait order",
1342 @future_incompatible = FutureIncompatibleInfo {
1343 reference: "issue #56484 <https://github.com/rust-lang/rust/issues/56484>",
1349 /// The `coherence_leak_check` lint detects conflicting implementations of
1350 /// a trait that are only distinguished by the old leak-check code.
1355 /// trait SomeTrait { }
1356 /// impl SomeTrait for for<'a> fn(&'a u8) { }
1357 /// impl<'a> SomeTrait for fn(&'a u8) { }
1364 /// In the past, the compiler would accept trait implementations for
1365 /// identical functions that differed only in where the lifetime binder
1366 /// appeared. Due to a change in the borrow checker implementation to fix
1367 /// several bugs, this is no longer allowed. However, since this affects
1368 /// existing code, this is a [future-incompatible] lint to transition this
1369 /// to a hard error in the future.
1371 /// Code relying on this pattern should introduce "[newtypes]",
1372 /// like `struct Foo(for<'a> fn(&'a u8))`.
1374 /// See [issue #56105] for more details.
1376 /// [issue #56105]: https://github.com/rust-lang/rust/issues/56105
1377 /// [newtypes]: https://doc.rust-lang.org/book/ch19-04-advanced-types.html#using-the-newtype-pattern-for-type-safety-and-abstraction
1378 /// [future-incompatible]: ../index.md#future-incompatible-lints
1379 pub COHERENCE_LEAK_CHECK,
1381 "distinct impls distinguished only by the leak-check code",
1382 @future_incompatible = FutureIncompatibleInfo {
1383 reference: "issue #56105 <https://github.com/rust-lang/rust/issues/56105>",
1389 /// The `deprecated` lint detects use of deprecated items.
1406 /// Items may be marked "deprecated" with the [`deprecated` attribute] to
1407 /// indicate that they should no longer be used. Usually the attribute
1408 /// should include a note on what to use instead, or check the
1411 /// [`deprecated` attribute]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute
1414 "detects use of deprecated items",
1415 report_in_external_macro
1419 /// The `unused_unsafe` lint detects unnecessary use of an `unsafe` block.
1431 /// If nothing within the block requires `unsafe`, then remove the
1432 /// `unsafe` marker because it is not required and may cause confusion.
1435 "unnecessary use of an `unsafe` block"
1439 /// The `unused_mut` lint detects mut variables which don't need to be
1452 /// The preferred style is to only mark variables as `mut` if it is
1456 "detect mut variables which don't need to be mutable"
1460 /// The `unconditional_recursion` lint detects functions that cannot
1461 /// return without calling themselves.
1475 /// It is usually a mistake to have a recursive call that does not have
1476 /// some condition to cause it to terminate. If you really intend to have
1477 /// an infinite loop, using a `loop` expression is recommended.
1478 pub UNCONDITIONAL_RECURSION,
1480 "functions that cannot return without calling themselves"
1484 /// The `single_use_lifetimes` lint detects lifetimes that are only used
1489 /// ```rust,compile_fail
1490 /// #![deny(single_use_lifetimes)]
1492 /// fn foo<'a>(x: &'a u32) {}
1499 /// Specifying an explicit lifetime like `'a` in a function or `impl`
1500 /// should only be used to link together two things. Otherwise, you should
1501 /// just use `'_` to indicate that the lifetime is not linked to anything,
1502 /// or elide the lifetime altogether if possible.
1504 /// This lint is "allow" by default because it was introduced at a time
1505 /// when `'_` and elided lifetimes were first being introduced, and this
1506 /// lint would be too noisy. Also, there are some known false positives
1507 /// that it produces. See [RFC 2115] for historical context, and [issue
1508 /// #44752] for more details.
1510 /// [RFC 2115]: https://github.com/rust-lang/rfcs/blob/master/text/2115-argument-lifetimes.md
1511 /// [issue #44752]: https://github.com/rust-lang/rust/issues/44752
1512 pub SINGLE_USE_LIFETIMES,
1514 "detects lifetime parameters that are only used once"
1518 /// The `unused_lifetimes` lint detects lifetime parameters that are never
1523 /// ```rust,compile_fail
1524 /// #[deny(unused_lifetimes)]
1526 /// pub fn foo<'a>() {}
1533 /// Unused lifetime parameters may signal a mistake or unfinished code.
1534 /// Consider removing the parameter.
1535 pub UNUSED_LIFETIMES,
1537 "detects lifetime parameters that are never used"
1541 /// The `tyvar_behind_raw_pointer` lint detects raw pointer to an
1542 /// inference variable.
1546 /// ```rust,edition2015
1548 /// let data = std::ptr::null();
1549 /// let _ = &data as *const *const ();
1551 /// if data.is_null() {}
1558 /// This kind of inference was previously allowed, but with the future
1559 /// arrival of [arbitrary self types], this can introduce ambiguity. To
1560 /// resolve this, use an explicit type instead of relying on type
1563 /// This is a [future-incompatible] lint to transition this to a hard
1564 /// error in the 2018 edition. See [issue #46906] for more details. This
1565 /// is currently a hard-error on the 2018 edition, and is "warn" by
1566 /// default in the 2015 edition.
1568 /// [arbitrary self types]: https://github.com/rust-lang/rust/issues/44874
1569 /// [issue #46906]: https://github.com/rust-lang/rust/issues/46906
1570 /// [future-incompatible]: ../index.md#future-incompatible-lints
1571 pub TYVAR_BEHIND_RAW_POINTER,
1573 "raw pointer to an inference variable",
1574 @future_incompatible = FutureIncompatibleInfo {
1575 reference: "issue #46906 <https://github.com/rust-lang/rust/issues/46906>",
1576 edition: Some(Edition::Edition2018),
1581 /// The `elided_lifetimes_in_paths` lint detects the use of hidden
1582 /// lifetime parameters.
1586 /// ```rust,compile_fail
1587 /// #![deny(elided_lifetimes_in_paths)]
1588 /// struct Foo<'a> {
1592 /// fn foo(x: &Foo) {
1600 /// Elided lifetime parameters can make it difficult to see at a glance
1601 /// that borrowing is occurring. This lint ensures that lifetime
1602 /// parameters are always explicitly stated, even if it is the `'_`
1603 /// [placeholder lifetime].
1605 /// This lint is "allow" by default because it has some known issues, and
1606 /// may require a significant transition for old code.
1608 /// [placeholder lifetime]: https://doc.rust-lang.org/reference/lifetime-elision.html#lifetime-elision-in-functions
1609 pub ELIDED_LIFETIMES_IN_PATHS,
1611 "hidden lifetime parameters in types are deprecated",
1616 /// The `bare_trait_objects` lint suggests using `dyn Trait` for trait
1624 /// fn takes_trait_object(_: Box<Trait>) {
1632 /// Without the `dyn` indicator, it can be ambiguous or confusing when
1633 /// reading code as to whether or not you are looking at a trait object.
1634 /// The `dyn` keyword makes it explicit, and adds a symmetry to contrast
1635 /// with [`impl Trait`].
1637 /// [`impl Trait`]: https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
1638 pub BARE_TRAIT_OBJECTS,
1640 "suggest using `dyn Trait` for trait objects"
1644 /// The `absolute_paths_not_starting_with_crate` lint detects fully
1645 /// qualified paths that start with a module name instead of `crate`,
1646 /// `self`, or an extern crate name
1650 /// ```rust,edition2015,compile_fail
1651 /// #![deny(absolute_paths_not_starting_with_crate)]
1666 /// Rust [editions] allow the language to evolve without breaking
1667 /// backwards compatibility. This lint catches code that uses absolute
1668 /// paths in the style of the 2015 edition. In the 2015 edition, absolute
1669 /// paths (those starting with `::`) refer to either the crate root or an
1670 /// external crate. In the 2018 edition it was changed so that they only
1671 /// refer to external crates. The path prefix `crate::` should be used
1672 /// instead to reference items from the crate root.
1674 /// If you switch the compiler from the 2015 to 2018 edition without
1675 /// updating the code, then it will fail to compile if the old style paths
1676 /// are used. You can manually change the paths to use the `crate::`
1677 /// prefix to transition to the 2018 edition.
1679 /// This lint solves the problem automatically. It is "allow" by default
1680 /// because the code is perfectly valid in the 2015 edition. The [`cargo
1681 /// fix`] tool with the `--edition` flag will switch this lint to "warn"
1682 /// and automatically apply the suggested fix from the compiler. This
1683 /// provides a completely automated way to update old code to the 2018
1686 /// [editions]: https://doc.rust-lang.org/edition-guide/
1687 /// [`cargo fix`]: https://doc.rust-lang.org/cargo/commands/cargo-fix.html
1688 pub ABSOLUTE_PATHS_NOT_STARTING_WITH_CRATE,
1690 "fully qualified paths that start with a module name \
1691 instead of `crate`, `self`, or an extern crate name",
1692 @future_incompatible = FutureIncompatibleInfo {
1693 reference: "issue #53130 <https://github.com/rust-lang/rust/issues/53130>",
1694 edition: Some(Edition::Edition2018),
1699 /// The `illegal_floating_point_literal_pattern` lint detects
1700 /// floating-point literals used in patterns.
1717 /// Previous versions of the compiler accepted floating-point literals in
1718 /// patterns, but it was later determined this was a mistake. The
1719 /// semantics of comparing floating-point values may not be clear in a
1720 /// pattern when contrasted with "structural equality". Typically you can
1721 /// work around this by using a [match guard], such as:
1727 /// y if y == 5.0 => {}
1732 /// This is a [future-incompatible] lint to transition this to a hard
1733 /// error in the future. See [issue #41620] for more details.
1735 /// [issue #41620]: https://github.com/rust-lang/rust/issues/41620
1736 /// [match guard]: https://doc.rust-lang.org/reference/expressions/match-expr.html#match-guards
1737 /// [future-incompatible]: ../index.md#future-incompatible-lints
1738 pub ILLEGAL_FLOATING_POINT_LITERAL_PATTERN,
1740 "floating-point literals cannot be used in patterns",
1741 @future_incompatible = FutureIncompatibleInfo {
1742 reference: "issue #41620 <https://github.com/rust-lang/rust/issues/41620>",
1748 /// The `unstable_name_collisions` lint detects that you have used a name
1749 /// that the standard library plans to add in the future.
1754 /// trait MyIterator : Iterator {
1755 /// // is_sorted is an unstable method that already exists on the Iterator trait
1756 /// fn is_sorted(self) -> bool where Self: Sized {true}
1759 /// impl<T: ?Sized> MyIterator for T where T: Iterator { }
1761 /// let x = vec![1, 2, 3];
1762 /// let _ = x.iter().is_sorted();
1769 /// When new methods are added to traits in the standard library, they are
1770 /// usually added in an "unstable" form which is only available on the
1771 /// [nightly channel] with a [`feature` attribute]. If there is any
1772 /// pre-existing code which extends a trait to have a method with the same
1773 /// name, then the names will collide. In the future, when the method is
1774 /// stabilized, this will cause an error due to the ambiguity. This lint
1775 /// is an early-warning to let you know that there may be a collision in
1776 /// the future. This can be avoided by adding type annotations to
1777 /// disambiguate which trait method you intend to call, such as
1778 /// `MyIterator::is_sorted(my_iter)` or renaming or removing the method.
1780 /// [nightly channel]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
1781 /// [`feature` attribute]: https://doc.rust-lang.org/nightly/unstable-book/
1782 pub UNSTABLE_NAME_COLLISIONS,
1784 "detects name collision with an existing but unstable method",
1785 @future_incompatible = FutureIncompatibleInfo {
1786 reference: "issue #48919 <https://github.com/rust-lang/rust/issues/48919>",
1788 // Note: this item represents future incompatibility of all unstable functions in the
1789 // standard library, and thus should never be removed or changed to an error.
1794 /// The `irrefutable_let_patterns` lint detects detects [irrefutable
1795 /// patterns] in [if-let] and [while-let] statements.
1802 /// if let _ = 123 {
1803 /// println!("always runs!");
1811 /// There usually isn't a reason to have an irrefutable pattern in an
1812 /// if-let or while-let statement, because the pattern will always match
1813 /// successfully. A [`let`] or [`loop`] statement will suffice. However,
1814 /// when generating code with a macro, forbidding irrefutable patterns
1815 /// would require awkward workarounds in situations where the macro
1816 /// doesn't know if the pattern is refutable or not. This lint allows
1817 /// macros to accept this form, while alerting for a possibly incorrect
1818 /// use in normal code.
1820 /// See [RFC 2086] for more details.
1822 /// [irrefutable patterns]: https://doc.rust-lang.org/reference/patterns.html#refutability
1823 /// [if-let]: https://doc.rust-lang.org/reference/expressions/if-expr.html#if-let-expressions
1824 /// [while-let]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#predicate-pattern-loops
1825 /// [`let`]: https://doc.rust-lang.org/reference/statements.html#let-statements
1826 /// [`loop`]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#infinite-loops
1827 /// [RFC 2086]: https://github.com/rust-lang/rfcs/blob/master/text/2086-allow-if-let-irrefutables.md
1828 pub IRREFUTABLE_LET_PATTERNS,
1830 "detects irrefutable patterns in if-let and while-let statements"
1834 /// The `unused_labels` lint detects [labels] that are never used.
1836 /// [labels]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#loop-labels
1841 /// 'unused_label: loop {}
1848 /// Unused labels may signal a mistake or unfinished code. To silence the
1849 /// warning for the individual label, prefix it with an underscore such as
1853 "detects labels that are never used"
1857 /// The `broken_intra_doc_links` lint detects failures in resolving
1858 /// intra-doc link targets. This is a `rustdoc` only lint, see the
1859 /// documentation in the [rustdoc book].
1861 /// [rustdoc book]: ../../../rustdoc/lints.html#broken_intra_doc_links
1862 pub BROKEN_INTRA_DOC_LINKS,
1864 "failures in resolving intra-doc link targets"
1868 /// This is a subset of `broken_intra_doc_links` that warns when linking from
1869 /// a public item to a private one. This is a `rustdoc` only lint, see the
1870 /// documentation in the [rustdoc book].
1872 /// [rustdoc book]: ../../../rustdoc/lints.html#private_intra_doc_links
1873 pub PRIVATE_INTRA_DOC_LINKS,
1875 "linking from a public item to a private one"
1879 /// The `invalid_codeblock_attributes` lint detects code block attributes
1880 /// in documentation examples that have potentially mis-typed values. This
1881 /// is a `rustdoc` only lint, see the documentation in the [rustdoc book].
1883 /// [rustdoc book]: ../../../rustdoc/lints.html#invalid_codeblock_attributes
1884 pub INVALID_CODEBLOCK_ATTRIBUTES,
1886 "codeblock attribute looks a lot like a known one"
1890 /// The `missing_crate_level_docs` lint detects if documentation is
1891 /// missing at the crate root. This is a `rustdoc` only lint, see the
1892 /// documentation in the [rustdoc book].
1894 /// [rustdoc book]: ../../../rustdoc/lints.html#missing_crate_level_docs
1895 pub MISSING_CRATE_LEVEL_DOCS,
1897 "detects crates with no crate-level documentation"
1901 /// The `missing_doc_code_examples` lint detects publicly-exported items
1902 /// without code samples in their documentation. This is a `rustdoc` only
1903 /// lint, see the documentation in the [rustdoc book].
1905 /// [rustdoc book]: ../../../rustdoc/lints.html#missing_doc_code_examples
1906 pub MISSING_DOC_CODE_EXAMPLES,
1908 "detects publicly-exported items without code samples in their documentation"
1912 /// The `private_doc_tests` lint detects code samples in docs of private
1913 /// items not documented by `rustdoc`. This is a `rustdoc` only lint, see
1914 /// the documentation in the [rustdoc book].
1916 /// [rustdoc book]: ../../../rustdoc/lints.html#private_doc_tests
1917 pub PRIVATE_DOC_TESTS,
1919 "detects code samples in docs of private items not documented by rustdoc"
1923 /// The `invalid_html_tags` lint detects invalid HTML tags. This is a
1924 /// `rustdoc` only lint, see the documentation in the [rustdoc book].
1926 /// [rustdoc book]: ../../../rustdoc/lints.html#invalid_html_tags
1927 pub INVALID_HTML_TAGS,
1929 "detects invalid HTML tags in doc comments"
1933 /// The `non_autolinks` lint detects when a URL could be written using
1934 /// only angle brackets. This is a `rustdoc` only lint, see the
1935 /// documentation in the [rustdoc book].
1937 /// [rustdoc book]: ../../../rustdoc/lints.html#non_autolinks
1940 "detects URLs that could be written using only angle brackets"
1944 /// The `where_clauses_object_safety` lint detects for [object safety] of
1945 /// [where clauses].
1947 /// [object safety]: https://doc.rust-lang.org/reference/items/traits.html#object-safety
1948 /// [where clauses]: https://doc.rust-lang.org/reference/items/generics.html#where-clauses
1955 /// trait X { fn foo(&self) where Self: Trait; }
1957 /// impl X for () { fn foo(&self) {} }
1959 /// impl Trait for dyn X {}
1961 /// // Segfault at opt-level 0, SIGILL otherwise.
1962 /// pub fn main() { <dyn X as X>::foo(&()); }
1969 /// The compiler previously allowed these object-unsafe bounds, which was
1970 /// incorrect. This is a [future-incompatible] lint to transition this to
1971 /// a hard error in the future. See [issue #51443] for more details.
1973 /// [issue #51443]: https://github.com/rust-lang/rust/issues/51443
1974 /// [future-incompatible]: ../index.md#future-incompatible-lints
1975 pub WHERE_CLAUSES_OBJECT_SAFETY,
1977 "checks the object safety of where clauses",
1978 @future_incompatible = FutureIncompatibleInfo {
1979 reference: "issue #51443 <https://github.com/rust-lang/rust/issues/51443>",
1985 /// The `proc_macro_derive_resolution_fallback` lint detects proc macro
1986 /// derives using inaccessible names from parent modules.
1990 /// ```rust,ignore (proc-macro)
1992 /// #![crate_type = "proc-macro"]
1994 /// extern crate proc_macro;
1996 /// use proc_macro::*;
1998 /// #[proc_macro_derive(Foo)]
1999 /// pub fn foo1(a: TokenStream) -> TokenStream {
2001 /// "mod __bar { static mut BAR: Option<Something> = None; }".parse().unwrap()
2005 /// ```rust,ignore (needs-dependency)
2008 /// extern crate foo;
2010 /// struct Something;
2018 /// This will produce:
2021 /// warning: cannot find type `Something` in this scope
2022 /// --> src/main.rs:8:10
2024 /// 8 | #[derive(Foo)]
2025 /// | ^^^ names from parent modules are not accessible without an explicit import
2027 /// = note: `#[warn(proc_macro_derive_resolution_fallback)]` on by default
2028 /// = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
2029 /// = note: for more information, see issue #50504 <https://github.com/rust-lang/rust/issues/50504>
2034 /// If a proc-macro generates a module, the compiler unintentionally
2035 /// allowed items in that module to refer to items in the crate root
2036 /// without importing them. This is a [future-incompatible] lint to
2037 /// transition this to a hard error in the future. See [issue #50504] for
2040 /// [issue #50504]: https://github.com/rust-lang/rust/issues/50504
2041 /// [future-incompatible]: ../index.md#future-incompatible-lints
2042 pub PROC_MACRO_DERIVE_RESOLUTION_FALLBACK,
2044 "detects proc macro derives using inaccessible names from parent modules",
2045 @future_incompatible = FutureIncompatibleInfo {
2046 reference: "issue #50504 <https://github.com/rust-lang/rust/issues/50504>",
2052 /// The `macro_use_extern_crate` lint detects the use of the
2053 /// [`macro_use` attribute].
2057 /// ```rust,ignore (needs extern crate)
2058 /// #![deny(macro_use_extern_crate)]
2061 /// extern crate serde_json;
2064 /// let _ = json!{{}};
2068 /// This will produce:
2071 /// error: deprecated `#[macro_use]` attribute used to import macros should be replaced at use sites with a `use` item to import the macro instead
2072 /// --> src/main.rs:3:1
2074 /// 3 | #[macro_use]
2077 /// note: the lint level is defined here
2078 /// --> src/main.rs:1:9
2080 /// 1 | #![deny(macro_use_extern_crate)]
2081 /// | ^^^^^^^^^^^^^^^^^^^^^^
2086 /// The [`macro_use` attribute] on an [`extern crate`] item causes
2087 /// macros in that external crate to be brought into the prelude of the
2088 /// crate, making the macros in scope everywhere. As part of the efforts
2089 /// to simplify handling of dependencies in the [2018 edition], the use of
2090 /// `extern crate` is being phased out. To bring macros from extern crates
2091 /// into scope, it is recommended to use a [`use` import].
2093 /// This lint is "allow" by default because this is a stylistic choice
2094 /// that has not been settled, see [issue #52043] for more information.
2096 /// [`macro_use` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#the-macro_use-attribute
2097 /// [`use` import]: https://doc.rust-lang.org/reference/items/use-declarations.html
2098 /// [issue #52043]: https://github.com/rust-lang/rust/issues/52043
2099 pub MACRO_USE_EXTERN_CRATE,
2101 "the `#[macro_use]` attribute is now deprecated in favor of using macros \
2102 via the module system"
2106 /// The `macro_expanded_macro_exports_accessed_by_absolute_paths` lint
2107 /// detects macro-expanded [`macro_export`] macros from the current crate
2108 /// that cannot be referred to by absolute paths.
2110 /// [`macro_export`]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
2114 /// ```rust,compile_fail
2115 /// macro_rules! define_exported {
2118 /// macro_rules! exported {
2124 /// define_exported!();
2127 /// crate::exported!();
2135 /// The intent is that all macros marked with the `#[macro_export]`
2136 /// attribute are made available in the root of the crate. However, when a
2137 /// `macro_rules!` definition is generated by another macro, the macro
2138 /// expansion is unable to uphold this rule. This is a
2139 /// [future-incompatible] lint to transition this to a hard error in the
2140 /// future. See [issue #53495] for more details.
2142 /// [issue #53495]: https://github.com/rust-lang/rust/issues/53495
2143 /// [future-incompatible]: ../index.md#future-incompatible-lints
2144 pub MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS,
2146 "macro-expanded `macro_export` macros from the current crate \
2147 cannot be referred to by absolute paths",
2148 @future_incompatible = FutureIncompatibleInfo {
2149 reference: "issue #52234 <https://github.com/rust-lang/rust/issues/52234>",
2156 /// The `explicit_outlives_requirements` lint detects unnecessary
2157 /// lifetime bounds that can be inferred.
2161 /// ```rust,compile_fail
2162 /// # #![allow(unused)]
2163 /// #![deny(explicit_outlives_requirements)]
2165 /// struct SharedRef<'a, T>
2177 /// If a `struct` contains a reference, such as `&'a T`, the compiler
2178 /// requires that `T` outlives the lifetime `'a`. This historically
2179 /// required writing an explicit lifetime bound to indicate this
2180 /// requirement. However, this can be overly explicit, causing clutter and
2181 /// unnecessary complexity. The language was changed to automatically
2182 /// infer the bound if it is not specified. Specifically, if the struct
2183 /// contains a reference, directly or indirectly, to `T` with lifetime
2184 /// `'x`, then it will infer that `T: 'x` is a requirement.
2186 /// This lint is "allow" by default because it can be noisy for existing
2187 /// code that already had these requirements. This is a stylistic choice,
2188 /// as it is still valid to explicitly state the bound. It also has some
2189 /// false positives that can cause confusion.
2191 /// See [RFC 2093] for more details.
2193 /// [RFC 2093]: https://github.com/rust-lang/rfcs/blob/master/text/2093-infer-outlives.md
2194 pub EXPLICIT_OUTLIVES_REQUIREMENTS,
2196 "outlives requirements can be inferred"
2200 /// The `indirect_structural_match` lint detects a `const` in a pattern
2201 /// that manually implements [`PartialEq`] and [`Eq`].
2203 /// [`PartialEq`]: https://doc.rust-lang.org/std/cmp/trait.PartialEq.html
2204 /// [`Eq`]: https://doc.rust-lang.org/std/cmp/trait.Eq.html
2208 /// ```rust,compile_fail
2209 /// #![deny(indirect_structural_match)]
2211 /// struct NoDerive(i32);
2212 /// impl PartialEq for NoDerive { fn eq(&self, _: &Self) -> bool { false } }
2213 /// impl Eq for NoDerive { }
2214 /// #[derive(PartialEq, Eq)]
2215 /// struct WrapParam<T>(T);
2216 /// const WRAP_INDIRECT_PARAM: & &WrapParam<NoDerive> = & &WrapParam(NoDerive(0));
2218 /// match WRAP_INDIRECT_PARAM {
2219 /// WRAP_INDIRECT_PARAM => { }
2229 /// The compiler unintentionally accepted this form in the past. This is a
2230 /// [future-incompatible] lint to transition this to a hard error in the
2231 /// future. See [issue #62411] for a complete description of the problem,
2232 /// and some possible solutions.
2234 /// [issue #62411]: https://github.com/rust-lang/rust/issues/62411
2235 /// [future-incompatible]: ../index.md#future-incompatible-lints
2236 pub INDIRECT_STRUCTURAL_MATCH,
2238 "constant used in pattern contains value of non-structural-match type in a field or a variant",
2239 @future_incompatible = FutureIncompatibleInfo {
2240 reference: "issue #62411 <https://github.com/rust-lang/rust/issues/62411>",
2246 /// The `deprecated_in_future` lint is internal to rustc and should not be
2247 /// used by user code.
2249 /// This lint is only enabled in the standard library. It works with the
2250 /// use of `#[rustc_deprecated]` with a `since` field of a version in the
2251 /// future. This allows something to be marked as deprecated in a future
2252 /// version, and then this lint will ensure that the item is no longer
2253 /// used in the standard library. See the [stability documentation] for
2256 /// [stability documentation]: https://rustc-dev-guide.rust-lang.org/stability.html#rustc_deprecated
2257 pub DEPRECATED_IN_FUTURE,
2259 "detects use of items that will be deprecated in a future version",
2260 report_in_external_macro
2264 /// The `pointer_structural_match` lint detects pointers used in patterns whose behaviour
2265 /// cannot be relied upon across compiler versions and optimization levels.
2269 /// ```rust,compile_fail
2270 /// #![deny(pointer_structural_match)]
2271 /// fn foo(a: usize, b: usize) -> usize { a + b }
2272 /// const FOO: fn(usize, usize) -> usize = foo;
2285 /// Previous versions of Rust allowed function pointers and wide raw pointers in patterns.
2286 /// While these work in many cases as expected by users, it is possible that due to
2287 /// optimizations pointers are "not equal to themselves" or pointers to different functions
2288 /// compare as equal during runtime. This is because LLVM optimizations can deduplicate
2289 /// functions if their bodies are the same, thus also making pointers to these functions point
2290 /// to the same location. Additionally functions may get duplicated if they are instantiated
2291 /// in different crates and not deduplicated again via LTO.
2292 pub POINTER_STRUCTURAL_MATCH,
2294 "pointers are not structural-match",
2295 @future_incompatible = FutureIncompatibleInfo {
2296 reference: "issue #62411 <https://github.com/rust-lang/rust/issues/70861>",
2302 /// The `nontrivial_structural_match` lint detects constants that are used in patterns,
2303 /// whose type is not structural-match and whose initializer body actually uses values
2304 /// that are not structural-match. So `Option<NotStruturalMatch>` is ok if the constant
2309 /// ```rust,compile_fail
2310 /// #![deny(nontrivial_structural_match)]
2312 /// #[derive(Copy, Clone, Debug)]
2313 /// struct NoDerive(u32);
2314 /// impl PartialEq for NoDerive { fn eq(&self, _: &Self) -> bool { false } }
2315 /// impl Eq for NoDerive { }
2317 /// const INDEX: Option<NoDerive> = [None, Some(NoDerive(10))][0];
2318 /// match None { Some(_) => panic!("whoops"), INDEX => dbg!(INDEX), };
2326 /// Previous versions of Rust accepted constants in patterns, even if those constants's types
2327 /// did not have `PartialEq` derived. Thus the compiler falls back to runtime execution of
2328 /// `PartialEq`, which can report that two constants are not equal even if they are
2330 pub NONTRIVIAL_STRUCTURAL_MATCH,
2332 "constant used in pattern of non-structural-match type and the constant's initializer \
2333 expression contains values of non-structural-match types",
2334 @future_incompatible = FutureIncompatibleInfo {
2335 reference: "issue #73448 <https://github.com/rust-lang/rust/issues/73448>",
2341 /// The `ambiguous_associated_items` lint detects ambiguity between
2342 /// [associated items] and [enum variants].
2344 /// [associated items]: https://doc.rust-lang.org/reference/items/associated-items.html
2345 /// [enum variants]: https://doc.rust-lang.org/reference/items/enumerations.html
2349 /// ```rust,compile_fail
2356 /// fn foo() -> Self::V;
2361 /// // `Self::V` is ambiguous because it may refer to the associated type or
2362 /// // the enum variant.
2363 /// fn foo() -> Self::V { 0 }
2371 /// Previous versions of Rust did not allow accessing enum variants
2372 /// through [type aliases]. When this ability was added (see [RFC 2338]), this
2373 /// introduced some situations where it can be ambiguous what a type
2374 /// was referring to.
2376 /// To fix this ambiguity, you should use a [qualified path] to explicitly
2377 /// state which type to use. For example, in the above example the
2378 /// function can be written as `fn f() -> <Self as Tr>::V { 0 }` to
2379 /// specifically refer to the associated type.
2381 /// This is a [future-incompatible] lint to transition this to a hard
2382 /// error in the future. See [issue #57644] for more details.
2384 /// [issue #57644]: https://github.com/rust-lang/rust/issues/57644
2385 /// [type aliases]: https://doc.rust-lang.org/reference/items/type-aliases.html#type-aliases
2386 /// [RFC 2338]: https://github.com/rust-lang/rfcs/blob/master/text/2338-type-alias-enum-variants.md
2387 /// [qualified path]: https://doc.rust-lang.org/reference/paths.html#qualified-paths
2388 /// [future-incompatible]: ../index.md#future-incompatible-lints
2389 pub AMBIGUOUS_ASSOCIATED_ITEMS,
2391 "ambiguous associated items",
2392 @future_incompatible = FutureIncompatibleInfo {
2393 reference: "issue #57644 <https://github.com/rust-lang/rust/issues/57644>",
2399 /// The `mutable_borrow_reservation_conflict` lint detects the reservation
2400 /// of a two-phased borrow that conflicts with other shared borrows.
2405 /// let mut v = vec![0, 1, 2];
2406 /// let shared = &v;
2407 /// v.push(shared.len());
2414 /// This is a [future-incompatible] lint to transition this to a hard error
2415 /// in the future. See [issue #59159] for a complete description of the
2416 /// problem, and some possible solutions.
2418 /// [issue #59159]: https://github.com/rust-lang/rust/issues/59159
2419 /// [future-incompatible]: ../index.md#future-incompatible-lints
2420 pub MUTABLE_BORROW_RESERVATION_CONFLICT,
2422 "reservation of a two-phased borrow conflicts with other shared borrows",
2423 @future_incompatible = FutureIncompatibleInfo {
2424 reference: "issue #59159 <https://github.com/rust-lang/rust/issues/59159>",
2430 /// The `soft_unstable` lint detects unstable features that were
2431 /// unintentionally allowed on stable.
2435 /// ```rust,compile_fail
2437 /// extern crate test;
2440 /// fn name(b: &mut test::Bencher) {
2449 /// The [`bench` attribute] was accidentally allowed to be specified on
2450 /// the [stable release channel]. Turning this to a hard error would have
2451 /// broken some projects. This lint allows those projects to continue to
2452 /// build correctly when [`--cap-lints`] is used, but otherwise signal an
2453 /// error that `#[bench]` should not be used on the stable channel. This
2454 /// is a [future-incompatible] lint to transition this to a hard error in
2455 /// the future. See [issue #64266] for more details.
2457 /// [issue #64266]: https://github.com/rust-lang/rust/issues/64266
2458 /// [`bench` attribute]: https://doc.rust-lang.org/nightly/unstable-book/library-features/test.html
2459 /// [stable release channel]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
2460 /// [`--cap-lints`]: https://doc.rust-lang.org/rustc/lints/levels.html#capping-lints
2461 /// [future-incompatible]: ../index.md#future-incompatible-lints
2464 "a feature gate that doesn't break dependent crates",
2465 @future_incompatible = FutureIncompatibleInfo {
2466 reference: "issue #64266 <https://github.com/rust-lang/rust/issues/64266>",
2472 /// The `inline_no_sanitize` lint detects incompatible use of
2473 /// [`#[inline(always)]`][inline] and [`#[no_sanitize(...)]`][no_sanitize].
2475 /// [inline]: https://doc.rust-lang.org/reference/attributes/codegen.html#the-inline-attribute
2476 /// [no_sanitize]: https://doc.rust-lang.org/nightly/unstable-book/language-features/no-sanitize.html
2481 /// #![feature(no_sanitize)]
2483 /// #[inline(always)]
2484 /// #[no_sanitize(address)]
2496 /// The use of the [`#[inline(always)]`][inline] attribute prevents the
2497 /// the [`#[no_sanitize(...)]`][no_sanitize] attribute from working.
2498 /// Consider temporarily removing `inline` attribute.
2499 pub INLINE_NO_SANITIZE,
2501 "detects incompatible use of `#[inline(always)]` and `#[no_sanitize(...)]`",
2505 /// The `asm_sub_register` lint detects using only a subset of a register
2506 /// for inline asm inputs.
2510 /// ```rust,ignore (fails on system llvm)
2511 /// #![feature(asm)]
2514 /// #[cfg(target_arch="x86_64")]
2516 /// asm!("mov {0}, {0}", in(reg) 0i16);
2521 /// This will produce:
2524 /// warning: formatting may not be suitable for sub-register argument
2525 /// --> src/main.rs:6:19
2527 /// 6 | asm!("mov {0}, {0}", in(reg) 0i16);
2528 /// | ^^^ ^^^ ---- for this argument
2530 /// = note: `#[warn(asm_sub_register)]` on by default
2531 /// = help: use the `x` modifier to have the register formatted as `ax`
2532 /// = help: or use the `r` modifier to keep the default formatting of `rax`
2537 /// Registers on some architectures can use different names to refer to a
2538 /// subset of the register. By default, the compiler will use the name for
2539 /// the full register size. To explicitly use a subset of the register,
2540 /// you can override the default by using a modifier on the template
2541 /// string operand to specify when subregister to use. This lint is issued
2542 /// if you pass in a value with a smaller data type than the default
2543 /// register size, to alert you of possibly using the incorrect width. To
2544 /// fix this, add the suggested modifier to the template, or cast the
2545 /// value to the correct size.
2547 /// See [register template modifiers] for more details.
2549 /// [register template modifiers]: https://doc.rust-lang.org/nightly/unstable-book/library-features/asm.html#register-template-modifiers
2550 pub ASM_SUB_REGISTER,
2552 "using only a subset of a register for inline asm inputs",
2556 /// The `unsafe_op_in_unsafe_fn` lint detects unsafe operations in unsafe
2557 /// functions without an explicit unsafe block. This lint only works on
2558 /// the [**nightly channel**] with the
2559 /// `#![feature(unsafe_block_in_unsafe_fn)]` feature.
2561 /// [**nightly channel**]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
2565 /// ```rust,compile_fail
2566 /// #![feature(unsafe_block_in_unsafe_fn)]
2567 /// #![deny(unsafe_op_in_unsafe_fn)]
2569 /// unsafe fn foo() {}
2571 /// unsafe fn bar() {
2582 /// Currently, an [`unsafe fn`] allows any [unsafe] operation within its
2583 /// body. However, this can increase the surface area of code that needs
2584 /// to be scrutinized for proper behavior. The [`unsafe` block] provides a
2585 /// convenient way to make it clear exactly which parts of the code are
2586 /// performing unsafe operations. In the future, it is desired to change
2587 /// it so that unsafe operations cannot be performed in an `unsafe fn`
2588 /// without an `unsafe` block.
2590 /// The fix to this is to wrap the unsafe code in an `unsafe` block.
2592 /// This lint is "allow" by default because it has not yet been
2593 /// stabilized, and is not yet complete. See [RFC #2585] and [issue
2594 /// #71668] for more details
2596 /// [`unsafe fn`]: https://doc.rust-lang.org/reference/unsafe-functions.html
2597 /// [`unsafe` block]: https://doc.rust-lang.org/reference/expressions/block-expr.html#unsafe-blocks
2598 /// [unsafe]: https://doc.rust-lang.org/reference/unsafety.html
2599 /// [RFC #2585]: https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md
2600 /// [issue #71668]: https://github.com/rust-lang/rust/issues/71668
2601 pub UNSAFE_OP_IN_UNSAFE_FN,
2603 "unsafe operations in unsafe functions without an explicit unsafe block are deprecated",
2604 @feature_gate = sym::unsafe_block_in_unsafe_fn;
2608 /// The `cenum_impl_drop_cast` lint detects an `as` cast of a field-less
2609 /// `enum` that implements [`Drop`].
2611 /// [`Drop`]: https://doc.rust-lang.org/std/ops/trait.Drop.html
2616 /// # #![allow(unused)]
2621 /// impl Drop for E {
2622 /// fn drop(&mut self) {
2623 /// println!("Drop");
2629 /// let i = e as u32;
2637 /// Casting a field-less `enum` that does not implement [`Copy`] to an
2638 /// integer moves the value without calling `drop`. This can result in
2639 /// surprising behavior if it was expected that `drop` should be called.
2640 /// Calling `drop` automatically would be inconsistent with other move
2641 /// operations. Since neither behavior is clear or consistent, it was
2642 /// decided that a cast of this nature will no longer be allowed.
2644 /// This is a [future-incompatible] lint to transition this to a hard error
2645 /// in the future. See [issue #73333] for more details.
2647 /// [future-incompatible]: ../index.md#future-incompatible-lints
2648 /// [issue #73333]: https://github.com/rust-lang/rust/issues/73333
2649 /// [`Copy`]: https://doc.rust-lang.org/std/marker/trait.Copy.html
2650 pub CENUM_IMPL_DROP_CAST,
2652 "a C-like enum implementing Drop is cast",
2653 @future_incompatible = FutureIncompatibleInfo {
2654 reference: "issue #73333 <https://github.com/rust-lang/rust/issues/73333>",
2660 /// The `const_evaluatable_unchecked` lint detects a generic constant used
2666 /// const fn foo<T>() -> usize {
2667 /// if std::mem::size_of::<*mut T>() < 8 { // size of *mut T does not depend on T
2675 /// let _ = [0; foo::<T>()];
2683 /// In the 1.43 release, some uses of generic parameters in array repeat
2684 /// expressions were accidentally allowed. This is a [future-incompatible]
2685 /// lint to transition this to a hard error in the future. See [issue
2686 /// #76200] for a more detailed description and possible fixes.
2688 /// [future-incompatible]: ../index.md#future-incompatible-lints
2689 /// [issue #76200]: https://github.com/rust-lang/rust/issues/76200
2690 pub CONST_EVALUATABLE_UNCHECKED,
2692 "detects a generic constant is used in a type without a emitting a warning",
2693 @future_incompatible = FutureIncompatibleInfo {
2694 reference: "issue #76200 <https://github.com/rust-lang/rust/issues/76200>",
2700 /// The `function_item_references` lint detects function references that are
2701 /// formatted with [`fmt::Pointer`] or transmuted.
2703 /// [`fmt::Pointer`]: https://doc.rust-lang.org/std/fmt/trait.Pointer.html
2711 /// println!("{:p}", &foo);
2719 /// Taking a reference to a function may be mistaken as a way to obtain a
2720 /// pointer to that function. This can give unexpected results when
2721 /// formatting the reference as a pointer or transmuting it. This lint is
2722 /// issued when function references are formatted as pointers, passed as
2723 /// arguments bound by [`fmt::Pointer`] or transmuted.
2724 pub FUNCTION_ITEM_REFERENCES,
2726 "suggest casting to a function pointer when attempting to take references to function items",
2730 /// The `uninhabited_static` lint detects uninhabited statics.
2737 /// static EXTERN: Void;
2745 /// Statics with an uninhabited type can never be initialized, so they are impossible to define.
2746 /// However, this can be side-stepped with an `extern static`, leading to problems later in the
2747 /// compiler which assumes that there are no initialized uninhabited places (such as locals or
2748 /// statics). This was accientally allowed, but is being phased out.
2749 pub UNINHABITED_STATIC,
2751 "uninhabited static",
2752 @future_incompatible = FutureIncompatibleInfo {
2753 reference: "issue #74840 <https://github.com/rust-lang/rust/issues/74840>",
2759 /// The `useless_deprecated` lint detects deprecation attributes with no effect.
2763 /// ```rust,compile_fail
2766 /// #[deprecated = "message"]
2767 /// impl Default for X {
2768 /// fn default() -> Self {
2778 /// Deprecation attributes have no effect on trait implementations.
2779 pub USELESS_DEPRECATED,
2781 "detects deprecation attributes with no effect",
2785 /// The `unsupported_naked_functions` lint detects naked function
2786 /// definitions that are unsupported but were previously accepted.
2791 /// #![feature(naked_functions)]
2794 /// pub fn f() -> u32 {
2803 /// The naked functions must be defined using a single inline assembly
2806 /// The execution must never fall through past the end of the assembly
2807 /// code so the block must use `noreturn` option. The asm block can also
2808 /// use `att_syntax` option, but other options are not allowed.
2810 /// The asm block must not contain any operands other than `const` and
2811 /// `sym`. Additionally, naked function should specify a non-Rust ABI.
2813 /// While other definitions of naked functions were previously accepted,
2814 /// they are unsupported and might not work reliably. This is a
2815 /// [future-incompatible] lint that will transition into hard error in
2818 /// [future-incompatible]: ../index.md#future-incompatible-lints
2819 pub UNSUPPORTED_NAKED_FUNCTIONS,
2821 "unsupported naked function definitions",
2822 @future_incompatible = FutureIncompatibleInfo {
2823 reference: "issue #32408 <https://github.com/rust-lang/rust/issues/32408>",
2828 declare_tool_lint! {
2829 pub rustc::INEFFECTIVE_UNSTABLE_TRAIT_IMPL,
2831 "detects `#[unstable]` on stable trait implementations for stable types"
2834 declare_lint_pass! {
2835 /// Does nothing as a lint pass, but registers some `Lint`s
2836 /// that are used by other parts of the compiler.
2838 ILLEGAL_FLOATING_POINT_LITERAL_PATTERN,
2839 ARITHMETIC_OVERFLOW,
2840 UNCONDITIONAL_PANIC,
2842 UNUSED_EXTERN_CRATES,
2843 UNUSED_CRATE_DEPENDENCIES,
2844 UNUSED_QUALIFICATIONS,
2850 UNREACHABLE_PATTERNS,
2851 OVERLAPPING_RANGE_ENDPOINTS,
2852 BINDINGS_WITH_VARIANT_NAME,
2857 UNKNOWN_CRATE_TYPES,
2859 TRIVIAL_NUMERIC_CASTS,
2861 EXPORTED_PRIVATE_DEPENDENCIES,
2862 PUB_USE_OF_PRIVATE_EXTERN_CRATE,
2863 INVALID_TYPE_PARAM_DEFAULT,
2865 RENAMED_AND_REMOVED_LINTS,
2866 UNALIGNED_REFERENCES,
2867 CONST_ITEM_MUTATION,
2868 SAFE_PACKED_BORROWS,
2869 PATTERNS_IN_FNS_WITHOUT_BODY,
2870 MISSING_FRAGMENT_SPECIFIER,
2871 LATE_BOUND_LIFETIME_ARGUMENTS,
2872 ORDER_DEPENDENT_TRAIT_OBJECTS,
2873 COHERENCE_LEAK_CHECK,
2877 UNCONDITIONAL_RECURSION,
2878 SINGLE_USE_LIFETIMES,
2881 TYVAR_BEHIND_RAW_POINTER,
2882 ELIDED_LIFETIMES_IN_PATHS,
2884 ABSOLUTE_PATHS_NOT_STARTING_WITH_CRATE,
2885 UNSTABLE_NAME_COLLISIONS,
2886 IRREFUTABLE_LET_PATTERNS,
2887 BROKEN_INTRA_DOC_LINKS,
2888 PRIVATE_INTRA_DOC_LINKS,
2889 INVALID_CODEBLOCK_ATTRIBUTES,
2890 MISSING_CRATE_LEVEL_DOCS,
2891 MISSING_DOC_CODE_EXAMPLES,
2895 WHERE_CLAUSES_OBJECT_SAFETY,
2896 PROC_MACRO_DERIVE_RESOLUTION_FALLBACK,
2897 MACRO_USE_EXTERN_CRATE,
2898 MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS,
2899 ILL_FORMED_ATTRIBUTE_INPUT,
2900 CONFLICTING_REPR_HINTS,
2901 META_VARIABLE_MISUSE,
2902 DEPRECATED_IN_FUTURE,
2903 AMBIGUOUS_ASSOCIATED_ITEMS,
2904 MUTABLE_BORROW_RESERVATION_CONFLICT,
2905 INDIRECT_STRUCTURAL_MATCH,
2906 POINTER_STRUCTURAL_MATCH,
2907 NONTRIVIAL_STRUCTURAL_MATCH,
2911 UNSAFE_OP_IN_UNSAFE_FN,
2913 CENUM_IMPL_DROP_CAST,
2914 CONST_EVALUATABLE_UNCHECKED,
2915 INEFFECTIVE_UNSTABLE_TRAIT_IMPL,
2917 FUNCTION_ITEM_REFERENCES,
2919 UNSUPPORTED_NAKED_FUNCTIONS,
2925 /// The `unused_doc_comments` lint detects doc comments that aren't used
2939 /// `rustdoc` does not use doc comments in all positions, and so the doc
2940 /// comment will be ignored. Try changing it to a normal comment with `//`
2941 /// to avoid the warning.
2942 pub UNUSED_DOC_COMMENTS,
2944 "detects doc comments that aren't used by rustdoc"
2947 declare_lint_pass!(UnusedDocComment => [UNUSED_DOC_COMMENTS]);
2950 /// The `missing_abi` lint detects cases where the ABI is omitted from
2951 /// extern declarations.
2955 /// ```rust,compile_fail
2956 /// #![deny(missing_abi)]
2958 /// extern fn foo() {}
2965 /// Historically, Rust implicitly selected C as the ABI for extern
2966 /// declarations. We expect to add new ABIs, like `C-unwind`, in the future,
2967 /// though this has not yet happened, and especially with their addition
2968 /// seeing the ABI easily will make code review easier.
2971 "No declared ABI for extern declaration"