1 // ignore-tidy-filelength
2 //! Some lints that are built in to the compiler.
4 //! These are the built-in lints that are emitted direct in the main
5 //! compiler code, rather than using their own custom pass. Those
6 //! lints are all available in `rustc_lint::builtin`.
8 use crate::{declare_lint, declare_lint_pass};
9 use rustc_span::edition::Edition;
10 use rustc_span::symbol::sym;
13 /// The `ill_formed_attribute_input` lint detects ill-formed attribute
14 /// inputs that were previously accepted and used in practice.
18 /// ```rust,compile_fail
19 /// #[inline = "this is not valid"]
27 /// Previously, inputs for many built-in attributes weren't validated and
28 /// nonsensical attribute inputs were accepted. After validation was
29 /// added, it was determined that some existing projects made use of these
30 /// invalid forms. This is a [future-incompatible] lint to transition this
31 /// to a hard error in the future. See [issue #57571] for more details.
33 /// Check the [attribute reference] for details on the valid inputs for
36 /// [issue #57571]: https://github.com/rust-lang/rust/issues/57571
37 /// [attribute reference]: https://doc.rust-lang.org/nightly/reference/attributes.html
38 /// [future-incompatible]: ../index.md#future-incompatible-lints
39 pub ILL_FORMED_ATTRIBUTE_INPUT,
41 "ill-formed attribute inputs that were previously accepted and used in practice",
42 @future_incompatible = FutureIncompatibleInfo {
43 reference: "issue #57571 <https://github.com/rust-lang/rust/issues/57571>",
50 /// The `conflicting_repr_hints` lint detects [`repr` attributes] with
51 /// conflicting hints.
53 /// [`repr` attributes]: https://doc.rust-lang.org/reference/type-layout.html#representations
57 /// ```rust,compile_fail
68 /// The compiler incorrectly accepted these conflicting representations in
69 /// the past. This is a [future-incompatible] lint to transition this to a
70 /// hard error in the future. See [issue #68585] for more details.
72 /// To correct the issue, remove one of the conflicting hints.
74 /// [issue #68585]: https://github.com/rust-lang/rust/issues/68585
75 /// [future-incompatible]: ../index.md#future-incompatible-lints
76 pub CONFLICTING_REPR_HINTS,
78 "conflicts between `#[repr(..)]` hints that were previously accepted and used in practice",
79 @future_incompatible = FutureIncompatibleInfo {
80 reference: "issue #68585 <https://github.com/rust-lang/rust/issues/68585>",
86 /// The `meta_variable_misuse` lint detects possible meta-variable misuse
87 /// in macro definitions.
91 /// ```rust,compile_fail
92 /// #![deny(meta_variable_misuse)]
94 /// macro_rules! foo {
96 /// ($( $i:ident = $($j:ident),+ );*) => { $( $( $i = $k; )+ )* };
108 /// There are quite a few different ways a [`macro_rules`] macro can be
109 /// improperly defined. Many of these errors were previously only detected
110 /// when the macro was expanded or not at all. This lint is an attempt to
111 /// catch some of these problems when the macro is *defined*.
113 /// This lint is "allow" by default because it may have false positives
114 /// and other issues. See [issue #61053] for more details.
116 /// [`macro_rules`]: https://doc.rust-lang.org/reference/macros-by-example.html
117 /// [issue #61053]: https://github.com/rust-lang/rust/issues/61053
118 pub META_VARIABLE_MISUSE,
120 "possible meta-variable misuse at macro definition"
124 /// The `incomplete_include` lint detects the use of the [`include!`]
125 /// macro with a file that contains more than one expression.
127 /// [`include!`]: https://doc.rust-lang.org/std/macro.include.html
131 /// ```rust,ignore (needs separate file)
133 /// include!("foo.txt");
137 /// where the file `foo.txt` contains:
146 /// error: include macro expected single expression in source
149 /// 1 | println!("1");
152 /// = note: `#[deny(incomplete_include)]` on by default
157 /// The [`include!`] macro is currently only intended to be used to
158 /// include a single [expression] or multiple [items]. Historically it
159 /// would ignore any contents after the first expression, but that can be
160 /// confusing. In the example above, the `println!` expression ends just
161 /// before the semicolon, making the semicolon "extra" information that is
162 /// ignored. Perhaps even more surprising, if the included file had
163 /// multiple print statements, the subsequent ones would be ignored!
165 /// One workaround is to place the contents in braces to create a [block
166 /// expression]. Also consider alternatives, like using functions to
167 /// encapsulate the expressions, or use [proc-macros].
169 /// This is a lint instead of a hard error because existing projects were
170 /// found to hit this error. To be cautious, it is a lint for now. The
171 /// future semantics of the `include!` macro are also uncertain, see
174 /// [items]: https://doc.rust-lang.org/reference/items.html
175 /// [expression]: https://doc.rust-lang.org/reference/expressions.html
176 /// [block expression]: https://doc.rust-lang.org/reference/expressions/block-expr.html
177 /// [proc-macros]: https://doc.rust-lang.org/reference/procedural-macros.html
178 /// [issue #35560]: https://github.com/rust-lang/rust/issues/35560
179 pub INCOMPLETE_INCLUDE,
181 "trailing content in included file"
185 /// The `arithmetic_overflow` lint detects that an arithmetic operation
188 /// [overflow]: https://doc.rust-lang.org/reference/expressions/operator-expr.html#overflow
192 /// ```rust,compile_fail
200 /// It is very likely a mistake to perform an arithmetic operation that
201 /// overflows its value. If the compiler is able to detect these kinds of
202 /// overflows at compile-time, it will trigger this lint. Consider
203 /// adjusting the expression to avoid overflow, or use a data type that
204 /// will not overflow.
205 pub ARITHMETIC_OVERFLOW,
207 "arithmetic operation overflows"
211 /// The `unconditional_panic` lint detects an operation that will cause a
212 /// panic at runtime.
216 /// ```rust,compile_fail
217 /// # #![allow(unused)]
225 /// This lint detects code that is very likely incorrect because it will
226 /// always panic, such as division by zero and out-of-bounds array
227 /// accesses. Consider adjusting your code if this is a bug, or using the
228 /// `panic!` or `unreachable!` macro instead in case the panic is intended.
229 pub UNCONDITIONAL_PANIC,
231 "operation will cause a panic at runtime"
235 /// The `const_err` lint detects an erroneous expression while doing
236 /// constant evaluation.
240 /// ```rust,compile_fail
241 /// #![allow(unconditional_panic)]
242 /// const C: i32 = 1/0;
249 /// This lint detects constants that fail to evaluate. Allowing the lint will accept the
250 /// constant declaration, but any use of this constant will still lead to a hard error. This is
251 /// a future incompatibility lint; the plan is to eventually entirely forbid even declaring
252 /// constants that cannot be evaluated. See [issue #71800] for more details.
254 /// [issue #71800]: https://github.com/rust-lang/rust/issues/71800
257 "constant evaluation encountered erroneous expression",
258 report_in_external_macro
262 /// The `unused_imports` lint detects imports that are never used.
267 /// use std::collections::HashMap;
274 /// Unused imports may signal a mistake or unfinished code, and clutter
275 /// the code, and should be removed. If you intended to re-export the item
276 /// to make it available outside of the module, add a visibility modifier
280 "imports that are never used"
284 /// The `unused_extern_crates` lint guards against `extern crate` items
285 /// that are never used.
289 /// ```rust,compile_fail
290 /// #![deny(unused_extern_crates)]
291 /// extern crate proc_macro;
298 /// `extern crate` items that are unused have no effect and should be
299 /// removed. Note that there are some cases where specifying an `extern
300 /// crate` is desired for the side effect of ensuring the given crate is
301 /// linked, even though it is not otherwise directly referenced. The lint
302 /// can be silenced by aliasing the crate to an underscore, such as
303 /// `extern crate foo as _`. Also note that it is no longer idiomatic to
304 /// use `extern crate` in the [2018 edition], as extern crates are now
305 /// automatically added in scope.
307 /// This lint is "allow" by default because it can be noisy, and produce
308 /// false-positives. If a dependency is being removed from a project, it
309 /// is recommended to remove it from the build configuration (such as
310 /// `Cargo.toml`) to ensure stale build entries aren't left behind.
312 /// [2018 edition]: https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html#no-more-extern-crate
313 pub UNUSED_EXTERN_CRATES,
315 "extern crates that are never used"
319 /// The `unused_crate_dependencies` lint detects crate dependencies that
324 /// ```rust,ignore (needs extern crate)
325 /// #![deny(unused_crate_dependencies)]
328 /// This will produce:
331 /// error: external crate `regex` unused in `lint_example`: remove the dependency or add `use regex as _;`
333 /// note: the lint level is defined here
334 /// --> src/lib.rs:1:9
336 /// 1 | #![deny(unused_crate_dependencies)]
337 /// | ^^^^^^^^^^^^^^^^^^^^^^^^^
342 /// After removing the code that uses a dependency, this usually also
343 /// requires removing the dependency from the build configuration.
344 /// However, sometimes that step can be missed, which leads to time wasted
345 /// building dependencies that are no longer used. This lint can be
346 /// enabled to detect dependencies that are never used (more specifically,
347 /// any dependency passed with the `--extern` command-line flag that is
348 /// never referenced via [`use`], [`extern crate`], or in any [path]).
350 /// This lint is "allow" by default because it can provide false positives
351 /// depending on how the build system is configured. For example, when
352 /// using Cargo, a "package" consists of multiple crates (such as a
353 /// library and a binary), but the dependencies are defined for the
354 /// package as a whole. If there is a dependency that is only used in the
355 /// binary, but not the library, then the lint will be incorrectly issued
358 /// [path]: https://doc.rust-lang.org/reference/paths.html
359 /// [`use`]: https://doc.rust-lang.org/reference/items/use-declarations.html
360 /// [`extern crate`]: https://doc.rust-lang.org/reference/items/extern-crates.html
361 pub UNUSED_CRATE_DEPENDENCIES,
363 "crate dependencies that are never used",
368 /// The `unused_qualifications` lint detects unnecessarily qualified
373 /// ```rust,compile_fail
374 /// #![deny(unused_qualifications)]
389 /// If an item from another module is already brought into scope, then
390 /// there is no need to qualify it in this case. You can call `bar()`
391 /// directly, without the `foo::`.
393 /// This lint is "allow" by default because it is somewhat pedantic, and
394 /// doesn't indicate an actual problem, but rather a stylistic choice, and
395 /// can be noisy when refactoring or moving around code.
396 pub UNUSED_QUALIFICATIONS,
398 "detects unnecessarily qualified names"
402 /// The `unknown_lints` lint detects unrecognized lint attribute.
407 /// #![allow(not_a_real_lint)]
414 /// It is usually a mistake to specify a lint that does not exist. Check
415 /// the spelling, and check the lint listing for the correct name. Also
416 /// consider if you are using an old version of the compiler, and the lint
417 /// is only available in a newer version.
420 "unrecognized lint attribute"
424 /// The `unused_variables` lint detects variables which are not used in
437 /// Unused variables may signal a mistake or unfinished code. To silence
438 /// the warning for the individual variable, prefix it with an underscore
440 pub UNUSED_VARIABLES,
442 "detect variables which are not used in any way"
446 /// The `unused_assignments` lint detects assignments that will never be read.
459 /// Unused assignments may signal a mistake or unfinished code. If the
460 /// variable is never used after being assigned, then the assignment can
461 /// be removed. Variables with an underscore prefix such as `_x` will not
462 /// trigger this lint.
463 pub UNUSED_ASSIGNMENTS,
465 "detect assignments that will never be read"
469 /// The `dead_code` lint detects unused, unexported items.
481 /// Dead code may signal a mistake or unfinished code. To silence the
482 /// warning for individual items, prefix the name with an underscore such
483 /// as `_foo`. If it was intended to expose the item outside of the crate,
484 /// consider adding a visibility modifier like `pub`. Otherwise consider
485 /// removing the unused code.
488 "detect unused, unexported items"
492 /// The `unused_attributes` lint detects attributes that were not used by
505 /// Unused [attributes] may indicate the attribute is placed in the wrong
506 /// position. Consider removing it, or placing it in the correct position.
507 /// Also consider if you intended to use an _inner attribute_ (with a `!`
508 /// such as `#![allow(unused)]`) which applies to the item the attribute
509 /// is within, or an _outer attribute_ (without a `!` such as
510 /// `#[allow(unsued)]`) which applies to the item *following* the
513 /// [attributes]: https://doc.rust-lang.org/reference/attributes.html
514 pub UNUSED_ATTRIBUTES,
516 "detects attributes that were not used by the compiler"
520 /// The `unreachable_code` lint detects unreachable code paths.
525 /// panic!("we never go past here!");
534 /// Unreachable code may signal a mistake or unfinished code. If the code
535 /// is no longer in use, consider removing it.
536 pub UNREACHABLE_CODE,
538 "detects unreachable code paths",
539 report_in_external_macro
543 /// The `unreachable_patterns` lint detects unreachable patterns.
559 /// This usually indicates a mistake in how the patterns are specified or
560 /// ordered. In this example, the `y` pattern will always match, so the
561 /// five is impossible to reach. Remember, match arms match in order, you
562 /// probably wanted to put the `5` case above the `y` case.
563 pub UNREACHABLE_PATTERNS,
565 "detects unreachable patterns"
569 /// The `overlapping_range_endpoints` lint detects `match` arms that have [range patterns] that
570 /// overlap on their endpoints.
572 /// [range patterns]: https://doc.rust-lang.org/nightly/reference/patterns.html#range-patterns
579 /// 0..=100 => { println!("small"); }
580 /// 100..=255 => { println!("large"); }
588 /// It is likely a mistake to have range patterns in a match expression that overlap in this
589 /// way. Check that the beginning and end values are what you expect, and keep in mind that
590 /// with `..=` the left and right bounds are inclusive.
591 pub OVERLAPPING_RANGE_ENDPOINTS,
593 "detects range patterns with overlapping endpoints"
597 /// The `bindings_with_variant_name` lint detects pattern bindings with
598 /// the same name as one of the matched variants.
608 /// pub fn foo(x: Enum) {
620 /// It is usually a mistake to specify an enum variant name as an
621 /// [identifier pattern]. In the example above, the `match` arms are
622 /// specifying a variable name to bind the value of `x` to. The second arm
623 /// is ignored because the first one matches *all* values. The likely
624 /// intent is that the arm was intended to match on the enum variant.
626 /// Two possible solutions are:
628 /// * Specify the enum variant using a [path pattern], such as
630 /// * Bring the enum variants into local scope, such as adding `use
631 /// Enum::*;` to the beginning of the `foo` function in the example
634 /// [identifier pattern]: https://doc.rust-lang.org/reference/patterns.html#identifier-patterns
635 /// [path pattern]: https://doc.rust-lang.org/reference/patterns.html#path-patterns
636 pub BINDINGS_WITH_VARIANT_NAME,
638 "detects pattern bindings with the same name as one of the matched variants"
642 /// The `unused_macros` lint detects macros that were not used.
647 /// macro_rules! unused {
659 /// Unused macros may signal a mistake or unfinished code. To silence the
660 /// warning for the individual macro, prefix the name with an underscore
661 /// such as `_my_macro`. If you intended to export the macro to make it
662 /// available outside of the crate, use the [`macro_export` attribute].
664 /// [`macro_export` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
667 "detects macros that were not used"
671 /// The `warnings` lint allows you to change the level of other
672 /// lints which produce warnings.
677 /// #![deny(warnings)]
685 /// The `warnings` lint is a bit special; by changing its level, you
686 /// change every other warning that would produce a warning to whatever
687 /// value you'd like. As such, you won't ever trigger this lint in your
691 "mass-change the level for lints which produce warnings"
695 /// The `unused_features` lint detects unused or unknown features found in
696 /// crate-level [`feature` attributes].
698 /// [`feature` attributes]: https://doc.rust-lang.org/nightly/unstable-book/
700 /// Note: This lint is currently not functional, see [issue #44232] for
703 /// [issue #44232]: https://github.com/rust-lang/rust/issues/44232
706 "unused features found in crate-level `#[feature]` directives"
710 /// The `stable_features` lint detects a [`feature` attribute] that
711 /// has since been made stable.
713 /// [`feature` attribute]: https://doc.rust-lang.org/nightly/unstable-book/
718 /// #![feature(test_accepted_feature)]
726 /// When a feature is stabilized, it is no longer necessary to include a
727 /// `#![feature]` attribute for it. To fix, simply remove the
728 /// `#![feature]` attribute.
731 "stable features found in `#[feature]` directive"
735 /// The `unknown_crate_types` lint detects an unknown crate type found in
736 /// a [`crate_type` attribute].
740 /// ```rust,compile_fail
741 /// #![crate_type="lol"]
749 /// An unknown value give to the `crate_type` attribute is almost
750 /// certainly a mistake.
752 /// [`crate_type` attribute]: https://doc.rust-lang.org/reference/linkage.html
753 pub UNKNOWN_CRATE_TYPES,
755 "unknown crate type found in `#[crate_type]` directive",
760 /// The `trivial_casts` lint detects trivial casts which could be replaced
761 /// with coercion, which may require [type ascription] or a temporary
766 /// ```rust,compile_fail
767 /// #![deny(trivial_casts)]
768 /// let x: &u32 = &42;
769 /// let y = x as *const u32;
776 /// A trivial cast is a cast `e as T` where `e` has type `U` and `U` is a
777 /// subtype of `T`. This type of cast is usually unnecessary, as it can be
778 /// usually be inferred.
780 /// This lint is "allow" by default because there are situations, such as
781 /// with FFI interfaces or complex type aliases, where it triggers
782 /// incorrectly, or in situations where it will be more difficult to
783 /// clearly express the intent. It may be possible that this will become a
784 /// warning in the future, possibly with [type ascription] providing a
785 /// convenient way to work around the current issues. See [RFC 401] for
786 /// historical context.
788 /// [type ascription]: https://github.com/rust-lang/rust/issues/23416
789 /// [RFC 401]: https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md
792 "detects trivial casts which could be removed"
796 /// The `trivial_numeric_casts` lint detects trivial numeric casts of types
797 /// which could be removed.
801 /// ```rust,compile_fail
802 /// #![deny(trivial_numeric_casts)]
803 /// let x = 42_i32 as i32;
810 /// A trivial numeric cast is a cast of a numeric type to the same numeric
811 /// type. This type of cast is usually unnecessary.
813 /// This lint is "allow" by default because there are situations, such as
814 /// with FFI interfaces or complex type aliases, where it triggers
815 /// incorrectly, or in situations where it will be more difficult to
816 /// clearly express the intent. It may be possible that this will become a
817 /// warning in the future, possibly with [type ascription] providing a
818 /// convenient way to work around the current issues. See [RFC 401] for
819 /// historical context.
821 /// [type ascription]: https://github.com/rust-lang/rust/issues/23416
822 /// [RFC 401]: https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md
823 pub TRIVIAL_NUMERIC_CASTS,
825 "detects trivial casts of numeric types which could be removed"
829 /// The `private_in_public` lint detects private items in public
830 /// interfaces not caught by the old implementation.
835 /// # #![allow(unused)]
840 /// impl super::SemiPriv {
841 /// pub fn f(_: Priv) {}
851 /// The visibility rules are intended to prevent exposing private items in
852 /// public interfaces. This is a [future-incompatible] lint to transition
853 /// this to a hard error in the future. See [issue #34537] for more
856 /// [issue #34537]: https://github.com/rust-lang/rust/issues/34537
857 /// [future-incompatible]: ../index.md#future-incompatible-lints
858 pub PRIVATE_IN_PUBLIC,
860 "detect private items in public interfaces not caught by the old implementation",
861 @future_incompatible = FutureIncompatibleInfo {
862 reference: "issue #34537 <https://github.com/rust-lang/rust/issues/34537>",
868 /// The `exported_private_dependencies` lint detects private dependencies
869 /// that are exposed in a public interface.
873 /// ```rust,ignore (needs-dependency)
874 /// pub fn foo() -> Option<some_private_dependency::Thing> {
879 /// This will produce:
882 /// warning: type `bar::Thing` from private dependency 'bar' in public interface
883 /// --> src/lib.rs:3:1
885 /// 3 | pub fn foo() -> Option<bar::Thing> {
886 /// | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
888 /// = note: `#[warn(exported_private_dependencies)]` on by default
893 /// Dependencies can be marked as "private" to indicate that they are not
894 /// exposed in the public interface of a crate. This can be used by Cargo
895 /// to independently resolve those dependencies because it can assume it
896 /// does not need to unify them with other packages using that same
897 /// dependency. This lint is an indication of a violation of that
900 /// To fix this, avoid exposing the dependency in your public interface.
901 /// Or, switch the dependency to a public dependency.
903 /// Note that support for this is only available on the nightly channel.
904 /// See [RFC 1977] for more details, as well as the [Cargo documentation].
906 /// [RFC 1977]: https://github.com/rust-lang/rfcs/blob/master/text/1977-public-private-dependencies.md
907 /// [Cargo documentation]: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#public-dependency
908 pub EXPORTED_PRIVATE_DEPENDENCIES,
910 "public interface leaks type from a private dependency"
914 /// The `pub_use_of_private_extern_crate` lint detects a specific
915 /// situation of re-exporting a private `extern crate`.
919 /// ```rust,compile_fail
920 /// extern crate core;
921 /// pub use core as reexported_core;
928 /// A public `use` declaration should not be used to publicly re-export a
929 /// private `extern crate`. `pub extern crate` should be used instead.
931 /// This was historically allowed, but is not the intended behavior
932 /// according to the visibility rules. This is a [future-incompatible]
933 /// lint to transition this to a hard error in the future. See [issue
934 /// #34537] for more details.
936 /// [issue #34537]: https://github.com/rust-lang/rust/issues/34537
937 /// [future-incompatible]: ../index.md#future-incompatible-lints
938 pub PUB_USE_OF_PRIVATE_EXTERN_CRATE,
940 "detect public re-exports of private extern crates",
941 @future_incompatible = FutureIncompatibleInfo {
942 reference: "issue #34537 <https://github.com/rust-lang/rust/issues/34537>",
948 /// The `invalid_type_param_default` lint detects type parameter defaults
949 /// erroneously allowed in an invalid location.
953 /// ```rust,compile_fail
954 /// fn foo<T=i32>(t: T) {}
961 /// Default type parameters were only intended to be allowed in certain
962 /// situations, but historically the compiler allowed them everywhere.
963 /// This is a [future-incompatible] lint to transition this to a hard
964 /// error in the future. See [issue #36887] for more details.
966 /// [issue #36887]: https://github.com/rust-lang/rust/issues/36887
967 /// [future-incompatible]: ../index.md#future-incompatible-lints
968 pub INVALID_TYPE_PARAM_DEFAULT,
970 "type parameter default erroneously allowed in invalid location",
971 @future_incompatible = FutureIncompatibleInfo {
972 reference: "issue #36887 <https://github.com/rust-lang/rust/issues/36887>",
978 /// The `renamed_and_removed_lints` lint detects lints that have been
979 /// renamed or removed.
984 /// #![deny(raw_pointer_derive)]
991 /// To fix this, either remove the lint or use the new name. This can help
992 /// avoid confusion about lints that are no longer valid, and help
993 /// maintain consistency for renamed lints.
994 pub RENAMED_AND_REMOVED_LINTS,
996 "lints that have been renamed or removed"
1000 /// The `unaligned_references` lint detects unaligned references to fields
1001 /// of [packed] structs.
1003 /// [packed]: https://doc.rust-lang.org/reference/type-layout.html#the-alignment-modifiers
1007 /// ```rust,compile_fail
1008 /// #![deny(unaligned_references)]
1011 /// pub struct Foo {
1018 /// let foo = Foo { field1: 0, field2: 0 };
1019 /// let _ = &foo.field1;
1028 /// Creating a reference to an insufficiently aligned packed field is
1029 /// [undefined behavior] and should be disallowed.
1031 /// This lint is "allow" by default because there is no stable
1032 /// alternative, and it is not yet certain how widespread existing code
1033 /// will trigger this lint.
1035 /// See [issue #27060] for more discussion.
1037 /// [undefined behavior]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html
1038 /// [issue #27060]: https://github.com/rust-lang/rust/issues/27060
1039 pub UNALIGNED_REFERENCES,
1041 "detects unaligned references to fields of packed structs",
1045 /// The `const_item_mutation` lint detects attempts to mutate a `const`
1051 /// const FOO: [i32; 1] = [0];
1055 /// // This will print "[0]".
1056 /// println!("{:?}", FOO);
1064 /// Trying to directly mutate a `const` item is almost always a mistake.
1065 /// What is happening in the example above is that a temporary copy of the
1066 /// `const` is mutated, but the original `const` is not. Each time you
1067 /// refer to the `const` by name (such as `FOO` in the example above), a
1068 /// separate copy of the value is inlined at that location.
1070 /// This lint checks for writing directly to a field (`FOO.field =
1071 /// some_value`) or array entry (`FOO[0] = val`), or taking a mutable
1072 /// reference to the const item (`&mut FOO`), including through an
1073 /// autoderef (`FOO.some_mut_self_method()`).
1075 /// There are various alternatives depending on what you are trying to
1078 /// * First, always reconsider using mutable globals, as they can be
1079 /// difficult to use correctly, and can make the code more difficult to
1080 /// use or understand.
1081 /// * If you are trying to perform a one-time initialization of a global:
1082 /// * If the value can be computed at compile-time, consider using
1083 /// const-compatible values (see [Constant Evaluation]).
1084 /// * For more complex single-initialization cases, consider using a
1085 /// third-party crate, such as [`lazy_static`] or [`once_cell`].
1086 /// * If you are using the [nightly channel], consider the new
1087 /// [`lazy`] module in the standard library.
1088 /// * If you truly need a mutable global, consider using a [`static`],
1089 /// which has a variety of options:
1090 /// * Simple data types can be directly defined and mutated with an
1091 /// [`atomic`] type.
1092 /// * More complex types can be placed in a synchronization primitive
1093 /// like a [`Mutex`], which can be initialized with one of the options
1095 /// * A [mutable `static`] is a low-level primitive, requiring unsafe.
1096 /// Typically This should be avoided in preference of something
1097 /// higher-level like one of the above.
1099 /// [Constant Evaluation]: https://doc.rust-lang.org/reference/const_eval.html
1100 /// [`static`]: https://doc.rust-lang.org/reference/items/static-items.html
1101 /// [mutable `static`]: https://doc.rust-lang.org/reference/items/static-items.html#mutable-statics
1102 /// [`lazy`]: https://doc.rust-lang.org/nightly/std/lazy/index.html
1103 /// [`lazy_static`]: https://crates.io/crates/lazy_static
1104 /// [`once_cell`]: https://crates.io/crates/once_cell
1105 /// [`atomic`]: https://doc.rust-lang.org/std/sync/atomic/index.html
1106 /// [`Mutex`]: https://doc.rust-lang.org/std/sync/struct.Mutex.html
1107 pub CONST_ITEM_MUTATION,
1109 "detects attempts to mutate a `const` item",
1113 /// The `safe_packed_borrows` lint detects borrowing a field in the
1114 /// interior of a packed structure with alignment other than 1.
1120 /// pub struct Unaligned<T>(pub T);
1122 /// pub struct Foo {
1124 /// data: Unaligned<u32>,
1128 /// let x = Foo { start: 0, data: Unaligned(1) };
1129 /// let y = &x.data.0;
1137 /// This type of borrow is unsafe and can cause errors on some platforms
1138 /// and violates some assumptions made by the compiler. This was
1139 /// previously allowed unintentionally. This is a [future-incompatible]
1140 /// lint to transition this to a hard error in the future. See [issue
1141 /// #46043] for more details, including guidance on how to solve the
1144 /// [issue #46043]: https://github.com/rust-lang/rust/issues/46043
1145 /// [future-incompatible]: ../index.md#future-incompatible-lints
1146 pub SAFE_PACKED_BORROWS,
1148 "safe borrows of fields of packed structs were erroneously allowed",
1149 @future_incompatible = FutureIncompatibleInfo {
1150 reference: "issue #46043 <https://github.com/rust-lang/rust/issues/46043>",
1156 /// The `patterns_in_fns_without_body` lint detects `mut` identifier
1157 /// patterns as a parameter in functions without a body.
1161 /// ```rust,compile_fail
1163 /// fn foo(mut arg: u8);
1171 /// To fix this, remove `mut` from the parameter in the trait definition;
1172 /// it can be used in the implementation. That is, the following is OK:
1176 /// fn foo(arg: u8); // Removed `mut` here
1179 /// impl Trait for i32 {
1180 /// fn foo(mut arg: u8) { // `mut` here is OK
1186 /// Trait definitions can define functions without a body to specify a
1187 /// function that implementors must define. The parameter names in the
1188 /// body-less functions are only allowed to be `_` or an [identifier] for
1189 /// documentation purposes (only the type is relevant). Previous versions
1190 /// of the compiler erroneously allowed [identifier patterns] with the
1191 /// `mut` keyword, but this was not intended to be allowed. This is a
1192 /// [future-incompatible] lint to transition this to a hard error in the
1193 /// future. See [issue #35203] for more details.
1195 /// [identifier]: https://doc.rust-lang.org/reference/identifiers.html
1196 /// [identifier patterns]: https://doc.rust-lang.org/reference/patterns.html#identifier-patterns
1197 /// [issue #35203]: https://github.com/rust-lang/rust/issues/35203
1198 /// [future-incompatible]: ../index.md#future-incompatible-lints
1199 pub PATTERNS_IN_FNS_WITHOUT_BODY,
1201 "patterns in functions without body were erroneously allowed",
1202 @future_incompatible = FutureIncompatibleInfo {
1203 reference: "issue #35203 <https://github.com/rust-lang/rust/issues/35203>",
1209 /// The `missing_fragment_specifier` lint is issued when an unused pattern in a
1210 /// `macro_rules!` macro definition has a meta-variable (e.g. `$e`) that is not
1211 /// followed by a fragment specifier (e.g. `:expr`).
1213 /// This warning can always be fixed by removing the unused pattern in the
1214 /// `macro_rules!` macro definition.
1218 /// ```rust,compile_fail
1219 /// macro_rules! foo {
1233 /// To fix this, remove the unused pattern from the `macro_rules!` macro definition:
1236 /// macro_rules! foo {
1243 pub MISSING_FRAGMENT_SPECIFIER,
1245 "detects missing fragment specifiers in unused `macro_rules!` patterns",
1246 @future_incompatible = FutureIncompatibleInfo {
1247 reference: "issue #40107 <https://github.com/rust-lang/rust/issues/40107>",
1253 /// The `late_bound_lifetime_arguments` lint detects generic lifetime
1254 /// arguments in path segments with late bound lifetime parameters.
1262 /// fn late<'a, 'b>(self, _: &'a u8, _: &'b u8) {}
1266 /// S.late::<'static>(&0, &0);
1274 /// It is not clear how to provide arguments for early-bound lifetime
1275 /// parameters if they are intermixed with late-bound parameters in the
1276 /// same list. For now, providing any explicit arguments will trigger this
1277 /// lint if late-bound parameters are present, so in the future a solution
1278 /// can be adopted without hitting backward compatibility issues. This is
1279 /// a [future-incompatible] lint to transition this to a hard error in the
1280 /// future. See [issue #42868] for more details, along with a description
1281 /// of the difference between early and late-bound parameters.
1283 /// [issue #42868]: https://github.com/rust-lang/rust/issues/42868
1284 /// [future-incompatible]: ../index.md#future-incompatible-lints
1285 pub LATE_BOUND_LIFETIME_ARGUMENTS,
1287 "detects generic lifetime arguments in path segments with late bound lifetime parameters",
1288 @future_incompatible = FutureIncompatibleInfo {
1289 reference: "issue #42868 <https://github.com/rust-lang/rust/issues/42868>",
1295 /// The `order_dependent_trait_objects` lint detects a trait coherency
1296 /// violation that would allow creating two trait impls for the same
1297 /// dynamic trait object involving marker traits.
1301 /// ```rust,compile_fail
1302 /// pub trait Trait {}
1304 /// impl Trait for dyn Send + Sync { }
1305 /// impl Trait for dyn Sync + Send { }
1312 /// A previous bug caused the compiler to interpret traits with different
1313 /// orders (such as `Send + Sync` and `Sync + Send`) as distinct types
1314 /// when they were intended to be treated the same. This allowed code to
1315 /// define separate trait implementations when there should be a coherence
1316 /// error. This is a [future-incompatible] lint to transition this to a
1317 /// hard error in the future. See [issue #56484] for more details.
1319 /// [issue #56484]: https://github.com/rust-lang/rust/issues/56484
1320 /// [future-incompatible]: ../index.md#future-incompatible-lints
1321 pub ORDER_DEPENDENT_TRAIT_OBJECTS,
1323 "trait-object types were treated as different depending on marker-trait order",
1324 @future_incompatible = FutureIncompatibleInfo {
1325 reference: "issue #56484 <https://github.com/rust-lang/rust/issues/56484>",
1331 /// The `coherence_leak_check` lint detects conflicting implementations of
1332 /// a trait that are only distinguished by the old leak-check code.
1337 /// trait SomeTrait { }
1338 /// impl SomeTrait for for<'a> fn(&'a u8) { }
1339 /// impl<'a> SomeTrait for fn(&'a u8) { }
1346 /// In the past, the compiler would accept trait implementations for
1347 /// identical functions that differed only in where the lifetime binder
1348 /// appeared. Due to a change in the borrow checker implementation to fix
1349 /// several bugs, this is no longer allowed. However, since this affects
1350 /// existing code, this is a [future-incompatible] lint to transition this
1351 /// to a hard error in the future.
1353 /// Code relying on this pattern should introduce "[newtypes]",
1354 /// like `struct Foo(for<'a> fn(&'a u8))`.
1356 /// See [issue #56105] for more details.
1358 /// [issue #56105]: https://github.com/rust-lang/rust/issues/56105
1359 /// [newtypes]: https://doc.rust-lang.org/book/ch19-04-advanced-types.html#using-the-newtype-pattern-for-type-safety-and-abstraction
1360 /// [future-incompatible]: ../index.md#future-incompatible-lints
1361 pub COHERENCE_LEAK_CHECK,
1363 "distinct impls distinguished only by the leak-check code",
1364 @future_incompatible = FutureIncompatibleInfo {
1365 reference: "issue #56105 <https://github.com/rust-lang/rust/issues/56105>",
1371 /// The `deprecated` lint detects use of deprecated items.
1388 /// Items may be marked "deprecated" with the [`deprecated` attribute] to
1389 /// indicate that they should no longer be used. Usually the attribute
1390 /// should include a note on what to use instead, or check the
1393 /// [`deprecated` attribute]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute
1396 "detects use of deprecated items",
1397 report_in_external_macro
1401 /// The `unused_unsafe` lint detects unnecessary use of an `unsafe` block.
1413 /// If nothing within the block requires `unsafe`, then remove the
1414 /// `unsafe` marker because it is not required and may cause confusion.
1417 "unnecessary use of an `unsafe` block"
1421 /// The `unused_mut` lint detects mut variables which don't need to be
1434 /// The preferred style is to only mark variables as `mut` if it is
1438 "detect mut variables which don't need to be mutable"
1442 /// The `unconditional_recursion` lint detects functions that cannot
1443 /// return without calling themselves.
1457 /// It is usually a mistake to have a recursive call that does not have
1458 /// some condition to cause it to terminate. If you really intend to have
1459 /// an infinite loop, using a `loop` expression is recommended.
1460 pub UNCONDITIONAL_RECURSION,
1462 "functions that cannot return without calling themselves"
1466 /// The `single_use_lifetimes` lint detects lifetimes that are only used
1471 /// ```rust,compile_fail
1472 /// #![deny(single_use_lifetimes)]
1474 /// fn foo<'a>(x: &'a u32) {}
1481 /// Specifying an explicit lifetime like `'a` in a function or `impl`
1482 /// should only be used to link together two things. Otherwise, you should
1483 /// just use `'_` to indicate that the lifetime is not linked to anything,
1484 /// or elide the lifetime altogether if possible.
1486 /// This lint is "allow" by default because it was introduced at a time
1487 /// when `'_` and elided lifetimes were first being introduced, and this
1488 /// lint would be too noisy. Also, there are some known false positives
1489 /// that it produces. See [RFC 2115] for historical context, and [issue
1490 /// #44752] for more details.
1492 /// [RFC 2115]: https://github.com/rust-lang/rfcs/blob/master/text/2115-argument-lifetimes.md
1493 /// [issue #44752]: https://github.com/rust-lang/rust/issues/44752
1494 pub SINGLE_USE_LIFETIMES,
1496 "detects lifetime parameters that are only used once"
1500 /// The `unused_lifetimes` lint detects lifetime parameters that are never
1505 /// ```rust,compile_fail
1506 /// #[deny(unused_lifetimes)]
1508 /// pub fn foo<'a>() {}
1515 /// Unused lifetime parameters may signal a mistake or unfinished code.
1516 /// Consider removing the parameter.
1517 pub UNUSED_LIFETIMES,
1519 "detects lifetime parameters that are never used"
1523 /// The `tyvar_behind_raw_pointer` lint detects raw pointer to an
1524 /// inference variable.
1528 /// ```rust,edition2015
1530 /// let data = std::ptr::null();
1531 /// let _ = &data as *const *const ();
1533 /// if data.is_null() {}
1540 /// This kind of inference was previously allowed, but with the future
1541 /// arrival of [arbitrary self types], this can introduce ambiguity. To
1542 /// resolve this, use an explicit type instead of relying on type
1545 /// This is a [future-incompatible] lint to transition this to a hard
1546 /// error in the 2018 edition. See [issue #46906] for more details. This
1547 /// is currently a hard-error on the 2018 edition, and is "warn" by
1548 /// default in the 2015 edition.
1550 /// [arbitrary self types]: https://github.com/rust-lang/rust/issues/44874
1551 /// [issue #46906]: https://github.com/rust-lang/rust/issues/46906
1552 /// [future-incompatible]: ../index.md#future-incompatible-lints
1553 pub TYVAR_BEHIND_RAW_POINTER,
1555 "raw pointer to an inference variable",
1556 @future_incompatible = FutureIncompatibleInfo {
1557 reference: "issue #46906 <https://github.com/rust-lang/rust/issues/46906>",
1558 edition: Some(Edition::Edition2018),
1563 /// The `elided_lifetimes_in_paths` lint detects the use of hidden
1564 /// lifetime parameters.
1568 /// ```rust,compile_fail
1569 /// #![deny(elided_lifetimes_in_paths)]
1570 /// struct Foo<'a> {
1574 /// fn foo(x: &Foo) {
1582 /// Elided lifetime parameters can make it difficult to see at a glance
1583 /// that borrowing is occurring. This lint ensures that lifetime
1584 /// parameters are always explicitly stated, even if it is the `'_`
1585 /// [placeholder lifetime].
1587 /// This lint is "allow" by default because it has some known issues, and
1588 /// may require a significant transition for old code.
1590 /// [placeholder lifetime]: https://doc.rust-lang.org/reference/lifetime-elision.html#lifetime-elision-in-functions
1591 pub ELIDED_LIFETIMES_IN_PATHS,
1593 "hidden lifetime parameters in types are deprecated",
1598 /// The `bare_trait_objects` lint suggests using `dyn Trait` for trait
1606 /// fn takes_trait_object(_: Box<Trait>) {
1614 /// Without the `dyn` indicator, it can be ambiguous or confusing when
1615 /// reading code as to whether or not you are looking at a trait object.
1616 /// The `dyn` keyword makes it explicit, and adds a symmetry to contrast
1617 /// with [`impl Trait`].
1619 /// [`impl Trait`]: https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
1620 pub BARE_TRAIT_OBJECTS,
1622 "suggest using `dyn Trait` for trait objects"
1626 /// The `absolute_paths_not_starting_with_crate` lint detects fully
1627 /// qualified paths that start with a module name instead of `crate`,
1628 /// `self`, or an extern crate name
1632 /// ```rust,edition2015,compile_fail
1633 /// #![deny(absolute_paths_not_starting_with_crate)]
1648 /// Rust [editions] allow the language to evolve without breaking
1649 /// backwards compatibility. This lint catches code that uses absolute
1650 /// paths in the style of the 2015 edition. In the 2015 edition, absolute
1651 /// paths (those starting with `::`) refer to either the crate root or an
1652 /// external crate. In the 2018 edition it was changed so that they only
1653 /// refer to external crates. The path prefix `crate::` should be used
1654 /// instead to reference items from the crate root.
1656 /// If you switch the compiler from the 2015 to 2018 edition without
1657 /// updating the code, then it will fail to compile if the old style paths
1658 /// are used. You can manually change the paths to use the `crate::`
1659 /// prefix to transition to the 2018 edition.
1661 /// This lint solves the problem automatically. It is "allow" by default
1662 /// because the code is perfectly valid in the 2015 edition. The [`cargo
1663 /// fix`] tool with the `--edition` flag will switch this lint to "warn"
1664 /// and automatically apply the suggested fix from the compiler. This
1665 /// provides a completely automated way to update old code to the 2018
1668 /// [editions]: https://doc.rust-lang.org/edition-guide/
1669 /// [`cargo fix`]: https://doc.rust-lang.org/cargo/commands/cargo-fix.html
1670 pub ABSOLUTE_PATHS_NOT_STARTING_WITH_CRATE,
1672 "fully qualified paths that start with a module name \
1673 instead of `crate`, `self`, or an extern crate name",
1674 @future_incompatible = FutureIncompatibleInfo {
1675 reference: "issue #53130 <https://github.com/rust-lang/rust/issues/53130>",
1676 edition: Some(Edition::Edition2018),
1681 /// The `illegal_floating_point_literal_pattern` lint detects
1682 /// floating-point literals used in patterns.
1699 /// Previous versions of the compiler accepted floating-point literals in
1700 /// patterns, but it was later determined this was a mistake. The
1701 /// semantics of comparing floating-point values may not be clear in a
1702 /// pattern when contrasted with "structural equality". Typically you can
1703 /// work around this by using a [match guard], such as:
1709 /// y if y == 5.0 => {}
1714 /// This is a [future-incompatible] lint to transition this to a hard
1715 /// error in the future. See [issue #41620] for more details.
1717 /// [issue #41620]: https://github.com/rust-lang/rust/issues/41620
1718 /// [match guard]: https://doc.rust-lang.org/reference/expressions/match-expr.html#match-guards
1719 /// [future-incompatible]: ../index.md#future-incompatible-lints
1720 pub ILLEGAL_FLOATING_POINT_LITERAL_PATTERN,
1722 "floating-point literals cannot be used in patterns",
1723 @future_incompatible = FutureIncompatibleInfo {
1724 reference: "issue #41620 <https://github.com/rust-lang/rust/issues/41620>",
1730 /// The `unstable_name_collisions` lint detects that you have used a name
1731 /// that the standard library plans to add in the future.
1736 /// trait MyIterator : Iterator {
1737 /// // is_sorted is an unstable method that already exists on the Iterator trait
1738 /// fn is_sorted(self) -> bool where Self: Sized {true}
1741 /// impl<T: ?Sized> MyIterator for T where T: Iterator { }
1743 /// let x = vec![1, 2, 3];
1744 /// let _ = x.iter().is_sorted();
1751 /// When new methods are added to traits in the standard library, they are
1752 /// usually added in an "unstable" form which is only available on the
1753 /// [nightly channel] with a [`feature` attribute]. If there is any
1754 /// pre-existing code which extends a trait to have a method with the same
1755 /// name, then the names will collide. In the future, when the method is
1756 /// stabilized, this will cause an error due to the ambiguity. This lint
1757 /// is an early-warning to let you know that there may be a collision in
1758 /// the future. This can be avoided by adding type annotations to
1759 /// disambiguate which trait method you intend to call, such as
1760 /// `MyIterator::is_sorted(my_iter)` or renaming or removing the method.
1762 /// [nightly channel]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
1763 /// [`feature` attribute]: https://doc.rust-lang.org/nightly/unstable-book/
1764 pub UNSTABLE_NAME_COLLISIONS,
1766 "detects name collision with an existing but unstable method",
1767 @future_incompatible = FutureIncompatibleInfo {
1768 reference: "issue #48919 <https://github.com/rust-lang/rust/issues/48919>",
1770 // Note: this item represents future incompatibility of all unstable functions in the
1771 // standard library, and thus should never be removed or changed to an error.
1776 /// The `irrefutable_let_patterns` lint detects detects [irrefutable
1777 /// patterns] in [if-let] and [while-let] statements.
1784 /// if let _ = 123 {
1785 /// println!("always runs!");
1793 /// There usually isn't a reason to have an irrefutable pattern in an
1794 /// if-let or while-let statement, because the pattern will always match
1795 /// successfully. A [`let`] or [`loop`] statement will suffice. However,
1796 /// when generating code with a macro, forbidding irrefutable patterns
1797 /// would require awkward workarounds in situations where the macro
1798 /// doesn't know if the pattern is refutable or not. This lint allows
1799 /// macros to accept this form, while alerting for a possibly incorrect
1800 /// use in normal code.
1802 /// See [RFC 2086] for more details.
1804 /// [irrefutable patterns]: https://doc.rust-lang.org/reference/patterns.html#refutability
1805 /// [if-let]: https://doc.rust-lang.org/reference/expressions/if-expr.html#if-let-expressions
1806 /// [while-let]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#predicate-pattern-loops
1807 /// [`let`]: https://doc.rust-lang.org/reference/statements.html#let-statements
1808 /// [`loop`]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#infinite-loops
1809 /// [RFC 2086]: https://github.com/rust-lang/rfcs/blob/master/text/2086-allow-if-let-irrefutables.md
1810 pub IRREFUTABLE_LET_PATTERNS,
1812 "detects irrefutable patterns in if-let and while-let statements"
1816 /// The `unused_labels` lint detects [labels] that are never used.
1818 /// [labels]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#loop-labels
1823 /// 'unused_label: loop {}
1830 /// Unused labels may signal a mistake or unfinished code. To silence the
1831 /// warning for the individual label, prefix it with an underscore such as
1835 "detects labels that are never used"
1839 /// The `broken_intra_doc_links` lint detects failures in resolving
1840 /// intra-doc link targets. This is a `rustdoc` only lint, see the
1841 /// documentation in the [rustdoc book].
1843 /// [rustdoc book]: ../../../rustdoc/lints.html#broken_intra_doc_links
1844 pub BROKEN_INTRA_DOC_LINKS,
1846 "failures in resolving intra-doc link targets"
1850 /// This is a subset of `broken_intra_doc_links` that warns when linking from
1851 /// a public item to a private one. This is a `rustdoc` only lint, see the
1852 /// documentation in the [rustdoc book].
1854 /// [rustdoc book]: ../../../rustdoc/lints.html#private_intra_doc_links
1855 pub PRIVATE_INTRA_DOC_LINKS,
1857 "linking from a public item to a private one"
1861 /// The `invalid_codeblock_attributes` lint detects code block attributes
1862 /// in documentation examples that have potentially mis-typed values. This
1863 /// is a `rustdoc` only lint, see the documentation in the [rustdoc book].
1865 /// [rustdoc book]: ../../../rustdoc/lints.html#invalid_codeblock_attributes
1866 pub INVALID_CODEBLOCK_ATTRIBUTES,
1868 "codeblock attribute looks a lot like a known one"
1872 /// The `missing_crate_level_docs` lint detects if documentation is
1873 /// missing at the crate root. This is a `rustdoc` only lint, see the
1874 /// documentation in the [rustdoc book].
1876 /// [rustdoc book]: ../../../rustdoc/lints.html#missing_crate_level_docs
1877 pub MISSING_CRATE_LEVEL_DOCS,
1879 "detects crates with no crate-level documentation"
1883 /// The `missing_doc_code_examples` lint detects publicly-exported items
1884 /// without code samples in their documentation. This is a `rustdoc` only
1885 /// lint, see the documentation in the [rustdoc book].
1887 /// [rustdoc book]: ../../../rustdoc/lints.html#missing_doc_code_examples
1888 pub MISSING_DOC_CODE_EXAMPLES,
1890 "detects publicly-exported items without code samples in their documentation"
1894 /// The `private_doc_tests` lint detects code samples in docs of private
1895 /// items not documented by `rustdoc`. This is a `rustdoc` only lint, see
1896 /// the documentation in the [rustdoc book].
1898 /// [rustdoc book]: ../../../rustdoc/lints.html#private_doc_tests
1899 pub PRIVATE_DOC_TESTS,
1901 "detects code samples in docs of private items not documented by rustdoc"
1905 /// The `invalid_html_tags` lint detects invalid HTML tags. This is a
1906 /// `rustdoc` only lint, see the documentation in the [rustdoc book].
1908 /// [rustdoc book]: ../../../rustdoc/lints.html#invalid_html_tags
1909 pub INVALID_HTML_TAGS,
1911 "detects invalid HTML tags in doc comments"
1915 /// The `non_autolinks` lint detects when a URL could be written using
1916 /// only angle brackets. This is a `rustdoc` only lint, see the
1917 /// documentation in the [rustdoc book].
1919 /// [rustdoc book]: ../../../rustdoc/lints.html#non_autolinks
1922 "detects URLs that could be written using only angle brackets"
1926 /// The `where_clauses_object_safety` lint detects for [object safety] of
1927 /// [where clauses].
1929 /// [object safety]: https://doc.rust-lang.org/reference/items/traits.html#object-safety
1930 /// [where clauses]: https://doc.rust-lang.org/reference/items/generics.html#where-clauses
1937 /// trait X { fn foo(&self) where Self: Trait; }
1939 /// impl X for () { fn foo(&self) {} }
1941 /// impl Trait for dyn X {}
1943 /// // Segfault at opt-level 0, SIGILL otherwise.
1944 /// pub fn main() { <dyn X as X>::foo(&()); }
1951 /// The compiler previously allowed these object-unsafe bounds, which was
1952 /// incorrect. This is a [future-incompatible] lint to transition this to
1953 /// a hard error in the future. See [issue #51443] for more details.
1955 /// [issue #51443]: https://github.com/rust-lang/rust/issues/51443
1956 /// [future-incompatible]: ../index.md#future-incompatible-lints
1957 pub WHERE_CLAUSES_OBJECT_SAFETY,
1959 "checks the object safety of where clauses",
1960 @future_incompatible = FutureIncompatibleInfo {
1961 reference: "issue #51443 <https://github.com/rust-lang/rust/issues/51443>",
1967 /// The `proc_macro_derive_resolution_fallback` lint detects proc macro
1968 /// derives using inaccessible names from parent modules.
1972 /// ```rust,ignore (proc-macro)
1974 /// #![crate_type = "proc-macro"]
1976 /// extern crate proc_macro;
1978 /// use proc_macro::*;
1980 /// #[proc_macro_derive(Foo)]
1981 /// pub fn foo1(a: TokenStream) -> TokenStream {
1983 /// "mod __bar { static mut BAR: Option<Something> = None; }".parse().unwrap()
1987 /// ```rust,ignore (needs-dependency)
1990 /// extern crate foo;
1992 /// struct Something;
2000 /// This will produce:
2003 /// warning: cannot find type `Something` in this scope
2004 /// --> src/main.rs:8:10
2006 /// 8 | #[derive(Foo)]
2007 /// | ^^^ names from parent modules are not accessible without an explicit import
2009 /// = note: `#[warn(proc_macro_derive_resolution_fallback)]` on by default
2010 /// = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
2011 /// = note: for more information, see issue #50504 <https://github.com/rust-lang/rust/issues/50504>
2016 /// If a proc-macro generates a module, the compiler unintentionally
2017 /// allowed items in that module to refer to items in the crate root
2018 /// without importing them. This is a [future-incompatible] lint to
2019 /// transition this to a hard error in the future. See [issue #50504] for
2022 /// [issue #50504]: https://github.com/rust-lang/rust/issues/50504
2023 /// [future-incompatible]: ../index.md#future-incompatible-lints
2024 pub PROC_MACRO_DERIVE_RESOLUTION_FALLBACK,
2026 "detects proc macro derives using inaccessible names from parent modules",
2027 @future_incompatible = FutureIncompatibleInfo {
2028 reference: "issue #50504 <https://github.com/rust-lang/rust/issues/50504>",
2034 /// The `macro_use_extern_crate` lint detects the use of the
2035 /// [`macro_use` attribute].
2039 /// ```rust,ignore (needs extern crate)
2040 /// #![deny(macro_use_extern_crate)]
2043 /// extern crate serde_json;
2046 /// let _ = json!{{}};
2050 /// This will produce:
2053 /// error: deprecated `#[macro_use]` attribute used to import macros should be replaced at use sites with a `use` item to import the macro instead
2054 /// --> src/main.rs:3:1
2056 /// 3 | #[macro_use]
2059 /// note: the lint level is defined here
2060 /// --> src/main.rs:1:9
2062 /// 1 | #![deny(macro_use_extern_crate)]
2063 /// | ^^^^^^^^^^^^^^^^^^^^^^
2068 /// The [`macro_use` attribute] on an [`extern crate`] item causes
2069 /// macros in that external crate to be brought into the prelude of the
2070 /// crate, making the macros in scope everywhere. As part of the efforts
2071 /// to simplify handling of dependencies in the [2018 edition], the use of
2072 /// `extern crate` is being phased out. To bring macros from extern crates
2073 /// into scope, it is recommended to use a [`use` import].
2075 /// This lint is "allow" by default because this is a stylistic choice
2076 /// that has not been settled, see [issue #52043] for more information.
2078 /// [`macro_use` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#the-macro_use-attribute
2079 /// [`use` import]: https://doc.rust-lang.org/reference/items/use-declarations.html
2080 /// [issue #52043]: https://github.com/rust-lang/rust/issues/52043
2081 pub MACRO_USE_EXTERN_CRATE,
2083 "the `#[macro_use]` attribute is now deprecated in favor of using macros \
2084 via the module system"
2088 /// The `macro_expanded_macro_exports_accessed_by_absolute_paths` lint
2089 /// detects macro-expanded [`macro_export`] macros from the current crate
2090 /// that cannot be referred to by absolute paths.
2092 /// [`macro_export`]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
2096 /// ```rust,compile_fail
2097 /// macro_rules! define_exported {
2100 /// macro_rules! exported {
2106 /// define_exported!();
2109 /// crate::exported!();
2117 /// The intent is that all macros marked with the `#[macro_export]`
2118 /// attribute are made available in the root of the crate. However, when a
2119 /// `macro_rules!` definition is generated by another macro, the macro
2120 /// expansion is unable to uphold this rule. This is a
2121 /// [future-incompatible] lint to transition this to a hard error in the
2122 /// future. See [issue #53495] for more details.
2124 /// [issue #53495]: https://github.com/rust-lang/rust/issues/53495
2125 /// [future-incompatible]: ../index.md#future-incompatible-lints
2126 pub MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS,
2128 "macro-expanded `macro_export` macros from the current crate \
2129 cannot be referred to by absolute paths",
2130 @future_incompatible = FutureIncompatibleInfo {
2131 reference: "issue #52234 <https://github.com/rust-lang/rust/issues/52234>",
2138 /// The `explicit_outlives_requirements` lint detects unnecessary
2139 /// lifetime bounds that can be inferred.
2143 /// ```rust,compile_fail
2144 /// # #![allow(unused)]
2145 /// #![deny(explicit_outlives_requirements)]
2147 /// struct SharedRef<'a, T>
2159 /// If a `struct` contains a reference, such as `&'a T`, the compiler
2160 /// requires that `T` outlives the lifetime `'a`. This historically
2161 /// required writing an explicit lifetime bound to indicate this
2162 /// requirement. However, this can be overly explicit, causing clutter and
2163 /// unnecessary complexity. The language was changed to automatically
2164 /// infer the bound if it is not specified. Specifically, if the struct
2165 /// contains a reference, directly or indirectly, to `T` with lifetime
2166 /// `'x`, then it will infer that `T: 'x` is a requirement.
2168 /// This lint is "allow" by default because it can be noisy for existing
2169 /// code that already had these requirements. This is a stylistic choice,
2170 /// as it is still valid to explicitly state the bound. It also has some
2171 /// false positives that can cause confusion.
2173 /// See [RFC 2093] for more details.
2175 /// [RFC 2093]: https://github.com/rust-lang/rfcs/blob/master/text/2093-infer-outlives.md
2176 pub EXPLICIT_OUTLIVES_REQUIREMENTS,
2178 "outlives requirements can be inferred"
2182 /// The `indirect_structural_match` lint detects a `const` in a pattern
2183 /// that manually implements [`PartialEq`] and [`Eq`].
2185 /// [`PartialEq`]: https://doc.rust-lang.org/std/cmp/trait.PartialEq.html
2186 /// [`Eq`]: https://doc.rust-lang.org/std/cmp/trait.Eq.html
2190 /// ```rust,compile_fail
2191 /// #![deny(indirect_structural_match)]
2193 /// struct NoDerive(i32);
2194 /// impl PartialEq for NoDerive { fn eq(&self, _: &Self) -> bool { false } }
2195 /// impl Eq for NoDerive { }
2196 /// #[derive(PartialEq, Eq)]
2197 /// struct WrapParam<T>(T);
2198 /// const WRAP_INDIRECT_PARAM: & &WrapParam<NoDerive> = & &WrapParam(NoDerive(0));
2200 /// match WRAP_INDIRECT_PARAM {
2201 /// WRAP_INDIRECT_PARAM => { }
2211 /// The compiler unintentionally accepted this form in the past. This is a
2212 /// [future-incompatible] lint to transition this to a hard error in the
2213 /// future. See [issue #62411] for a complete description of the problem,
2214 /// and some possible solutions.
2216 /// [issue #62411]: https://github.com/rust-lang/rust/issues/62411
2217 /// [future-incompatible]: ../index.md#future-incompatible-lints
2218 pub INDIRECT_STRUCTURAL_MATCH,
2220 "constant used in pattern contains value of non-structural-match type in a field or a variant",
2221 @future_incompatible = FutureIncompatibleInfo {
2222 reference: "issue #62411 <https://github.com/rust-lang/rust/issues/62411>",
2228 /// The `deprecated_in_future` lint is internal to rustc and should not be
2229 /// used by user code.
2231 /// This lint is only enabled in the standard library. It works with the
2232 /// use of `#[rustc_deprecated]` with a `since` field of a version in the
2233 /// future. This allows something to be marked as deprecated in a future
2234 /// version, and then this lint will ensure that the item is no longer
2235 /// used in the standard library. See the [stability documentation] for
2238 /// [stability documentation]: https://rustc-dev-guide.rust-lang.org/stability.html#rustc_deprecated
2239 pub DEPRECATED_IN_FUTURE,
2241 "detects use of items that will be deprecated in a future version",
2242 report_in_external_macro
2246 /// The `pointer_structural_match` lint detects pointers used in patterns whose behaviour
2247 /// cannot be relied upon across compiler versions and optimization levels.
2251 /// ```rust,compile_fail
2252 /// #![deny(pointer_structural_match)]
2253 /// fn foo(a: usize, b: usize) -> usize { a + b }
2254 /// const FOO: fn(usize, usize) -> usize = foo;
2267 /// Previous versions of Rust allowed function pointers and wide raw pointers in patterns.
2268 /// While these work in many cases as expected by users, it is possible that due to
2269 /// optimizations pointers are "not equal to themselves" or pointers to different functions
2270 /// compare as equal during runtime. This is because LLVM optimizations can deduplicate
2271 /// functions if their bodies are the same, thus also making pointers to these functions point
2272 /// to the same location. Additionally functions may get duplicated if they are instantiated
2273 /// in different crates and not deduplicated again via LTO.
2274 pub POINTER_STRUCTURAL_MATCH,
2276 "pointers are not structural-match",
2277 @future_incompatible = FutureIncompatibleInfo {
2278 reference: "issue #62411 <https://github.com/rust-lang/rust/issues/70861>",
2284 /// The `nontrivial_structural_match` lint detects constants that are used in patterns,
2285 /// whose type is not structural-match and whose initializer body actually uses values
2286 /// that are not structural-match. So `Option<NotStruturalMatch>` is ok if the constant
2291 /// ```rust,compile_fail
2292 /// #![deny(nontrivial_structural_match)]
2294 /// #[derive(Copy, Clone, Debug)]
2295 /// struct NoDerive(u32);
2296 /// impl PartialEq for NoDerive { fn eq(&self, _: &Self) -> bool { false } }
2297 /// impl Eq for NoDerive { }
2299 /// const INDEX: Option<NoDerive> = [None, Some(NoDerive(10))][0];
2300 /// match None { Some(_) => panic!("whoops"), INDEX => dbg!(INDEX), };
2308 /// Previous versions of Rust accepted constants in patterns, even if those constants's types
2309 /// did not have `PartialEq` derived. Thus the compiler falls back to runtime execution of
2310 /// `PartialEq`, which can report that two constants are not equal even if they are
2312 pub NONTRIVIAL_STRUCTURAL_MATCH,
2314 "constant used in pattern of non-structural-match type and the constant's initializer \
2315 expression contains values of non-structural-match types",
2316 @future_incompatible = FutureIncompatibleInfo {
2317 reference: "issue #73448 <https://github.com/rust-lang/rust/issues/73448>",
2323 /// The `ambiguous_associated_items` lint detects ambiguity between
2324 /// [associated items] and [enum variants].
2326 /// [associated items]: https://doc.rust-lang.org/reference/items/associated-items.html
2327 /// [enum variants]: https://doc.rust-lang.org/reference/items/enumerations.html
2331 /// ```rust,compile_fail
2338 /// fn foo() -> Self::V;
2343 /// // `Self::V` is ambiguous because it may refer to the associated type or
2344 /// // the enum variant.
2345 /// fn foo() -> Self::V { 0 }
2353 /// Previous versions of Rust did not allow accessing enum variants
2354 /// through [type aliases]. When this ability was added (see [RFC 2338]), this
2355 /// introduced some situations where it can be ambiguous what a type
2356 /// was referring to.
2358 /// To fix this ambiguity, you should use a [qualified path] to explicitly
2359 /// state which type to use. For example, in the above example the
2360 /// function can be written as `fn f() -> <Self as Tr>::V { 0 }` to
2361 /// specifically refer to the associated type.
2363 /// This is a [future-incompatible] lint to transition this to a hard
2364 /// error in the future. See [issue #57644] for more details.
2366 /// [issue #57644]: https://github.com/rust-lang/rust/issues/57644
2367 /// [type aliases]: https://doc.rust-lang.org/reference/items/type-aliases.html#type-aliases
2368 /// [RFC 2338]: https://github.com/rust-lang/rfcs/blob/master/text/2338-type-alias-enum-variants.md
2369 /// [qualified path]: https://doc.rust-lang.org/reference/paths.html#qualified-paths
2370 /// [future-incompatible]: ../index.md#future-incompatible-lints
2371 pub AMBIGUOUS_ASSOCIATED_ITEMS,
2373 "ambiguous associated items",
2374 @future_incompatible = FutureIncompatibleInfo {
2375 reference: "issue #57644 <https://github.com/rust-lang/rust/issues/57644>",
2381 /// The `mutable_borrow_reservation_conflict` lint detects the reservation
2382 /// of a two-phased borrow that conflicts with other shared borrows.
2387 /// let mut v = vec![0, 1, 2];
2388 /// let shared = &v;
2389 /// v.push(shared.len());
2396 /// This is a [future-incompatible] lint to transition this to a hard error
2397 /// in the future. See [issue #59159] for a complete description of the
2398 /// problem, and some possible solutions.
2400 /// [issue #59159]: https://github.com/rust-lang/rust/issues/59159
2401 /// [future-incompatible]: ../index.md#future-incompatible-lints
2402 pub MUTABLE_BORROW_RESERVATION_CONFLICT,
2404 "reservation of a two-phased borrow conflicts with other shared borrows",
2405 @future_incompatible = FutureIncompatibleInfo {
2406 reference: "issue #59159 <https://github.com/rust-lang/rust/issues/59159>",
2412 /// The `soft_unstable` lint detects unstable features that were
2413 /// unintentionally allowed on stable.
2417 /// ```rust,compile_fail
2419 /// extern crate test;
2422 /// fn name(b: &mut test::Bencher) {
2431 /// The [`bench` attribute] was accidentally allowed to be specified on
2432 /// the [stable release channel]. Turning this to a hard error would have
2433 /// broken some projects. This lint allows those projects to continue to
2434 /// build correctly when [`--cap-lints`] is used, but otherwise signal an
2435 /// error that `#[bench]` should not be used on the stable channel. This
2436 /// is a [future-incompatible] lint to transition this to a hard error in
2437 /// the future. See [issue #64266] for more details.
2439 /// [issue #64266]: https://github.com/rust-lang/rust/issues/64266
2440 /// [`bench` attribute]: https://doc.rust-lang.org/nightly/unstable-book/library-features/test.html
2441 /// [stable release channel]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
2442 /// [`--cap-lints`]: https://doc.rust-lang.org/rustc/lints/levels.html#capping-lints
2443 /// [future-incompatible]: ../index.md#future-incompatible-lints
2446 "a feature gate that doesn't break dependent crates",
2447 @future_incompatible = FutureIncompatibleInfo {
2448 reference: "issue #64266 <https://github.com/rust-lang/rust/issues/64266>",
2454 /// The `inline_no_sanitize` lint detects incompatible use of
2455 /// [`#[inline(always)]`][inline] and [`#[no_sanitize(...)]`][no_sanitize].
2457 /// [inline]: https://doc.rust-lang.org/reference/attributes/codegen.html#the-inline-attribute
2458 /// [no_sanitize]: https://doc.rust-lang.org/nightly/unstable-book/language-features/no-sanitize.html
2463 /// #![feature(no_sanitize)]
2465 /// #[inline(always)]
2466 /// #[no_sanitize(address)]
2478 /// The use of the [`#[inline(always)]`][inline] attribute prevents the
2479 /// the [`#[no_sanitize(...)]`][no_sanitize] attribute from working.
2480 /// Consider temporarily removing `inline` attribute.
2481 pub INLINE_NO_SANITIZE,
2483 "detects incompatible use of `#[inline(always)]` and `#[no_sanitize(...)]`",
2487 /// The `asm_sub_register` lint detects using only a subset of a register
2488 /// for inline asm inputs.
2492 /// ```rust,ignore (fails on system llvm)
2493 /// #![feature(asm)]
2496 /// #[cfg(target_arch="x86_64")]
2498 /// asm!("mov {0}, {0}", in(reg) 0i16);
2503 /// This will produce:
2506 /// warning: formatting may not be suitable for sub-register argument
2507 /// --> src/main.rs:6:19
2509 /// 6 | asm!("mov {0}, {0}", in(reg) 0i16);
2510 /// | ^^^ ^^^ ---- for this argument
2512 /// = note: `#[warn(asm_sub_register)]` on by default
2513 /// = help: use the `x` modifier to have the register formatted as `ax`
2514 /// = help: or use the `r` modifier to keep the default formatting of `rax`
2519 /// Registers on some architectures can use different names to refer to a
2520 /// subset of the register. By default, the compiler will use the name for
2521 /// the full register size. To explicitly use a subset of the register,
2522 /// you can override the default by using a modifier on the template
2523 /// string operand to specify when subregister to use. This lint is issued
2524 /// if you pass in a value with a smaller data type than the default
2525 /// register size, to alert you of possibly using the incorrect width. To
2526 /// fix this, add the suggested modifier to the template, or cast the
2527 /// value to the correct size.
2529 /// See [register template modifiers] for more details.
2531 /// [register template modifiers]: https://doc.rust-lang.org/nightly/unstable-book/library-features/asm.html#register-template-modifiers
2532 pub ASM_SUB_REGISTER,
2534 "using only a subset of a register for inline asm inputs",
2538 /// The `unsafe_op_in_unsafe_fn` lint detects unsafe operations in unsafe
2539 /// functions without an explicit unsafe block. This lint only works on
2540 /// the [**nightly channel**] with the
2541 /// `#![feature(unsafe_block_in_unsafe_fn)]` feature.
2543 /// [**nightly channel**]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
2547 /// ```rust,compile_fail
2548 /// #![feature(unsafe_block_in_unsafe_fn)]
2549 /// #![deny(unsafe_op_in_unsafe_fn)]
2551 /// unsafe fn foo() {}
2553 /// unsafe fn bar() {
2564 /// Currently, an [`unsafe fn`] allows any [unsafe] operation within its
2565 /// body. However, this can increase the surface area of code that needs
2566 /// to be scrutinized for proper behavior. The [`unsafe` block] provides a
2567 /// convenient way to make it clear exactly which parts of the code are
2568 /// performing unsafe operations. In the future, it is desired to change
2569 /// it so that unsafe operations cannot be performed in an `unsafe fn`
2570 /// without an `unsafe` block.
2572 /// The fix to this is to wrap the unsafe code in an `unsafe` block.
2574 /// This lint is "allow" by default because it has not yet been
2575 /// stabilized, and is not yet complete. See [RFC #2585] and [issue
2576 /// #71668] for more details
2578 /// [`unsafe fn`]: https://doc.rust-lang.org/reference/unsafe-functions.html
2579 /// [`unsafe` block]: https://doc.rust-lang.org/reference/expressions/block-expr.html#unsafe-blocks
2580 /// [unsafe]: https://doc.rust-lang.org/reference/unsafety.html
2581 /// [RFC #2585]: https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md
2582 /// [issue #71668]: https://github.com/rust-lang/rust/issues/71668
2583 pub UNSAFE_OP_IN_UNSAFE_FN,
2585 "unsafe operations in unsafe functions without an explicit unsafe block are deprecated",
2586 @feature_gate = sym::unsafe_block_in_unsafe_fn;
2590 /// The `cenum_impl_drop_cast` lint detects an `as` cast of a field-less
2591 /// `enum` that implements [`Drop`].
2593 /// [`Drop`]: https://doc.rust-lang.org/std/ops/trait.Drop.html
2598 /// # #![allow(unused)]
2603 /// impl Drop for E {
2604 /// fn drop(&mut self) {
2605 /// println!("Drop");
2611 /// let i = e as u32;
2619 /// Casting a field-less `enum` that does not implement [`Copy`] to an
2620 /// integer moves the value without calling `drop`. This can result in
2621 /// surprising behavior if it was expected that `drop` should be called.
2622 /// Calling `drop` automatically would be inconsistent with other move
2623 /// operations. Since neither behavior is clear or consistent, it was
2624 /// decided that a cast of this nature will no longer be allowed.
2626 /// This is a [future-incompatible] lint to transition this to a hard error
2627 /// in the future. See [issue #73333] for more details.
2629 /// [future-incompatible]: ../index.md#future-incompatible-lints
2630 /// [issue #73333]: https://github.com/rust-lang/rust/issues/73333
2631 /// [`Copy`]: https://doc.rust-lang.org/std/marker/trait.Copy.html
2632 pub CENUM_IMPL_DROP_CAST,
2634 "a C-like enum implementing Drop is cast",
2635 @future_incompatible = FutureIncompatibleInfo {
2636 reference: "issue #73333 <https://github.com/rust-lang/rust/issues/73333>",
2642 /// The `const_evaluatable_unchecked` lint detects a generic constant used
2648 /// const fn foo<T>() -> usize {
2649 /// if std::mem::size_of::<*mut T>() < 8 { // size of *mut T does not depend on T
2657 /// let _ = [0; foo::<T>()];
2665 /// In the 1.43 release, some uses of generic parameters in array repeat
2666 /// expressions were accidentally allowed. This is a [future-incompatible]
2667 /// lint to transition this to a hard error in the future. See [issue
2668 /// #76200] for a more detailed description and possible fixes.
2670 /// [future-incompatible]: ../index.md#future-incompatible-lints
2671 /// [issue #76200]: https://github.com/rust-lang/rust/issues/76200
2672 pub CONST_EVALUATABLE_UNCHECKED,
2674 "detects a generic constant is used in a type without a emitting a warning",
2675 @future_incompatible = FutureIncompatibleInfo {
2676 reference: "issue #76200 <https://github.com/rust-lang/rust/issues/76200>",
2682 /// The `function_item_references` lint detects function references that are
2683 /// formatted with [`fmt::Pointer`] or transmuted.
2685 /// [`fmt::Pointer`]: https://doc.rust-lang.org/std/fmt/trait.Pointer.html
2693 /// println!("{:p}", &foo);
2701 /// Taking a reference to a function may be mistaken as a way to obtain a
2702 /// pointer to that function. This can give unexpected results when
2703 /// formatting the reference as a pointer or transmuting it. This lint is
2704 /// issued when function references are formatted as pointers, passed as
2705 /// arguments bound by [`fmt::Pointer`] or transmuted.
2706 pub FUNCTION_ITEM_REFERENCES,
2708 "suggest casting to a function pointer when attempting to take references to function items",
2712 /// The `uninhabited_static` lint detects uninhabited statics.
2719 /// static EXTERN: Void;
2727 /// Statics with an uninhabited type can never be initialized, so they are impossible to define.
2728 /// However, this can be side-stepped with an `extern static`, leading to problems later in the
2729 /// compiler which assumes that there are no initialized uninhabited places (such as locals or
2730 /// statics). This was accientally allowed, but is being phased out.
2731 pub UNINHABITED_STATIC,
2733 "uninhabited static",
2734 @future_incompatible = FutureIncompatibleInfo {
2735 reference: "issue #74840 <https://github.com/rust-lang/rust/issues/74840>",
2741 /// The `useless_deprecated` lint detects deprecation attributes with no effect.
2745 /// ```rust,compile_fail
2748 /// #[deprecated = "message"]
2749 /// impl Default for X {
2750 /// fn default() -> Self {
2760 /// Deprecation attributes have no effect on trait implementations.
2761 pub USELESS_DEPRECATED,
2763 "detects deprecation attributes with no effect",
2767 /// The `unsupported_naked_functions` lint detects naked function
2768 /// definitions that are unsupported but were previously accepted.
2773 /// #![feature(naked_functions)]
2776 /// pub fn f() -> u32 {
2785 /// The naked functions must be defined using a single inline assembly
2788 /// The execution must never fall through past the end of the assembly
2789 /// code so the block must use `noreturn` option. The asm block can also
2790 /// use `att_syntax` option, but other options are not allowed.
2792 /// The asm block must not contain any operands other than `const` and
2793 /// `sym`. Additionally, naked function should specify a non-Rust ABI.
2795 /// While other definitions of naked functions were previously accepted,
2796 /// they are unsupported and might not work reliably. This is a
2797 /// [future-incompatible] lint that will transition into hard error in
2800 /// [future-incompatible]: ../index.md#future-incompatible-lints
2801 pub UNSUPPORTED_NAKED_FUNCTIONS,
2803 "unsupported naked function definitions",
2804 @future_incompatible = FutureIncompatibleInfo {
2805 reference: "issue #32408 <https://github.com/rust-lang/rust/issues/32408>",
2811 /// The `ineffective_unstable_trait_impl` lint detects `#[unstable]` attributes which are not used.
2816 /// #![feature(staged_api)]
2818 /// #[derive(Clone)]
2819 /// #[stable(feature = "x", since = "1")]
2822 /// #[unstable(feature = "y", issue = "none")]
2823 /// impl Copy for S {}
2830 /// `staged_api` does not currently support using a stability attribute on `impl` blocks.
2831 /// `impl`s are always stable if both the type and trait are stable, and always unstable otherwise.
2832 pub INEFFECTIVE_UNSTABLE_TRAIT_IMPL,
2834 "detects `#[unstable]` on stable trait implementations for stable types"
2838 /// The `semicolon_in_expressions_from_macros` lint detects trailing semicolons
2839 /// in macro bodies when the macro is invoked in expression position.
2840 /// This was previous accepted, but is being phased out.
2844 /// ```rust,compile_fail
2845 /// #![deny(semicolon_in_expressions_from_macros)]
2846 /// macro_rules! foo {
2851 /// let val = match true {
2862 /// Previous, Rust ignored trailing semicolon in a macro
2863 /// body when a macro was invoked in expression position.
2864 /// However, this makes the treatment of semicolons in the language
2865 /// inconsistent, and could lead to unexpected runtime behavior
2866 /// in some circumstances (e.g. if the macro author expects
2867 /// a value to be dropped).
2869 /// This is a [future-incompatible] lint to transition this
2870 /// to a hard error in the future. See [issue #79813] for more details.
2872 /// [issue #79813]: https://github.com/rust-lang/rust/issues/79813
2873 /// [future-incompatible]: ../index.md#future-incompatible-lints
2874 pub SEMICOLON_IN_EXPRESSIONS_FROM_MACROS,
2876 "trailing semicolon in macro body used as expression",
2877 @future_incompatible = FutureIncompatibleInfo {
2878 reference: "issue #79813 <https://github.com/rust-lang/rust/issues/79813>",
2883 declare_lint_pass! {
2884 /// Does nothing as a lint pass, but registers some `Lint`s
2885 /// that are used by other parts of the compiler.
2887 ILLEGAL_FLOATING_POINT_LITERAL_PATTERN,
2888 ARITHMETIC_OVERFLOW,
2889 UNCONDITIONAL_PANIC,
2891 UNUSED_EXTERN_CRATES,
2892 UNUSED_CRATE_DEPENDENCIES,
2893 UNUSED_QUALIFICATIONS,
2899 UNREACHABLE_PATTERNS,
2900 OVERLAPPING_RANGE_ENDPOINTS,
2901 BINDINGS_WITH_VARIANT_NAME,
2906 UNKNOWN_CRATE_TYPES,
2908 TRIVIAL_NUMERIC_CASTS,
2910 EXPORTED_PRIVATE_DEPENDENCIES,
2911 PUB_USE_OF_PRIVATE_EXTERN_CRATE,
2912 INVALID_TYPE_PARAM_DEFAULT,
2914 RENAMED_AND_REMOVED_LINTS,
2915 UNALIGNED_REFERENCES,
2916 CONST_ITEM_MUTATION,
2917 SAFE_PACKED_BORROWS,
2918 PATTERNS_IN_FNS_WITHOUT_BODY,
2919 MISSING_FRAGMENT_SPECIFIER,
2920 LATE_BOUND_LIFETIME_ARGUMENTS,
2921 ORDER_DEPENDENT_TRAIT_OBJECTS,
2922 COHERENCE_LEAK_CHECK,
2926 UNCONDITIONAL_RECURSION,
2927 SINGLE_USE_LIFETIMES,
2930 TYVAR_BEHIND_RAW_POINTER,
2931 ELIDED_LIFETIMES_IN_PATHS,
2933 ABSOLUTE_PATHS_NOT_STARTING_WITH_CRATE,
2934 UNSTABLE_NAME_COLLISIONS,
2935 IRREFUTABLE_LET_PATTERNS,
2936 BROKEN_INTRA_DOC_LINKS,
2937 PRIVATE_INTRA_DOC_LINKS,
2938 INVALID_CODEBLOCK_ATTRIBUTES,
2939 MISSING_CRATE_LEVEL_DOCS,
2940 MISSING_DOC_CODE_EXAMPLES,
2944 WHERE_CLAUSES_OBJECT_SAFETY,
2945 PROC_MACRO_DERIVE_RESOLUTION_FALLBACK,
2946 MACRO_USE_EXTERN_CRATE,
2947 MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS,
2948 ILL_FORMED_ATTRIBUTE_INPUT,
2949 CONFLICTING_REPR_HINTS,
2950 META_VARIABLE_MISUSE,
2951 DEPRECATED_IN_FUTURE,
2952 AMBIGUOUS_ASSOCIATED_ITEMS,
2953 MUTABLE_BORROW_RESERVATION_CONFLICT,
2954 INDIRECT_STRUCTURAL_MATCH,
2955 POINTER_STRUCTURAL_MATCH,
2956 NONTRIVIAL_STRUCTURAL_MATCH,
2960 UNSAFE_OP_IN_UNSAFE_FN,
2962 CENUM_IMPL_DROP_CAST,
2963 CONST_EVALUATABLE_UNCHECKED,
2964 INEFFECTIVE_UNSTABLE_TRAIT_IMPL,
2966 FUNCTION_ITEM_REFERENCES,
2968 UNSUPPORTED_NAKED_FUNCTIONS,
2970 SEMICOLON_IN_EXPRESSIONS_FROM_MACROS,
2975 /// The `unused_doc_comments` lint detects doc comments that aren't used
2989 /// `rustdoc` does not use doc comments in all positions, and so the doc
2990 /// comment will be ignored. Try changing it to a normal comment with `//`
2991 /// to avoid the warning.
2992 pub UNUSED_DOC_COMMENTS,
2994 "detects doc comments that aren't used by rustdoc"
2997 declare_lint_pass!(UnusedDocComment => [UNUSED_DOC_COMMENTS]);
3000 /// The `missing_abi` lint detects cases where the ABI is omitted from
3001 /// extern declarations.
3005 /// ```rust,compile_fail
3006 /// #![deny(missing_abi)]
3008 /// extern fn foo() {}
3015 /// Historically, Rust implicitly selected C as the ABI for extern
3016 /// declarations. We expect to add new ABIs, like `C-unwind`, in the future,
3017 /// though this has not yet happened, and especially with their addition
3018 /// seeing the ABI easily will make code review easier.
3021 "No declared ABI for extern declaration"