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. When possible,
225 /// the compiler will attempt to detect situations where code can be
226 /// evaluated at compile-time to generate more efficient code. While
227 /// evaluating such code, if it detects that the code will unconditionally
228 /// panic, this usually indicates that it is doing something incorrectly.
229 /// If this lint is allowed, then the code will not be evaluated at
230 /// compile-time, and instead continue to generate code to evaluate at
231 /// runtime, which may panic during runtime.
232 pub UNCONDITIONAL_PANIC,
234 "operation will cause a panic at runtime"
238 /// The `const_err` lint detects an erroneous expression while doing
239 /// constant evaluation.
243 /// ```rust,compile_fail
244 /// #![allow(unconditional_panic)]
245 /// let x: &'static i32 = &(1 / 0);
252 /// This lint detects code that is very likely incorrect. If this lint is
253 /// allowed, then the code will not be evaluated at compile-time, and
254 /// instead continue to generate code to evaluate at runtime, which may
255 /// panic during runtime.
257 /// Note that this lint may trigger in either inside or outside of a
258 /// [const context]. Outside of a [const context], the compiler can
259 /// sometimes evaluate an expression at compile-time in order to generate
260 /// more efficient code. As the compiler becomes better at doing this, it
261 /// needs to decide what to do when it encounters code that it knows for
262 /// certain will panic or is otherwise incorrect. Making this a hard error
263 /// would prevent existing code that exhibited this behavior from
264 /// compiling, breaking backwards-compatibility. However, this is almost
265 /// certainly incorrect code, so this is a deny-by-default lint. For more
266 /// details, see [RFC 1229] and [issue #28238].
268 /// Note that there are several other more specific lints associated with
269 /// compile-time evaluation, such as [`arithmetic_overflow`],
270 /// [`unconditional_panic`].
272 /// [const context]: https://doc.rust-lang.org/reference/const_eval.html#const-context
273 /// [RFC 1229]: https://github.com/rust-lang/rfcs/blob/master/text/1229-compile-time-asserts.md
274 /// [issue #28238]: https://github.com/rust-lang/rust/issues/28238
275 /// [`arithmetic_overflow`]: deny-by-default.html#arithmetic-overflow
276 /// [`unconditional_panic`]: deny-by-default.html#unconditional-panic
279 "constant evaluation detected erroneous expression",
280 report_in_external_macro
284 /// The `unused_imports` lint detects imports that are never used.
289 /// use std::collections::HashMap;
296 /// Unused imports may signal a mistake or unfinished code, and clutter
297 /// the code, and should be removed. If you intended to re-export the item
298 /// to make it available outside of the module, add a visibility modifier
302 "imports that are never used"
306 /// The `unused_extern_crates` lint guards against `extern crate` items
307 /// that are never used.
311 /// ```rust,compile_fail
312 /// #![deny(unused_extern_crates)]
313 /// extern crate proc_macro;
320 /// `extern crate` items that are unused have no effect and should be
321 /// removed. Note that there are some cases where specifying an `extern
322 /// crate` is desired for the side effect of ensuring the given crate is
323 /// linked, even though it is not otherwise directly referenced. The lint
324 /// can be silenced by aliasing the crate to an underscore, such as
325 /// `extern crate foo as _`. Also note that it is no longer idiomatic to
326 /// use `extern crate` in the [2018 edition], as extern crates are now
327 /// automatically added in scope.
329 /// This lint is "allow" by default because it can be noisy, and produce
330 /// false-positives. If a dependency is being removed from a project, it
331 /// is recommended to remove it from the build configuration (such as
332 /// `Cargo.toml`) to ensure stale build entries aren't left behind.
334 /// [2018 edition]: https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html#no-more-extern-crate
335 pub UNUSED_EXTERN_CRATES,
337 "extern crates that are never used"
341 /// The `unused_crate_dependencies` lint detects crate dependencies that
346 /// ```rust,ignore (needs extern crate)
347 /// #![deny(unused_crate_dependencies)]
350 /// This will produce:
353 /// error: external crate `regex` unused in `lint_example`: remove the dependency or add `use regex as _;`
355 /// note: the lint level is defined here
356 /// --> src/lib.rs:1:9
358 /// 1 | #![deny(unused_crate_dependencies)]
359 /// | ^^^^^^^^^^^^^^^^^^^^^^^^^
364 /// After removing the code that uses a dependency, this usually also
365 /// requires removing the dependency from the build configuration.
366 /// However, sometimes that step can be missed, which leads to time wasted
367 /// building dependencies that are no longer used. This lint can be
368 /// enabled to detect dependencies that are never used (more specifically,
369 /// any dependency passed with the `--extern` command-line flag that is
370 /// never referenced via [`use`], [`extern crate`], or in any [path]).
372 /// This lint is "allow" by default because it can provide false positives
373 /// depending on how the build system is configured. For example, when
374 /// using Cargo, a "package" consists of multiple crates (such as a
375 /// library and a binary), but the dependencies are defined for the
376 /// package as a whole. If there is a dependency that is only used in the
377 /// binary, but not the library, then the lint will be incorrectly issued
380 /// [path]: https://doc.rust-lang.org/reference/paths.html
381 /// [`use`]: https://doc.rust-lang.org/reference/items/use-declarations.html
382 /// [`extern crate`]: https://doc.rust-lang.org/reference/items/extern-crates.html
383 pub UNUSED_CRATE_DEPENDENCIES,
385 "crate dependencies that are never used",
390 /// The `unused_qualifications` lint detects unnecessarily qualified
395 /// ```rust,compile_fail
396 /// #![deny(unused_qualifications)]
411 /// If an item from another module is already brought into scope, then
412 /// there is no need to qualify it in this case. You can call `bar()`
413 /// directly, without the `foo::`.
415 /// This lint is "allow" by default because it is somewhat pedantic, and
416 /// doesn't indicate an actual problem, but rather a stylistic choice, and
417 /// can be noisy when refactoring or moving around code.
418 pub UNUSED_QUALIFICATIONS,
420 "detects unnecessarily qualified names"
424 /// The `unknown_lints` lint detects unrecognized lint attribute.
429 /// #![allow(not_a_real_lint)]
436 /// It is usually a mistake to specify a lint that does not exist. Check
437 /// the spelling, and check the lint listing for the correct name. Also
438 /// consider if you are using an old version of the compiler, and the lint
439 /// is only available in a newer version.
442 "unrecognized lint attribute"
446 /// The `unused_variables` lint detects variables which are not used in
459 /// Unused variables may signal a mistake or unfinished code. To silence
460 /// the warning for the individual variable, prefix it with an underscore
462 pub UNUSED_VARIABLES,
464 "detect variables which are not used in any way"
468 /// The `unused_assignments` lint detects assignments that will never be read.
481 /// Unused assignments may signal a mistake or unfinished code. If the
482 /// variable is never used after being assigned, then the assignment can
483 /// be removed. Variables with an underscore prefix such as `_x` will not
484 /// trigger this lint.
485 pub UNUSED_ASSIGNMENTS,
487 "detect assignments that will never be read"
491 /// The `dead_code` lint detects unused, unexported items.
503 /// Dead code may signal a mistake or unfinished code. To silence the
504 /// warning for individual items, prefix the name with an underscore such
505 /// as `_foo`. If it was intended to expose the item outside of the crate,
506 /// consider adding a visibility modifier like `pub`. Otherwise consider
507 /// removing the unused code.
510 "detect unused, unexported items"
514 /// The `unused_attributes` lint detects attributes that were not used by
527 /// Unused [attributes] may indicate the attribute is placed in the wrong
528 /// position. Consider removing it, or placing it in the correct position.
529 /// Also consider if you intended to use an _inner attribute_ (with a `!`
530 /// such as `#![allow(unused)]`) which applies to the item the attribute
531 /// is within, or an _outer attribute_ (without a `!` such as
532 /// `#[allow(unsued)]`) which applies to the item *following* the
535 /// [attributes]: https://doc.rust-lang.org/reference/attributes.html
536 pub UNUSED_ATTRIBUTES,
538 "detects attributes that were not used by the compiler"
542 /// The `unreachable_code` lint detects unreachable code paths.
547 /// panic!("we never go past here!");
556 /// Unreachable code may signal a mistake or unfinished code. If the code
557 /// is no longer in use, consider removing it.
558 pub UNREACHABLE_CODE,
560 "detects unreachable code paths",
561 report_in_external_macro
565 /// The `unreachable_patterns` lint detects unreachable patterns.
581 /// This usually indicates a mistake in how the patterns are specified or
582 /// ordered. In this example, the `y` pattern will always match, so the
583 /// five is impossible to reach. Remember, match arms match in order, you
584 /// probably wanted to put the `5` case above the `y` case.
585 pub UNREACHABLE_PATTERNS,
587 "detects unreachable patterns"
591 /// The `overlapping_patterns` lint detects `match` arms that have
592 /// [range patterns] that overlap.
594 /// [range patterns]: https://doc.rust-lang.org/nightly/reference/patterns.html#range-patterns
601 /// 0..=100 => { println!("small"); }
602 /// 100..=255 => { println!("large"); }
610 /// It is likely a mistake to have range patterns in a match expression
611 /// that overlap. Check that the beginning and end values are what you
612 /// expect, and keep in mind that with `..=` the left and right bounds are
614 pub OVERLAPPING_PATTERNS,
616 "detects overlapping patterns"
620 /// The `bindings_with_variant_name` lint detects pattern bindings with
621 /// the same name as one of the matched variants.
631 /// pub fn foo(x: Enum) {
643 /// It is usually a mistake to specify an enum variant name as an
644 /// [identifier pattern]. In the example above, the `match` arms are
645 /// specifying a variable name to bind the value of `x` to. The second arm
646 /// is ignored because the first one matches *all* values. The likely
647 /// intent is that the arm was intended to match on the enum variant.
649 /// Two possible solutions are:
651 /// * Specify the enum variant using a [path pattern], such as
653 /// * Bring the enum variants into local scope, such as adding `use
654 /// Enum::*;` to the beginning of the `foo` function in the example
657 /// [identifier pattern]: https://doc.rust-lang.org/reference/patterns.html#identifier-patterns
658 /// [path pattern]: https://doc.rust-lang.org/reference/patterns.html#path-patterns
659 pub BINDINGS_WITH_VARIANT_NAME,
661 "detects pattern bindings with the same name as one of the matched variants"
665 /// The `unused_macros` lint detects macros that were not used.
670 /// macro_rules! unused {
682 /// Unused macros may signal a mistake or unfinished code. To silence the
683 /// warning for the individual macro, prefix the name with an underscore
684 /// such as `_my_macro`. If you intended to export the macro to make it
685 /// available outside of the crate, use the [`macro_export` attribute].
687 /// [`macro_export` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
690 "detects macros that were not used"
694 /// The `warnings` lint allows you to change the level of other
695 /// lints which produce warnings.
700 /// #![deny(warnings)]
708 /// The `warnings` lint is a bit special; by changing its level, you
709 /// change every other warning that would produce a warning to whatever
710 /// value you'd like. As such, you won't ever trigger this lint in your
714 "mass-change the level for lints which produce warnings"
718 /// The `unused_features` lint detects unused or unknown features found in
719 /// crate-level [`feature` attributes].
721 /// [`feature` attributes]: https://doc.rust-lang.org/nightly/unstable-book/
723 /// Note: This lint is currently not functional, see [issue #44232] for
726 /// [issue #44232]: https://github.com/rust-lang/rust/issues/44232
729 "unused features found in crate-level `#[feature]` directives"
733 /// The `stable_features` lint detects a [`feature` attribute] that
734 /// has since been made stable.
736 /// [`feature` attribute]: https://doc.rust-lang.org/nightly/unstable-book/
741 /// #![feature(test_accepted_feature)]
749 /// When a feature is stabilized, it is no longer necessary to include a
750 /// `#![feature]` attribute for it. To fix, simply remove the
751 /// `#![feature]` attribute.
754 "stable features found in `#[feature]` directive"
758 /// The `unknown_crate_types` lint detects an unknown crate type found in
759 /// a [`crate_type` attribute].
763 /// ```rust,compile_fail
764 /// #![crate_type="lol"]
772 /// An unknown value give to the `crate_type` attribute is almost
773 /// certainly a mistake.
775 /// [`crate_type` attribute]: https://doc.rust-lang.org/reference/linkage.html
776 pub UNKNOWN_CRATE_TYPES,
778 "unknown crate type found in `#[crate_type]` directive",
783 /// The `trivial_casts` lint detects trivial casts which could be replaced
784 /// with coercion, which may require [type ascription] or a temporary
789 /// ```rust,compile_fail
790 /// #![deny(trivial_casts)]
791 /// let x: &u32 = &42;
792 /// let y = x as *const u32;
799 /// A trivial cast is a cast `e as T` where `e` has type `U` and `U` is a
800 /// subtype of `T`. This type of cast is usually unnecessary, as it can be
801 /// usually be inferred.
803 /// This lint is "allow" by default because there are situations, such as
804 /// with FFI interfaces or complex type aliases, where it triggers
805 /// incorrectly, or in situations where it will be more difficult to
806 /// clearly express the intent. It may be possible that this will become a
807 /// warning in the future, possibly with [type ascription] providing a
808 /// convenient way to work around the current issues. See [RFC 401] for
809 /// historical context.
811 /// [type ascription]: https://github.com/rust-lang/rust/issues/23416
812 /// [RFC 401]: https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md
815 "detects trivial casts which could be removed"
819 /// The `trivial_numeric_casts` lint detects trivial numeric casts of types
820 /// which could be removed.
824 /// ```rust,compile_fail
825 /// #![deny(trivial_numeric_casts)]
826 /// let x = 42_i32 as i32;
833 /// A trivial numeric cast is a cast of a numeric type to the same numeric
834 /// type. This type of cast is usually unnecessary.
836 /// This lint is "allow" by default because there are situations, such as
837 /// with FFI interfaces or complex type aliases, where it triggers
838 /// incorrectly, or in situations where it will be more difficult to
839 /// clearly express the intent. It may be possible that this will become a
840 /// warning in the future, possibly with [type ascription] providing a
841 /// convenient way to work around the current issues. See [RFC 401] for
842 /// historical context.
844 /// [type ascription]: https://github.com/rust-lang/rust/issues/23416
845 /// [RFC 401]: https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md
846 pub TRIVIAL_NUMERIC_CASTS,
848 "detects trivial casts of numeric types which could be removed"
852 /// The `private_in_public` lint detects private items in public
853 /// interfaces not caught by the old implementation.
858 /// # #![allow(unused)]
863 /// impl super::SemiPriv {
864 /// pub fn f(_: Priv) {}
874 /// The visibility rules are intended to prevent exposing private items in
875 /// public interfaces. This is a [future-incompatible] lint to transition
876 /// this to a hard error in the future. See [issue #34537] for more
879 /// [issue #34537]: https://github.com/rust-lang/rust/issues/34537
880 /// [future-incompatible]: ../index.md#future-incompatible-lints
881 pub PRIVATE_IN_PUBLIC,
883 "detect private items in public interfaces not caught by the old implementation",
884 @future_incompatible = FutureIncompatibleInfo {
885 reference: "issue #34537 <https://github.com/rust-lang/rust/issues/34537>",
891 /// The `exported_private_dependencies` lint detects private dependencies
892 /// that are exposed in a public interface.
896 /// ```rust,ignore (needs-dependency)
897 /// pub fn foo() -> Option<some_private_dependency::Thing> {
902 /// This will produce:
905 /// warning: type `bar::Thing` from private dependency 'bar' in public interface
906 /// --> src/lib.rs:3:1
908 /// 3 | pub fn foo() -> Option<bar::Thing> {
909 /// | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
911 /// = note: `#[warn(exported_private_dependencies)]` on by default
916 /// Dependencies can be marked as "private" to indicate that they are not
917 /// exposed in the public interface of a crate. This can be used by Cargo
918 /// to independently resolve those dependencies because it can assume it
919 /// does not need to unify them with other packages using that same
920 /// dependency. This lint is an indication of a violation of that
923 /// To fix this, avoid exposing the dependency in your public interface.
924 /// Or, switch the dependency to a public dependency.
926 /// Note that support for this is only available on the nightly channel.
927 /// See [RFC 1977] for more details, as well as the [Cargo documentation].
929 /// [RFC 1977]: https://github.com/rust-lang/rfcs/blob/master/text/1977-public-private-dependencies.md
930 /// [Cargo documentation]: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#public-dependency
931 pub EXPORTED_PRIVATE_DEPENDENCIES,
933 "public interface leaks type from a private dependency"
937 /// The `pub_use_of_private_extern_crate` lint detects a specific
938 /// situation of re-exporting a private `extern crate`.
942 /// ```rust,compile_fail
943 /// extern crate core;
944 /// pub use core as reexported_core;
951 /// A public `use` declaration should not be used to publicly re-export a
952 /// private `extern crate`. `pub extern crate` should be used instead.
954 /// This was historically allowed, but is not the intended behavior
955 /// according to the visibility rules. This is a [future-incompatible]
956 /// lint to transition this to a hard error in the future. See [issue
957 /// #34537] for more details.
959 /// [issue #34537]: https://github.com/rust-lang/rust/issues/34537
960 /// [future-incompatible]: ../index.md#future-incompatible-lints
961 pub PUB_USE_OF_PRIVATE_EXTERN_CRATE,
963 "detect public re-exports of private extern crates",
964 @future_incompatible = FutureIncompatibleInfo {
965 reference: "issue #34537 <https://github.com/rust-lang/rust/issues/34537>",
971 /// The `invalid_type_param_default` lint detects type parameter defaults
972 /// erroneously allowed in an invalid location.
976 /// ```rust,compile_fail
977 /// fn foo<T=i32>(t: T) {}
984 /// Default type parameters were only intended to be allowed in certain
985 /// situations, but historically the compiler allowed them everywhere.
986 /// This is a [future-incompatible] lint to transition this to a hard
987 /// error in the future. See [issue #36887] for more details.
989 /// [issue #36887]: https://github.com/rust-lang/rust/issues/36887
990 /// [future-incompatible]: ../index.md#future-incompatible-lints
991 pub INVALID_TYPE_PARAM_DEFAULT,
993 "type parameter default erroneously allowed in invalid location",
994 @future_incompatible = FutureIncompatibleInfo {
995 reference: "issue #36887 <https://github.com/rust-lang/rust/issues/36887>",
1001 /// The `renamed_and_removed_lints` lint detects lints that have been
1002 /// renamed or removed.
1007 /// #![deny(raw_pointer_derive)]
1014 /// To fix this, either remove the lint or use the new name. This can help
1015 /// avoid confusion about lints that are no longer valid, and help
1016 /// maintain consistency for renamed lints.
1017 pub RENAMED_AND_REMOVED_LINTS,
1019 "lints that have been renamed or removed"
1023 /// The `unaligned_references` lint detects unaligned references to fields
1024 /// of [packed] structs.
1026 /// [packed]: https://doc.rust-lang.org/reference/type-layout.html#the-alignment-modifiers
1030 /// ```rust,compile_fail
1031 /// #![deny(unaligned_references)]
1034 /// pub struct Foo {
1041 /// let foo = Foo { field1: 0, field2: 0 };
1042 /// let _ = &foo.field1;
1051 /// Creating a reference to an insufficiently aligned packed field is
1052 /// [undefined behavior] and should be disallowed.
1054 /// This lint is "allow" by default because there is no stable
1055 /// alternative, and it is not yet certain how widespread existing code
1056 /// will trigger this lint.
1058 /// See [issue #27060] for more discussion.
1060 /// [undefined behavior]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html
1061 /// [issue #27060]: https://github.com/rust-lang/rust/issues/27060
1062 pub UNALIGNED_REFERENCES,
1064 "detects unaligned references to fields of packed structs",
1068 /// The `const_item_mutation` lint detects attempts to mutate a `const`
1074 /// const FOO: [i32; 1] = [0];
1078 /// // This will print "[0]".
1079 /// println!("{:?}", FOO);
1087 /// Trying to directly mutate a `const` item is almost always a mistake.
1088 /// What is happening in the example above is that a temporary copy of the
1089 /// `const` is mutated, but the original `const` is not. Each time you
1090 /// refer to the `const` by name (such as `FOO` in the example above), a
1091 /// separate copy of the value is inlined at that location.
1093 /// This lint checks for writing directly to a field (`FOO.field =
1094 /// some_value`) or array entry (`FOO[0] = val`), or taking a mutable
1095 /// reference to the const item (`&mut FOO`), including through an
1096 /// autoderef (`FOO.some_mut_self_method()`).
1098 /// There are various alternatives depending on what you are trying to
1101 /// * First, always reconsider using mutable globals, as they can be
1102 /// difficult to use correctly, and can make the code more difficult to
1103 /// use or understand.
1104 /// * If you are trying to perform a one-time initialization of a global:
1105 /// * If the value can be computed at compile-time, consider using
1106 /// const-compatible values (see [Constant Evaluation]).
1107 /// * For more complex single-initialization cases, consider using a
1108 /// third-party crate, such as [`lazy_static`] or [`once_cell`].
1109 /// * If you are using the [nightly channel], consider the new
1110 /// [`lazy`] module in the standard library.
1111 /// * If you truly need a mutable global, consider using a [`static`],
1112 /// which has a variety of options:
1113 /// * Simple data types can be directly defined and mutated with an
1114 /// [`atomic`] type.
1115 /// * More complex types can be placed in a synchronization primitive
1116 /// like a [`Mutex`], which can be initialized with one of the options
1118 /// * A [mutable `static`] is a low-level primitive, requiring unsafe.
1119 /// Typically This should be avoided in preference of something
1120 /// higher-level like one of the above.
1122 /// [Constant Evaluation]: https://doc.rust-lang.org/reference/const_eval.html
1123 /// [`static`]: https://doc.rust-lang.org/reference/items/static-items.html
1124 /// [mutable `static`]: https://doc.rust-lang.org/reference/items/static-items.html#mutable-statics
1125 /// [`lazy`]: https://doc.rust-lang.org/nightly/std/lazy/index.html
1126 /// [`lazy_static`]: https://crates.io/crates/lazy_static
1127 /// [`once_cell`]: https://crates.io/crates/once_cell
1128 /// [`atomic`]: https://doc.rust-lang.org/std/sync/atomic/index.html
1129 /// [`Mutex`]: https://doc.rust-lang.org/std/sync/struct.Mutex.html
1130 pub CONST_ITEM_MUTATION,
1132 "detects attempts to mutate a `const` item",
1136 /// The `safe_packed_borrows` lint detects borrowing a field in the
1137 /// interior of a packed structure with alignment other than 1.
1143 /// pub struct Unaligned<T>(pub T);
1145 /// pub struct Foo {
1147 /// data: Unaligned<u32>,
1151 /// let x = Foo { start: 0, data: Unaligned(1) };
1152 /// let y = &x.data.0;
1160 /// This type of borrow is unsafe and can cause errors on some platforms
1161 /// and violates some assumptions made by the compiler. This was
1162 /// previously allowed unintentionally. This is a [future-incompatible]
1163 /// lint to transition this to a hard error in the future. See [issue
1164 /// #46043] for more details, including guidance on how to solve the
1167 /// [issue #46043]: https://github.com/rust-lang/rust/issues/46043
1168 /// [future-incompatible]: ../index.md#future-incompatible-lints
1169 pub SAFE_PACKED_BORROWS,
1171 "safe borrows of fields of packed structs were erroneously allowed",
1172 @future_incompatible = FutureIncompatibleInfo {
1173 reference: "issue #46043 <https://github.com/rust-lang/rust/issues/46043>",
1179 /// The `patterns_in_fns_without_body` lint detects `mut` identifier
1180 /// patterns as a parameter in functions without a body.
1184 /// ```rust,compile_fail
1186 /// fn foo(mut arg: u8);
1194 /// To fix this, remove `mut` from the parameter in the trait definition;
1195 /// it can be used in the implementation. That is, the following is OK:
1199 /// fn foo(arg: u8); // Removed `mut` here
1202 /// impl Trait for i32 {
1203 /// fn foo(mut arg: u8) { // `mut` here is OK
1209 /// Trait definitions can define functions without a body to specify a
1210 /// function that implementors must define. The parameter names in the
1211 /// body-less functions are only allowed to be `_` or an [identifier] for
1212 /// documentation purposes (only the type is relevant). Previous versions
1213 /// of the compiler erroneously allowed [identifier patterns] with the
1214 /// `mut` keyword, but this was not intended to be allowed. This is a
1215 /// [future-incompatible] lint to transition this to a hard error in the
1216 /// future. See [issue #35203] for more details.
1218 /// [identifier]: https://doc.rust-lang.org/reference/identifiers.html
1219 /// [identifier patterns]: https://doc.rust-lang.org/reference/patterns.html#identifier-patterns
1220 /// [issue #35203]: https://github.com/rust-lang/rust/issues/35203
1221 /// [future-incompatible]: ../index.md#future-incompatible-lints
1222 pub PATTERNS_IN_FNS_WITHOUT_BODY,
1224 "patterns in functions without body were erroneously allowed",
1225 @future_incompatible = FutureIncompatibleInfo {
1226 reference: "issue #35203 <https://github.com/rust-lang/rust/issues/35203>",
1232 /// The `late_bound_lifetime_arguments` lint detects generic lifetime
1233 /// arguments in path segments with late bound lifetime parameters.
1241 /// fn late<'a, 'b>(self, _: &'a u8, _: &'b u8) {}
1245 /// S.late::<'static>(&0, &0);
1253 /// It is not clear how to provide arguments for early-bound lifetime
1254 /// parameters if they are intermixed with late-bound parameters in the
1255 /// same list. For now, providing any explicit arguments will trigger this
1256 /// lint if late-bound parameters are present, so in the future a solution
1257 /// can be adopted without hitting backward compatibility issues. This is
1258 /// a [future-incompatible] lint to transition this to a hard error in the
1259 /// future. See [issue #42868] for more details, along with a description
1260 /// of the difference between early and late-bound parameters.
1262 /// [issue #42868]: https://github.com/rust-lang/rust/issues/42868
1263 /// [future-incompatible]: ../index.md#future-incompatible-lints
1264 pub LATE_BOUND_LIFETIME_ARGUMENTS,
1266 "detects generic lifetime arguments in path segments with late bound lifetime parameters",
1267 @future_incompatible = FutureIncompatibleInfo {
1268 reference: "issue #42868 <https://github.com/rust-lang/rust/issues/42868>",
1274 /// The `order_dependent_trait_objects` lint detects a trait coherency
1275 /// violation that would allow creating two trait impls for the same
1276 /// dynamic trait object involving marker traits.
1280 /// ```rust,compile_fail
1281 /// pub trait Trait {}
1283 /// impl Trait for dyn Send + Sync { }
1284 /// impl Trait for dyn Sync + Send { }
1291 /// A previous bug caused the compiler to interpret traits with different
1292 /// orders (such as `Send + Sync` and `Sync + Send`) as distinct types
1293 /// when they were intended to be treated the same. This allowed code to
1294 /// define separate trait implementations when there should be a coherence
1295 /// error. This is a [future-incompatible] lint to transition this to a
1296 /// hard error in the future. See [issue #56484] for more details.
1298 /// [issue #56484]: https://github.com/rust-lang/rust/issues/56484
1299 /// [future-incompatible]: ../index.md#future-incompatible-lints
1300 pub ORDER_DEPENDENT_TRAIT_OBJECTS,
1302 "trait-object types were treated as different depending on marker-trait order",
1303 @future_incompatible = FutureIncompatibleInfo {
1304 reference: "issue #56484 <https://github.com/rust-lang/rust/issues/56484>",
1310 /// The `coherence_leak_check` lint detects conflicting implementations of
1311 /// a trait that are only distinguished by the old leak-check code.
1316 /// trait SomeTrait { }
1317 /// impl SomeTrait for for<'a> fn(&'a u8) { }
1318 /// impl<'a> SomeTrait for fn(&'a u8) { }
1325 /// In the past, the compiler would accept trait implementations for
1326 /// identical functions that differed only in where the lifetime binder
1327 /// appeared. Due to a change in the borrow checker implementation to fix
1328 /// several bugs, this is no longer allowed. However, since this affects
1329 /// existing code, this is a [future-incompatible] lint to transition this
1330 /// to a hard error in the future.
1332 /// Code relying on this pattern should introduce "[newtypes]",
1333 /// like `struct Foo(for<'a> fn(&'a u8))`.
1335 /// See [issue #56105] for more details.
1337 /// [issue #56105]: https://github.com/rust-lang/rust/issues/56105
1338 /// [newtypes]: https://doc.rust-lang.org/book/ch19-04-advanced-types.html#using-the-newtype-pattern-for-type-safety-and-abstraction
1339 /// [future-incompatible]: ../index.md#future-incompatible-lints
1340 pub COHERENCE_LEAK_CHECK,
1342 "distinct impls distinguished only by the leak-check code",
1343 @future_incompatible = FutureIncompatibleInfo {
1344 reference: "issue #56105 <https://github.com/rust-lang/rust/issues/56105>",
1350 /// The `deprecated` lint detects use of deprecated items.
1367 /// Items may be marked "deprecated" with the [`deprecated` attribute] to
1368 /// indicate that they should no longer be used. Usually the attribute
1369 /// should include a note on what to use instead, or check the
1372 /// [`deprecated` attribute]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute
1375 "detects use of deprecated items",
1376 report_in_external_macro
1380 /// The `unused_unsafe` lint detects unnecessary use of an `unsafe` block.
1392 /// If nothing within the block requires `unsafe`, then remove the
1393 /// `unsafe` marker because it is not required and may cause confusion.
1396 "unnecessary use of an `unsafe` block"
1400 /// The `unused_mut` lint detects mut variables which don't need to be
1413 /// The preferred style is to only mark variables as `mut` if it is
1417 "detect mut variables which don't need to be mutable"
1421 /// The `unconditional_recursion` lint detects functions that cannot
1422 /// return without calling themselves.
1436 /// It is usually a mistake to have a recursive call that does not have
1437 /// some condition to cause it to terminate. If you really intend to have
1438 /// an infinite loop, using a `loop` expression is recommended.
1439 pub UNCONDITIONAL_RECURSION,
1441 "functions that cannot return without calling themselves"
1445 /// The `single_use_lifetimes` lint detects lifetimes that are only used
1450 /// ```rust,compile_fail
1451 /// #![deny(single_use_lifetimes)]
1453 /// fn foo<'a>(x: &'a u32) {}
1460 /// Specifying an explicit lifetime like `'a` in a function or `impl`
1461 /// should only be used to link together two things. Otherwise, you should
1462 /// just use `'_` to indicate that the lifetime is not linked to anything,
1463 /// or elide the lifetime altogether if possible.
1465 /// This lint is "allow" by default because it was introduced at a time
1466 /// when `'_` and elided lifetimes were first being introduced, and this
1467 /// lint would be too noisy. Also, there are some known false positives
1468 /// that it produces. See [RFC 2115] for historical context, and [issue
1469 /// #44752] for more details.
1471 /// [RFC 2115]: https://github.com/rust-lang/rfcs/blob/master/text/2115-argument-lifetimes.md
1472 /// [issue #44752]: https://github.com/rust-lang/rust/issues/44752
1473 pub SINGLE_USE_LIFETIMES,
1475 "detects lifetime parameters that are only used once"
1479 /// The `unused_lifetimes` lint detects lifetime parameters that are never
1484 /// ```rust,compile_fail
1485 /// #[deny(unused_lifetimes)]
1487 /// pub fn foo<'a>() {}
1494 /// Unused lifetime parameters may signal a mistake or unfinished code.
1495 /// Consider removing the parameter.
1496 pub UNUSED_LIFETIMES,
1498 "detects lifetime parameters that are never used"
1502 /// The `tyvar_behind_raw_pointer` lint detects raw pointer to an
1503 /// inference variable.
1507 /// ```rust,edition2015
1509 /// let data = std::ptr::null();
1510 /// let _ = &data as *const *const ();
1512 /// if data.is_null() {}
1519 /// This kind of inference was previously allowed, but with the future
1520 /// arrival of [arbitrary self types], this can introduce ambiguity. To
1521 /// resolve this, use an explicit type instead of relying on type
1524 /// This is a [future-incompatible] lint to transition this to a hard
1525 /// error in the 2018 edition. See [issue #46906] for more details. This
1526 /// is currently a hard-error on the 2018 edition, and is "warn" by
1527 /// default in the 2015 edition.
1529 /// [arbitrary self types]: https://github.com/rust-lang/rust/issues/44874
1530 /// [issue #46906]: https://github.com/rust-lang/rust/issues/46906
1531 /// [future-incompatible]: ../index.md#future-incompatible-lints
1532 pub TYVAR_BEHIND_RAW_POINTER,
1534 "raw pointer to an inference variable",
1535 @future_incompatible = FutureIncompatibleInfo {
1536 reference: "issue #46906 <https://github.com/rust-lang/rust/issues/46906>",
1537 edition: Some(Edition::Edition2018),
1542 /// The `elided_lifetimes_in_paths` lint detects the use of hidden
1543 /// lifetime parameters.
1547 /// ```rust,compile_fail
1548 /// #![deny(elided_lifetimes_in_paths)]
1549 /// struct Foo<'a> {
1553 /// fn foo(x: &Foo) {
1561 /// Elided lifetime parameters can make it difficult to see at a glance
1562 /// that borrowing is occurring. This lint ensures that lifetime
1563 /// parameters are always explicitly stated, even if it is the `'_`
1564 /// [placeholder lifetime].
1566 /// This lint is "allow" by default because it has some known issues, and
1567 /// may require a significant transition for old code.
1569 /// [placeholder lifetime]: https://doc.rust-lang.org/reference/lifetime-elision.html#lifetime-elision-in-functions
1570 pub ELIDED_LIFETIMES_IN_PATHS,
1572 "hidden lifetime parameters in types are deprecated",
1577 /// The `bare_trait_objects` lint suggests using `dyn Trait` for trait
1585 /// fn takes_trait_object(_: Box<Trait>) {
1593 /// Without the `dyn` indicator, it can be ambiguous or confusing when
1594 /// reading code as to whether or not you are looking at a trait object.
1595 /// The `dyn` keyword makes it explicit, and adds a symmetry to contrast
1596 /// with [`impl Trait`].
1598 /// [`impl Trait`]: https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
1599 pub BARE_TRAIT_OBJECTS,
1601 "suggest using `dyn Trait` for trait objects"
1605 /// The `absolute_paths_not_starting_with_crate` lint detects fully
1606 /// qualified paths that start with a module name instead of `crate`,
1607 /// `self`, or an extern crate name
1611 /// ```rust,edition2015,compile_fail
1612 /// #![deny(absolute_paths_not_starting_with_crate)]
1627 /// Rust [editions] allow the language to evolve without breaking
1628 /// backwards compatibility. This lint catches code that uses absolute
1629 /// paths in the style of the 2015 edition. In the 2015 edition, absolute
1630 /// paths (those starting with `::`) refer to either the crate root or an
1631 /// external crate. In the 2018 edition it was changed so that they only
1632 /// refer to external crates. The path prefix `crate::` should be used
1633 /// instead to reference items from the crate root.
1635 /// If you switch the compiler from the 2015 to 2018 edition without
1636 /// updating the code, then it will fail to compile if the old style paths
1637 /// are used. You can manually change the paths to use the `crate::`
1638 /// prefix to transition to the 2018 edition.
1640 /// This lint solves the problem automatically. It is "allow" by default
1641 /// because the code is perfectly valid in the 2015 edition. The [`cargo
1642 /// fix`] tool with the `--edition` flag will switch this lint to "warn"
1643 /// and automatically apply the suggested fix from the compiler. This
1644 /// provides a completely automated way to update old code to the 2018
1647 /// [editions]: https://doc.rust-lang.org/edition-guide/
1648 /// [`cargo fix`]: https://doc.rust-lang.org/cargo/commands/cargo-fix.html
1649 pub ABSOLUTE_PATHS_NOT_STARTING_WITH_CRATE,
1651 "fully qualified paths that start with a module name \
1652 instead of `crate`, `self`, or an extern crate name",
1653 @future_incompatible = FutureIncompatibleInfo {
1654 reference: "issue #53130 <https://github.com/rust-lang/rust/issues/53130>",
1655 edition: Some(Edition::Edition2018),
1660 /// The `illegal_floating_point_literal_pattern` lint detects
1661 /// floating-point literals used in patterns.
1678 /// Previous versions of the compiler accepted floating-point literals in
1679 /// patterns, but it was later determined this was a mistake. The
1680 /// semantics of comparing floating-point values may not be clear in a
1681 /// pattern when contrasted with "structural equality". Typically you can
1682 /// work around this by using a [match guard], such as:
1688 /// y if y == 5.0 => {}
1693 /// This is a [future-incompatible] lint to transition this to a hard
1694 /// error in the future. See [issue #41620] for more details.
1696 /// [issue #41620]: https://github.com/rust-lang/rust/issues/41620
1697 /// [match guard]: https://doc.rust-lang.org/reference/expressions/match-expr.html#match-guards
1698 /// [future-incompatible]: ../index.md#future-incompatible-lints
1699 pub ILLEGAL_FLOATING_POINT_LITERAL_PATTERN,
1701 "floating-point literals cannot be used in patterns",
1702 @future_incompatible = FutureIncompatibleInfo {
1703 reference: "issue #41620 <https://github.com/rust-lang/rust/issues/41620>",
1709 /// The `unstable_name_collisions` lint detects that you have used a name
1710 /// that the standard library plans to add in the future.
1715 /// trait MyIterator : Iterator {
1716 /// // is_sorted is an unstable method that already exists on the Iterator trait
1717 /// fn is_sorted(self) -> bool where Self: Sized {true}
1720 /// impl<T: ?Sized> MyIterator for T where T: Iterator { }
1722 /// let x = vec![1,2,3];
1723 /// let _ = x.iter().is_sorted();
1730 /// When new methods are added to traits in the standard library, they are
1731 /// usually added in an "unstable" form which is only available on the
1732 /// [nightly channel] with a [`feature` attribute]. If there is any
1733 /// pre-existing code which extends a trait to have a method with the same
1734 /// name, then the names will collide. In the future, when the method is
1735 /// stabilized, this will cause an error due to the ambiguity. This lint
1736 /// is an early-warning to let you know that there may be a collision in
1737 /// the future. This can be avoided by adding type annotations to
1738 /// disambiguate which trait method you intend to call, such as
1739 /// `MyIterator::is_sorted(my_iter)` or renaming or removing the method.
1741 /// [nightly channel]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
1742 /// [`feature` attribute]: https://doc.rust-lang.org/nightly/unstable-book/
1743 pub UNSTABLE_NAME_COLLISIONS,
1745 "detects name collision with an existing but unstable method",
1746 @future_incompatible = FutureIncompatibleInfo {
1747 reference: "issue #48919 <https://github.com/rust-lang/rust/issues/48919>",
1749 // Note: this item represents future incompatibility of all unstable functions in the
1750 // standard library, and thus should never be removed or changed to an error.
1755 /// The `irrefutable_let_patterns` lint detects detects [irrefutable
1756 /// patterns] in [if-let] and [while-let] statements.
1763 /// if let _ = 123 {
1764 /// println!("always runs!");
1772 /// There usually isn't a reason to have an irrefutable pattern in an
1773 /// if-let or while-let statement, because the pattern will always match
1774 /// successfully. A [`let`] or [`loop`] statement will suffice. However,
1775 /// when generating code with a macro, forbidding irrefutable patterns
1776 /// would require awkward workarounds in situations where the macro
1777 /// doesn't know if the pattern is refutable or not. This lint allows
1778 /// macros to accept this form, while alerting for a possibly incorrect
1779 /// use in normal code.
1781 /// See [RFC 2086] for more details.
1783 /// [irrefutable patterns]: https://doc.rust-lang.org/reference/patterns.html#refutability
1784 /// [if-let]: https://doc.rust-lang.org/reference/expressions/if-expr.html#if-let-expressions
1785 /// [while-let]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#predicate-pattern-loops
1786 /// [`let`]: https://doc.rust-lang.org/reference/statements.html#let-statements
1787 /// [`loop`]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#infinite-loops
1788 /// [RFC 2086]: https://github.com/rust-lang/rfcs/blob/master/text/2086-allow-if-let-irrefutables.md
1789 pub IRREFUTABLE_LET_PATTERNS,
1791 "detects irrefutable patterns in if-let and while-let statements"
1795 /// The `unused_labels` lint detects [labels] that are never used.
1797 /// [labels]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#loop-labels
1802 /// 'unused_label: loop {}
1809 /// Unused labels may signal a mistake or unfinished code. To silence the
1810 /// warning for the individual label, prefix it with an underscore such as
1814 "detects labels that are never used"
1818 /// The `broken_intra_doc_links` lint detects failures in resolving
1819 /// intra-doc link targets. This is a `rustdoc` only lint, see the
1820 /// documentation in the [rustdoc book].
1822 /// [rustdoc book]: ../../../rustdoc/lints.html#broken_intra_doc_links
1823 pub BROKEN_INTRA_DOC_LINKS,
1825 "failures in resolving intra-doc link targets"
1829 /// This is a subset of `broken_intra_doc_links` that warns when linking from
1830 /// a public item to a private one. This is a `rustdoc` only lint, see the
1831 /// documentation in the [rustdoc book].
1833 /// [rustdoc book]: ../../../rustdoc/lints.html#private_intra_doc_links
1834 pub PRIVATE_INTRA_DOC_LINKS,
1836 "linking from a public item to a private one"
1840 /// The `invalid_codeblock_attributes` lint detects code block attributes
1841 /// in documentation examples that have potentially mis-typed values. This
1842 /// is a `rustdoc` only lint, see the documentation in the [rustdoc book].
1844 /// [rustdoc book]: ../../../rustdoc/lints.html#invalid_codeblock_attributes
1845 pub INVALID_CODEBLOCK_ATTRIBUTES,
1847 "codeblock attribute looks a lot like a known one"
1851 /// The `missing_crate_level_docs` lint detects if documentation is
1852 /// missing at the crate root. This is a `rustdoc` only lint, see the
1853 /// documentation in the [rustdoc book].
1855 /// [rustdoc book]: ../../../rustdoc/lints.html#missing_crate_level_docs
1856 pub MISSING_CRATE_LEVEL_DOCS,
1858 "detects crates with no crate-level documentation"
1862 /// The `missing_doc_code_examples` lint detects publicly-exported items
1863 /// without code samples in their documentation. This is a `rustdoc` only
1864 /// lint, see the documentation in the [rustdoc book].
1866 /// [rustdoc book]: ../../../rustdoc/lints.html#missing_doc_code_examples
1867 pub MISSING_DOC_CODE_EXAMPLES,
1869 "detects publicly-exported items without code samples in their documentation"
1873 /// The `private_doc_tests` lint detects code samples in docs of private
1874 /// items not documented by `rustdoc`. This is a `rustdoc` only lint, see
1875 /// the documentation in the [rustdoc book].
1877 /// [rustdoc book]: ../../../rustdoc/lints.html#private_doc_tests
1878 pub PRIVATE_DOC_TESTS,
1880 "detects code samples in docs of private items not documented by rustdoc"
1884 /// The `invalid_html_tags` lint detects invalid HTML tags. This is a
1885 /// `rustdoc` only lint, see the documentation in the [rustdoc book].
1887 /// [rustdoc book]: ../../../rustdoc/lints.html#invalid_html_tags
1888 pub INVALID_HTML_TAGS,
1890 "detects invalid HTML tags in doc comments"
1894 /// The `non_autolinks` lint detects when a URL could be written using
1895 /// only angle brackets. This is a `rustdoc` only lint, see the
1896 /// documentation in the [rustdoc book].
1898 /// [rustdoc book]: ../../../rustdoc/lints.html#non_autolinks
1901 "detects URLs that could be written using only angle brackets"
1905 /// The `where_clauses_object_safety` lint detects for [object safety] of
1906 /// [where clauses].
1908 /// [object safety]: https://doc.rust-lang.org/reference/items/traits.html#object-safety
1909 /// [where clauses]: https://doc.rust-lang.org/reference/items/generics.html#where-clauses
1916 /// trait X { fn foo(&self) where Self: Trait; }
1918 /// impl X for () { fn foo(&self) {} }
1920 /// impl Trait for dyn X {}
1922 /// // Segfault at opt-level 0, SIGILL otherwise.
1923 /// pub fn main() { <dyn X as X>::foo(&()); }
1930 /// The compiler previously allowed these object-unsafe bounds, which was
1931 /// incorrect. This is a [future-incompatible] lint to transition this to
1932 /// a hard error in the future. See [issue #51443] for more details.
1934 /// [issue #51443]: https://github.com/rust-lang/rust/issues/51443
1935 /// [future-incompatible]: ../index.md#future-incompatible-lints
1936 pub WHERE_CLAUSES_OBJECT_SAFETY,
1938 "checks the object safety of where clauses",
1939 @future_incompatible = FutureIncompatibleInfo {
1940 reference: "issue #51443 <https://github.com/rust-lang/rust/issues/51443>",
1946 /// The `proc_macro_derive_resolution_fallback` lint detects proc macro
1947 /// derives using inaccessible names from parent modules.
1951 /// ```rust,ignore (proc-macro)
1953 /// #![crate_type = "proc-macro"]
1955 /// extern crate proc_macro;
1957 /// use proc_macro::*;
1959 /// #[proc_macro_derive(Foo)]
1960 /// pub fn foo1(a: TokenStream) -> TokenStream {
1962 /// "mod __bar { static mut BAR: Option<Something> = None; }".parse().unwrap()
1966 /// ```rust,ignore (needs-dependency)
1969 /// extern crate foo;
1971 /// struct Something;
1979 /// This will produce:
1982 /// warning: cannot find type `Something` in this scope
1983 /// --> src/main.rs:8:10
1985 /// 8 | #[derive(Foo)]
1986 /// | ^^^ names from parent modules are not accessible without an explicit import
1988 /// = note: `#[warn(proc_macro_derive_resolution_fallback)]` on by default
1989 /// = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
1990 /// = note: for more information, see issue #50504 <https://github.com/rust-lang/rust/issues/50504>
1995 /// If a proc-macro generates a module, the compiler unintentionally
1996 /// allowed items in that module to refer to items in the crate root
1997 /// without importing them. This is a [future-incompatible] lint to
1998 /// transition this to a hard error in the future. See [issue #50504] for
2001 /// [issue #50504]: https://github.com/rust-lang/rust/issues/50504
2002 /// [future-incompatible]: ../index.md#future-incompatible-lints
2003 pub PROC_MACRO_DERIVE_RESOLUTION_FALLBACK,
2005 "detects proc macro derives using inaccessible names from parent modules",
2006 @future_incompatible = FutureIncompatibleInfo {
2007 reference: "issue #50504 <https://github.com/rust-lang/rust/issues/50504>",
2013 /// The `macro_use_extern_crate` lint detects the use of the
2014 /// [`macro_use` attribute].
2018 /// ```rust,ignore (needs extern crate)
2019 /// #![deny(macro_use_extern_crate)]
2022 /// extern crate serde_json;
2025 /// let _ = json!{{}};
2029 /// This will produce:
2032 /// error: deprecated `#[macro_use]` attribute used to import macros should be replaced at use sites with a `use` item to import the macro instead
2033 /// --> src/main.rs:3:1
2035 /// 3 | #[macro_use]
2038 /// note: the lint level is defined here
2039 /// --> src/main.rs:1:9
2041 /// 1 | #![deny(macro_use_extern_crate)]
2042 /// | ^^^^^^^^^^^^^^^^^^^^^^
2047 /// The [`macro_use` attribute] on an [`extern crate`] item causes
2048 /// macros in that external crate to be brought into the prelude of the
2049 /// crate, making the macros in scope everywhere. As part of the efforts
2050 /// to simplify handling of dependencies in the [2018 edition], the use of
2051 /// `extern crate` is being phased out. To bring macros from extern crates
2052 /// into scope, it is recommended to use a [`use` import].
2054 /// This lint is "allow" by default because this is a stylistic choice
2055 /// that has not been settled, see [issue #52043] for more information.
2057 /// [`macro_use` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#the-macro_use-attribute
2058 /// [`use` import]: https://doc.rust-lang.org/reference/items/use-declarations.html
2059 /// [issue #52043]: https://github.com/rust-lang/rust/issues/52043
2060 pub MACRO_USE_EXTERN_CRATE,
2062 "the `#[macro_use]` attribute is now deprecated in favor of using macros \
2063 via the module system"
2067 /// The `macro_expanded_macro_exports_accessed_by_absolute_paths` lint
2068 /// detects macro-expanded [`macro_export`] macros from the current crate
2069 /// that cannot be referred to by absolute paths.
2071 /// [`macro_export`]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
2075 /// ```rust,compile_fail
2076 /// macro_rules! define_exported {
2079 /// macro_rules! exported {
2085 /// define_exported!();
2088 /// crate::exported!();
2096 /// The intent is that all macros marked with the `#[macro_export]`
2097 /// attribute are made available in the root of the crate. However, when a
2098 /// `macro_rules!` definition is generated by another macro, the macro
2099 /// expansion is unable to uphold this rule. This is a
2100 /// [future-incompatible] lint to transition this to a hard error in the
2101 /// future. See [issue #53495] for more details.
2103 /// [issue #53495]: https://github.com/rust-lang/rust/issues/53495
2104 /// [future-incompatible]: ../index.md#future-incompatible-lints
2105 pub MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS,
2107 "macro-expanded `macro_export` macros from the current crate \
2108 cannot be referred to by absolute paths",
2109 @future_incompatible = FutureIncompatibleInfo {
2110 reference: "issue #52234 <https://github.com/rust-lang/rust/issues/52234>",
2117 /// The `explicit_outlives_requirements` lint detects unnecessary
2118 /// lifetime bounds that can be inferred.
2122 /// ```rust,compile_fail
2123 /// # #![allow(unused)]
2124 /// #![deny(explicit_outlives_requirements)]
2126 /// struct SharedRef<'a, T>
2138 /// If a `struct` contains a reference, such as `&'a T`, the compiler
2139 /// requires that `T` outlives the lifetime `'a`. This historically
2140 /// required writing an explicit lifetime bound to indicate this
2141 /// requirement. However, this can be overly explicit, causing clutter and
2142 /// unnecessary complexity. The language was changed to automatically
2143 /// infer the bound if it is not specified. Specifically, if the struct
2144 /// contains a reference, directly or indirectly, to `T` with lifetime
2145 /// `'x`, then it will infer that `T: 'x` is a requirement.
2147 /// This lint is "allow" by default because it can be noisy for existing
2148 /// code that already had these requirements. This is a stylistic choice,
2149 /// as it is still valid to explicitly state the bound. It also has some
2150 /// false positives that can cause confusion.
2152 /// See [RFC 2093] for more details.
2154 /// [RFC 2093]: https://github.com/rust-lang/rfcs/blob/master/text/2093-infer-outlives.md
2155 pub EXPLICIT_OUTLIVES_REQUIREMENTS,
2157 "outlives requirements can be inferred"
2161 /// The `indirect_structural_match` lint detects a `const` in a pattern
2162 /// that manually implements [`PartialEq`] and [`Eq`].
2164 /// [`PartialEq`]: https://doc.rust-lang.org/std/cmp/trait.PartialEq.html
2165 /// [`Eq`]: https://doc.rust-lang.org/std/cmp/trait.Eq.html
2169 /// ```rust,compile_fail
2170 /// #![deny(indirect_structural_match)]
2172 /// struct NoDerive(i32);
2173 /// impl PartialEq for NoDerive { fn eq(&self, _: &Self) -> bool { false } }
2174 /// impl Eq for NoDerive { }
2175 /// #[derive(PartialEq, Eq)]
2176 /// struct WrapParam<T>(T);
2177 /// const WRAP_INDIRECT_PARAM: & &WrapParam<NoDerive> = & &WrapParam(NoDerive(0));
2179 /// match WRAP_INDIRECT_PARAM {
2180 /// WRAP_INDIRECT_PARAM => { }
2190 /// The compiler unintentionally accepted this form in the past. This is a
2191 /// [future-incompatible] lint to transition this to a hard error in the
2192 /// future. See [issue #62411] for a complete description of the problem,
2193 /// and some possible solutions.
2195 /// [issue #62411]: https://github.com/rust-lang/rust/issues/62411
2196 /// [future-incompatible]: ../index.md#future-incompatible-lints
2197 pub INDIRECT_STRUCTURAL_MATCH,
2199 "constant used in pattern contains value of non-structural-match type in a field or a variant",
2200 @future_incompatible = FutureIncompatibleInfo {
2201 reference: "issue #62411 <https://github.com/rust-lang/rust/issues/62411>",
2207 /// The `deprecated_in_future` lint is internal to rustc and should not be
2208 /// used by user code.
2210 /// This lint is only enabled in the standard library. It works with the
2211 /// use of `#[rustc_deprecated]` with a `since` field of a version in the
2212 /// future. This allows something to be marked as deprecated in a future
2213 /// version, and then this lint will ensure that the item is no longer
2214 /// used in the standard library. See the [stability documentation] for
2217 /// [stability documentation]: https://rustc-dev-guide.rust-lang.org/stability.html#rustc_deprecated
2218 pub DEPRECATED_IN_FUTURE,
2220 "detects use of items that will be deprecated in a future version",
2221 report_in_external_macro
2225 /// The `pointer_structural_match` lint detects pointers used in patterns whose behaviour
2226 /// cannot be relied upon across compiler versions and optimization levels.
2230 /// ```rust,compile_fail
2231 /// #![deny(pointer_structural_match)]
2232 /// fn foo(a: usize, b: usize) -> usize { a + b }
2233 /// const FOO: fn(usize, usize) -> usize = foo;
2246 /// Previous versions of Rust allowed function pointers and wide raw pointers in patterns.
2247 /// While these work in many cases as expected by users, it is possible that due to
2248 /// optimizations pointers are "not equal to themselves" or pointers to different functions
2249 /// compare as equal during runtime. This is because LLVM optimizations can deduplicate
2250 /// functions if their bodies are the same, thus also making pointers to these functions point
2251 /// to the same location. Additionally functions may get duplicated if they are instantiated
2252 /// in different crates and not deduplicated again via LTO.
2253 pub POINTER_STRUCTURAL_MATCH,
2255 "pointers are not structural-match",
2256 @future_incompatible = FutureIncompatibleInfo {
2257 reference: "issue #62411 <https://github.com/rust-lang/rust/issues/70861>",
2263 /// The `nontrivial_structural_match` lint detects constants that are used in patterns,
2264 /// whose type is not structural-match and whose initializer body actually uses values
2265 /// that are not structural-match. So `Option<NotStruturalMatch>` is ok if the constant
2270 /// ```rust,compile_fail
2271 /// #![deny(nontrivial_structural_match)]
2273 /// #[derive(Copy, Clone, Debug)]
2274 /// struct NoDerive(u32);
2275 /// impl PartialEq for NoDerive { fn eq(&self, _: &Self) -> bool { false } }
2276 /// impl Eq for NoDerive { }
2278 /// const INDEX: Option<NoDerive> = [None, Some(NoDerive(10))][0];
2279 /// match None { Some(_) => panic!("whoops"), INDEX => dbg!(INDEX), };
2287 /// Previous versions of Rust accepted constants in patterns, even if those constants's types
2288 /// did not have `PartialEq` derived. Thus the compiler falls back to runtime execution of
2289 /// `PartialEq`, which can report that two constants are not equal even if they are
2291 pub NONTRIVIAL_STRUCTURAL_MATCH,
2293 "constant used in pattern of non-structural-match type and the constant's initializer \
2294 expression contains values of non-structural-match types",
2295 @future_incompatible = FutureIncompatibleInfo {
2296 reference: "issue #73448 <https://github.com/rust-lang/rust/issues/73448>",
2302 /// The `ambiguous_associated_items` lint detects ambiguity between
2303 /// [associated items] and [enum variants].
2305 /// [associated items]: https://doc.rust-lang.org/reference/items/associated-items.html
2306 /// [enum variants]: https://doc.rust-lang.org/reference/items/enumerations.html
2310 /// ```rust,compile_fail
2317 /// fn foo() -> Self::V;
2322 /// // `Self::V` is ambiguous because it may refer to the associated type or
2323 /// // the enum variant.
2324 /// fn foo() -> Self::V { 0 }
2332 /// Previous versions of Rust did not allow accessing enum variants
2333 /// through [type aliases]. When this ability was added (see [RFC 2338]), this
2334 /// introduced some situations where it can be ambiguous what a type
2335 /// was referring to.
2337 /// To fix this ambiguity, you should use a [qualified path] to explicitly
2338 /// state which type to use. For example, in the above example the
2339 /// function can be written as `fn f() -> <Self as Tr>::V { 0 }` to
2340 /// specifically refer to the associated type.
2342 /// This is a [future-incompatible] lint to transition this to a hard
2343 /// error in the future. See [issue #57644] for more details.
2345 /// [issue #57644]: https://github.com/rust-lang/rust/issues/57644
2346 /// [type aliases]: https://doc.rust-lang.org/reference/items/type-aliases.html#type-aliases
2347 /// [RFC 2338]: https://github.com/rust-lang/rfcs/blob/master/text/2338-type-alias-enum-variants.md
2348 /// [qualified path]: https://doc.rust-lang.org/reference/paths.html#qualified-paths
2349 /// [future-incompatible]: ../index.md#future-incompatible-lints
2350 pub AMBIGUOUS_ASSOCIATED_ITEMS,
2352 "ambiguous associated items",
2353 @future_incompatible = FutureIncompatibleInfo {
2354 reference: "issue #57644 <https://github.com/rust-lang/rust/issues/57644>",
2360 /// The `mutable_borrow_reservation_conflict` lint detects the reservation
2361 /// of a two-phased borrow that conflicts with other shared borrows.
2366 /// let mut v = vec![0, 1, 2];
2367 /// let shared = &v;
2368 /// v.push(shared.len());
2375 /// This is a [future-incompatible] lint to transition this to a hard error
2376 /// in the future. See [issue #59159] for a complete description of the
2377 /// problem, and some possible solutions.
2379 /// [issue #59159]: https://github.com/rust-lang/rust/issues/59159
2380 /// [future-incompatible]: ../index.md#future-incompatible-lints
2381 pub MUTABLE_BORROW_RESERVATION_CONFLICT,
2383 "reservation of a two-phased borrow conflicts with other shared borrows",
2384 @future_incompatible = FutureIncompatibleInfo {
2385 reference: "issue #59159 <https://github.com/rust-lang/rust/issues/59159>",
2391 /// The `soft_unstable` lint detects unstable features that were
2392 /// unintentionally allowed on stable.
2396 /// ```rust,compile_fail
2398 /// extern crate test;
2401 /// fn name(b: &mut test::Bencher) {
2410 /// The [`bench` attribute] was accidentally allowed to be specified on
2411 /// the [stable release channel]. Turning this to a hard error would have
2412 /// broken some projects. This lint allows those projects to continue to
2413 /// build correctly when [`--cap-lints`] is used, but otherwise signal an
2414 /// error that `#[bench]` should not be used on the stable channel. This
2415 /// is a [future-incompatible] lint to transition this to a hard error in
2416 /// the future. See [issue #64266] for more details.
2418 /// [issue #64266]: https://github.com/rust-lang/rust/issues/64266
2419 /// [`bench` attribute]: https://doc.rust-lang.org/nightly/unstable-book/library-features/test.html
2420 /// [stable release channel]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
2421 /// [`--cap-lints`]: https://doc.rust-lang.org/rustc/lints/levels.html#capping-lints
2422 /// [future-incompatible]: ../index.md#future-incompatible-lints
2425 "a feature gate that doesn't break dependent crates",
2426 @future_incompatible = FutureIncompatibleInfo {
2427 reference: "issue #64266 <https://github.com/rust-lang/rust/issues/64266>",
2433 /// The `inline_no_sanitize` lint detects incompatible use of
2434 /// [`#[inline(always)]`][inline] and [`#[no_sanitize(...)]`][no_sanitize].
2436 /// [inline]: https://doc.rust-lang.org/reference/attributes/codegen.html#the-inline-attribute
2437 /// [no_sanitize]: https://doc.rust-lang.org/nightly/unstable-book/language-features/no-sanitize.html
2442 /// #![feature(no_sanitize)]
2444 /// #[inline(always)]
2445 /// #[no_sanitize(address)]
2457 /// The use of the [`#[inline(always)]`][inline] attribute prevents the
2458 /// the [`#[no_sanitize(...)]`][no_sanitize] attribute from working.
2459 /// Consider temporarily removing `inline` attribute.
2460 pub INLINE_NO_SANITIZE,
2462 "detects incompatible use of `#[inline(always)]` and `#[no_sanitize(...)]`",
2466 /// The `asm_sub_register` lint detects using only a subset of a register
2467 /// for inline asm inputs.
2471 /// ```rust,ignore (fails on system llvm)
2472 /// #![feature(asm)]
2475 /// #[cfg(target_arch="x86_64")]
2477 /// asm!("mov {0}, {0}", in(reg) 0i16);
2482 /// This will produce:
2485 /// warning: formatting may not be suitable for sub-register argument
2486 /// --> src/main.rs:6:19
2488 /// 6 | asm!("mov {0}, {0}", in(reg) 0i16);
2489 /// | ^^^ ^^^ ---- for this argument
2491 /// = note: `#[warn(asm_sub_register)]` on by default
2492 /// = help: use the `x` modifier to have the register formatted as `ax`
2493 /// = help: or use the `r` modifier to keep the default formatting of `rax`
2498 /// Registers on some architectures can use different names to refer to a
2499 /// subset of the register. By default, the compiler will use the name for
2500 /// the full register size. To explicitly use a subset of the register,
2501 /// you can override the default by using a modifier on the template
2502 /// string operand to specify when subregister to use. This lint is issued
2503 /// if you pass in a value with a smaller data type than the default
2504 /// register size, to alert you of possibly using the incorrect width. To
2505 /// fix this, add the suggested modifier to the template, or cast the
2506 /// value to the correct size.
2508 /// See [register template modifiers] for more details.
2510 /// [register template modifiers]: https://doc.rust-lang.org/nightly/unstable-book/library-features/asm.html#register-template-modifiers
2511 pub ASM_SUB_REGISTER,
2513 "using only a subset of a register for inline asm inputs",
2517 /// The `unsafe_op_in_unsafe_fn` lint detects unsafe operations in unsafe
2518 /// functions without an explicit unsafe block. This lint only works on
2519 /// the [**nightly channel**] with the
2520 /// `#![feature(unsafe_block_in_unsafe_fn)]` feature.
2522 /// [**nightly channel**]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
2526 /// ```rust,compile_fail
2527 /// #![feature(unsafe_block_in_unsafe_fn)]
2528 /// #![deny(unsafe_op_in_unsafe_fn)]
2530 /// unsafe fn foo() {}
2532 /// unsafe fn bar() {
2543 /// Currently, an [`unsafe fn`] allows any [unsafe] operation within its
2544 /// body. However, this can increase the surface area of code that needs
2545 /// to be scrutinized for proper behavior. The [`unsafe` block] provides a
2546 /// convenient way to make it clear exactly which parts of the code are
2547 /// performing unsafe operations. In the future, it is desired to change
2548 /// it so that unsafe operations cannot be performed in an `unsafe fn`
2549 /// without an `unsafe` block.
2551 /// The fix to this is to wrap the unsafe code in an `unsafe` block.
2553 /// This lint is "allow" by default because it has not yet been
2554 /// stabilized, and is not yet complete. See [RFC #2585] and [issue
2555 /// #71668] for more details
2557 /// [`unsafe fn`]: https://doc.rust-lang.org/reference/unsafe-functions.html
2558 /// [`unsafe` block]: https://doc.rust-lang.org/reference/expressions/block-expr.html#unsafe-blocks
2559 /// [unsafe]: https://doc.rust-lang.org/reference/unsafety.html
2560 /// [RFC #2585]: https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md
2561 /// [issue #71668]: https://github.com/rust-lang/rust/issues/71668
2562 pub UNSAFE_OP_IN_UNSAFE_FN,
2564 "unsafe operations in unsafe functions without an explicit unsafe block are deprecated",
2565 @feature_gate = sym::unsafe_block_in_unsafe_fn;
2569 /// The `cenum_impl_drop_cast` lint detects an `as` cast of a field-less
2570 /// `enum` that implements [`Drop`].
2572 /// [`Drop`]: https://doc.rust-lang.org/std/ops/trait.Drop.html
2577 /// # #![allow(unused)]
2582 /// impl Drop for E {
2583 /// fn drop(&mut self) {
2584 /// println!("Drop");
2590 /// let i = e as u32;
2598 /// Casting a field-less `enum` that does not implement [`Copy`] to an
2599 /// integer moves the value without calling `drop`. This can result in
2600 /// surprising behavior if it was expected that `drop` should be called.
2601 /// Calling `drop` automatically would be inconsistent with other move
2602 /// operations. Since neither behavior is clear or consistent, it was
2603 /// decided that a cast of this nature will no longer be allowed.
2605 /// This is a [future-incompatible] lint to transition this to a hard error
2606 /// in the future. See [issue #73333] for more details.
2608 /// [future-incompatible]: ../index.md#future-incompatible-lints
2609 /// [issue #73333]: https://github.com/rust-lang/rust/issues/73333
2610 /// [`Copy`]: https://doc.rust-lang.org/std/marker/trait.Copy.html
2611 pub CENUM_IMPL_DROP_CAST,
2613 "a C-like enum implementing Drop is cast",
2614 @future_incompatible = FutureIncompatibleInfo {
2615 reference: "issue #73333 <https://github.com/rust-lang/rust/issues/73333>",
2621 /// The `const_evaluatable_unchecked` lint detects a generic constant used
2627 /// const fn foo<T>() -> usize {
2628 /// if std::mem::size_of::<*mut T>() < 8 { // size of *mut T does not depend on T
2636 /// let _ = [0; foo::<T>()];
2644 /// In the 1.43 release, some uses of generic parameters in array repeat
2645 /// expressions were accidentally allowed. This is a [future-incompatible]
2646 /// lint to transition this to a hard error in the future. See [issue
2647 /// #76200] for a more detailed description and possible fixes.
2649 /// [future-incompatible]: ../index.md#future-incompatible-lints
2650 /// [issue #76200]: https://github.com/rust-lang/rust/issues/76200
2651 pub CONST_EVALUATABLE_UNCHECKED,
2653 "detects a generic constant is used in a type without a emitting a warning",
2654 @future_incompatible = FutureIncompatibleInfo {
2655 reference: "issue #76200 <https://github.com/rust-lang/rust/issues/76200>",
2661 /// The `function_item_references` lint detects function references that are
2662 /// formatted with [`fmt::Pointer`] or transmuted.
2664 /// [`fmt::Pointer`]: https://doc.rust-lang.org/std/fmt/trait.Pointer.html
2672 /// println!("{:p}", &foo);
2680 /// Taking a reference to a function may be mistaken as a way to obtain a
2681 /// pointer to that function. This can give unexpected results when
2682 /// formatting the reference as a pointer or transmuting it. This lint is
2683 /// issued when function references are formatted as pointers, passed as
2684 /// arguments bound by [`fmt::Pointer`] or transmuted.
2685 pub FUNCTION_ITEM_REFERENCES,
2687 "suggest casting to a function pointer when attempting to take references to function items",
2691 /// The `uninhabited_static` lint detects uninhabited statics.
2698 /// static EXTERN: Void;
2706 /// Statics with an uninhabited type can never be initialized, so they are impossible to define.
2707 /// However, this can be side-stepped with an `extern static`, leading to problems later in the
2708 /// compiler which assumes that there are no initialized uninhabited places (such as locals or
2709 /// statics). This was accientally allowed, but is being phased out.
2710 pub UNINHABITED_STATIC,
2712 "uninhabited static",
2713 @future_incompatible = FutureIncompatibleInfo {
2714 reference: "issue #74840 <https://github.com/rust-lang/rust/issues/74840>",
2720 /// The `useless_deprecated` lint detects deprecation attributes with no effect.
2724 /// ```rust,compile_fail
2727 /// #[deprecated = "message"]
2728 /// impl Default for X {
2729 /// fn default() -> Self {
2739 /// Deprecation attributes have no effect on trait implementations.
2740 pub USELESS_DEPRECATED,
2742 "detects deprecation attributes with no effect",
2745 declare_tool_lint! {
2746 pub rustc::INEFFECTIVE_UNSTABLE_TRAIT_IMPL,
2748 "detects `#[unstable]` on stable trait implementations for stable types"
2751 declare_lint_pass! {
2752 /// Does nothing as a lint pass, but registers some `Lint`s
2753 /// that are used by other parts of the compiler.
2755 ILLEGAL_FLOATING_POINT_LITERAL_PATTERN,
2756 ARITHMETIC_OVERFLOW,
2757 UNCONDITIONAL_PANIC,
2759 UNUSED_EXTERN_CRATES,
2760 UNUSED_CRATE_DEPENDENCIES,
2761 UNUSED_QUALIFICATIONS,
2767 UNREACHABLE_PATTERNS,
2768 OVERLAPPING_PATTERNS,
2769 BINDINGS_WITH_VARIANT_NAME,
2774 UNKNOWN_CRATE_TYPES,
2776 TRIVIAL_NUMERIC_CASTS,
2778 EXPORTED_PRIVATE_DEPENDENCIES,
2779 PUB_USE_OF_PRIVATE_EXTERN_CRATE,
2780 INVALID_TYPE_PARAM_DEFAULT,
2782 RENAMED_AND_REMOVED_LINTS,
2783 UNALIGNED_REFERENCES,
2784 CONST_ITEM_MUTATION,
2785 SAFE_PACKED_BORROWS,
2786 PATTERNS_IN_FNS_WITHOUT_BODY,
2787 LATE_BOUND_LIFETIME_ARGUMENTS,
2788 ORDER_DEPENDENT_TRAIT_OBJECTS,
2789 COHERENCE_LEAK_CHECK,
2793 UNCONDITIONAL_RECURSION,
2794 SINGLE_USE_LIFETIMES,
2797 TYVAR_BEHIND_RAW_POINTER,
2798 ELIDED_LIFETIMES_IN_PATHS,
2800 ABSOLUTE_PATHS_NOT_STARTING_WITH_CRATE,
2801 UNSTABLE_NAME_COLLISIONS,
2802 IRREFUTABLE_LET_PATTERNS,
2803 BROKEN_INTRA_DOC_LINKS,
2804 PRIVATE_INTRA_DOC_LINKS,
2805 INVALID_CODEBLOCK_ATTRIBUTES,
2806 MISSING_CRATE_LEVEL_DOCS,
2807 MISSING_DOC_CODE_EXAMPLES,
2811 WHERE_CLAUSES_OBJECT_SAFETY,
2812 PROC_MACRO_DERIVE_RESOLUTION_FALLBACK,
2813 MACRO_USE_EXTERN_CRATE,
2814 MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS,
2815 ILL_FORMED_ATTRIBUTE_INPUT,
2816 CONFLICTING_REPR_HINTS,
2817 META_VARIABLE_MISUSE,
2818 DEPRECATED_IN_FUTURE,
2819 AMBIGUOUS_ASSOCIATED_ITEMS,
2820 MUTABLE_BORROW_RESERVATION_CONFLICT,
2821 INDIRECT_STRUCTURAL_MATCH,
2822 POINTER_STRUCTURAL_MATCH,
2823 NONTRIVIAL_STRUCTURAL_MATCH,
2827 UNSAFE_OP_IN_UNSAFE_FN,
2829 CENUM_IMPL_DROP_CAST,
2830 CONST_EVALUATABLE_UNCHECKED,
2831 INEFFECTIVE_UNSTABLE_TRAIT_IMPL,
2833 FUNCTION_ITEM_REFERENCES,
2839 /// The `unused_doc_comments` lint detects doc comments that aren't used
2853 /// `rustdoc` does not use doc comments in all positions, and so the doc
2854 /// comment will be ignored. Try changing it to a normal comment with `//`
2855 /// to avoid the warning.
2856 pub UNUSED_DOC_COMMENTS,
2858 "detects doc comments that aren't used by rustdoc"
2861 declare_lint_pass!(UnusedDocComment => [UNUSED_DOC_COMMENTS]);