1 // ignore-tidy-filelength
3 //! Some lints that are built in to the compiler.
5 //! These are the built-in lints that are emitted direct in the main
6 //! compiler code, rather than using their own custom pass. Those
7 //! lints are all available in `rustc_lint::builtin`.
9 use crate::{declare_lint, declare_lint_pass, FutureIncompatibilityReason}
;
10 use rustc_span
::edition
::Edition
;
13 /// The `forbidden_lint_groups` lint detects violations of
14 /// `forbid` applied to a lint group. Due to a bug in the compiler,
15 /// these used to be overlooked entirely. They now generate a warning.
20 /// #![forbid(warnings)]
21 /// #![deny(bad_style)]
28 /// ### Recommended fix
30 /// If your crate is using `#![forbid(warnings)]`,
31 /// we recommend that you change to `#![deny(warnings)]`.
35 /// Due to a compiler bug, applying `forbid` to lint groups
36 /// previously had no effect. The bug is now fixed but instead of
37 /// enforcing `forbid` we issue this future-compatibility warning
38 /// to avoid breaking existing crates.
39 pub FORBIDDEN_LINT_GROUPS
,
41 "applying forbid to lint-groups",
42 @future_incompatible
= FutureIncompatibleInfo
{
43 reference
: "issue #81670 <https://github.com/rust-lang/rust/issues/81670>",
48 /// The `ill_formed_attribute_input` lint detects ill-formed attribute
49 /// inputs that were previously accepted and used in practice.
53 /// ```rust,compile_fail
54 /// #[inline = "this is not valid"]
62 /// Previously, inputs for many built-in attributes weren't validated and
63 /// nonsensical attribute inputs were accepted. After validation was
64 /// added, it was determined that some existing projects made use of these
65 /// invalid forms. This is a [future-incompatible] lint to transition this
66 /// to a hard error in the future. See [issue #57571] for more details.
68 /// Check the [attribute reference] for details on the valid inputs for
71 /// [issue #57571]: https://github.com/rust-lang/rust/issues/57571
72 /// [attribute reference]: https://doc.rust-lang.org/nightly/reference/attributes.html
73 /// [future-incompatible]: ../index.md#future-incompatible-lints
74 pub ILL_FORMED_ATTRIBUTE_INPUT
,
76 "ill-formed attribute inputs that were previously accepted and used in practice",
77 @future_incompatible
= FutureIncompatibleInfo
{
78 reference
: "issue #57571 <https://github.com/rust-lang/rust/issues/57571>",
84 /// The `conflicting_repr_hints` lint detects [`repr` attributes] with
85 /// conflicting hints.
87 /// [`repr` attributes]: https://doc.rust-lang.org/reference/type-layout.html#representations
91 /// ```rust,compile_fail
102 /// The compiler incorrectly accepted these conflicting representations in
103 /// the past. This is a [future-incompatible] lint to transition this to a
104 /// hard error in the future. See [issue #68585] for more details.
106 /// To correct the issue, remove one of the conflicting hints.
108 /// [issue #68585]: https://github.com/rust-lang/rust/issues/68585
109 /// [future-incompatible]: ../index.md#future-incompatible-lints
110 pub CONFLICTING_REPR_HINTS
,
112 "conflicts between `#[repr(..)]` hints that were previously accepted and used in practice",
113 @future_incompatible
= FutureIncompatibleInfo
{
114 reference
: "issue #68585 <https://github.com/rust-lang/rust/issues/68585>",
119 /// The `meta_variable_misuse` lint detects possible meta-variable misuse
120 /// in macro definitions.
124 /// ```rust,compile_fail
125 /// #![deny(meta_variable_misuse)]
127 /// macro_rules! foo {
129 /// ($( $i:ident = $($j:ident),+ );*) => { $( $( $i = $k; )+ )* };
141 /// There are quite a few different ways a [`macro_rules`] macro can be
142 /// improperly defined. Many of these errors were previously only detected
143 /// when the macro was expanded or not at all. This lint is an attempt to
144 /// catch some of these problems when the macro is *defined*.
146 /// This lint is "allow" by default because it may have false positives
147 /// and other issues. See [issue #61053] for more details.
149 /// [`macro_rules`]: https://doc.rust-lang.org/reference/macros-by-example.html
150 /// [issue #61053]: https://github.com/rust-lang/rust/issues/61053
151 pub META_VARIABLE_MISUSE
,
153 "possible meta-variable misuse at macro definition"
157 /// The `incomplete_include` lint detects the use of the [`include!`]
158 /// macro with a file that contains more than one expression.
160 /// [`include!`]: https://doc.rust-lang.org/std/macro.include.html
164 /// ```rust,ignore (needs separate file)
166 /// include!("foo.txt");
170 /// where the file `foo.txt` contains:
179 /// error: include macro expected single expression in source
182 /// 1 | println!("1");
185 /// = note: `#[deny(incomplete_include)]` on by default
190 /// The [`include!`] macro is currently only intended to be used to
191 /// include a single [expression] or multiple [items]. Historically it
192 /// would ignore any contents after the first expression, but that can be
193 /// confusing. In the example above, the `println!` expression ends just
194 /// before the semicolon, making the semicolon "extra" information that is
195 /// ignored. Perhaps even more surprising, if the included file had
196 /// multiple print statements, the subsequent ones would be ignored!
198 /// One workaround is to place the contents in braces to create a [block
199 /// expression]. Also consider alternatives, like using functions to
200 /// encapsulate the expressions, or use [proc-macros].
202 /// This is a lint instead of a hard error because existing projects were
203 /// found to hit this error. To be cautious, it is a lint for now. The
204 /// future semantics of the `include!` macro are also uncertain, see
207 /// [items]: https://doc.rust-lang.org/reference/items.html
208 /// [expression]: https://doc.rust-lang.org/reference/expressions.html
209 /// [block expression]: https://doc.rust-lang.org/reference/expressions/block-expr.html
210 /// [proc-macros]: https://doc.rust-lang.org/reference/procedural-macros.html
211 /// [issue #35560]: https://github.com/rust-lang/rust/issues/35560
212 pub INCOMPLETE_INCLUDE
,
214 "trailing content in included file"
218 /// The `arithmetic_overflow` lint detects that an arithmetic operation
221 /// [overflow]: https://doc.rust-lang.org/reference/expressions/operator-expr.html#overflow
225 /// ```rust,compile_fail
233 /// It is very likely a mistake to perform an arithmetic operation that
234 /// overflows its value. If the compiler is able to detect these kinds of
235 /// overflows at compile-time, it will trigger this lint. Consider
236 /// adjusting the expression to avoid overflow, or use a data type that
237 /// will not overflow.
238 pub ARITHMETIC_OVERFLOW
,
240 "arithmetic operation overflows"
244 /// The `unconditional_panic` lint detects an operation that will cause a
245 /// panic at runtime.
249 /// ```rust,compile_fail
250 /// # #![allow(unused)]
258 /// This lint detects code that is very likely incorrect because it will
259 /// always panic, such as division by zero and out-of-bounds array
260 /// accesses. Consider adjusting your code if this is a bug, or using the
261 /// `panic!` or `unreachable!` macro instead in case the panic is intended.
262 pub UNCONDITIONAL_PANIC
,
264 "operation will cause a panic at runtime"
268 /// The `const_err` lint detects an erroneous expression while doing
269 /// constant evaluation.
273 /// ```rust,compile_fail
274 /// #![allow(unconditional_panic)]
275 /// const C: i32 = 1/0;
282 /// This lint detects constants that fail to evaluate. Allowing the lint will accept the
283 /// constant declaration, but any use of this constant will still lead to a hard error. This is
284 /// a future incompatibility lint; the plan is to eventually entirely forbid even declaring
285 /// constants that cannot be evaluated. See [issue #71800] for more details.
287 /// [issue #71800]: https://github.com/rust-lang/rust/issues/71800
290 "constant evaluation encountered erroneous expression",
291 @future_incompatible
= FutureIncompatibleInfo
{
292 reference
: "issue #71800 <https://github.com/rust-lang/rust/issues/71800>",
294 report_in_external_macro
298 /// The `unused_imports` lint detects imports that are never used.
303 /// use std::collections::HashMap;
310 /// Unused imports may signal a mistake or unfinished code, and clutter
311 /// the code, and should be removed. If you intended to re-export the item
312 /// to make it available outside of the module, add a visibility modifier
316 "imports that are never used"
320 /// The `unused_extern_crates` lint guards against `extern crate` items
321 /// that are never used.
325 /// ```rust,compile_fail
326 /// #![deny(unused_extern_crates)]
327 /// extern crate proc_macro;
334 /// `extern crate` items that are unused have no effect and should be
335 /// removed. Note that there are some cases where specifying an `extern
336 /// crate` is desired for the side effect of ensuring the given crate is
337 /// linked, even though it is not otherwise directly referenced. The lint
338 /// can be silenced by aliasing the crate to an underscore, such as
339 /// `extern crate foo as _`. Also note that it is no longer idiomatic to
340 /// use `extern crate` in the [2018 edition], as extern crates are now
341 /// automatically added in scope.
343 /// This lint is "allow" by default because it can be noisy, and produce
344 /// false-positives. If a dependency is being removed from a project, it
345 /// is recommended to remove it from the build configuration (such as
346 /// `Cargo.toml`) to ensure stale build entries aren't left behind.
348 /// [2018 edition]: https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html#no-more-extern-crate
349 pub UNUSED_EXTERN_CRATES
,
351 "extern crates that are never used"
355 /// The `unused_crate_dependencies` lint detects crate dependencies that
360 /// ```rust,ignore (needs extern crate)
361 /// #![deny(unused_crate_dependencies)]
364 /// This will produce:
367 /// error: external crate `regex` unused in `lint_example`: remove the dependency or add `use regex as _;`
369 /// note: the lint level is defined here
370 /// --> src/lib.rs:1:9
372 /// 1 | #![deny(unused_crate_dependencies)]
373 /// | ^^^^^^^^^^^^^^^^^^^^^^^^^
378 /// After removing the code that uses a dependency, this usually also
379 /// requires removing the dependency from the build configuration.
380 /// However, sometimes that step can be missed, which leads to time wasted
381 /// building dependencies that are no longer used. This lint can be
382 /// enabled to detect dependencies that are never used (more specifically,
383 /// any dependency passed with the `--extern` command-line flag that is
384 /// never referenced via [`use`], [`extern crate`], or in any [path]).
386 /// This lint is "allow" by default because it can provide false positives
387 /// depending on how the build system is configured. For example, when
388 /// using Cargo, a "package" consists of multiple crates (such as a
389 /// library and a binary), but the dependencies are defined for the
390 /// package as a whole. If there is a dependency that is only used in the
391 /// binary, but not the library, then the lint will be incorrectly issued
394 /// [path]: https://doc.rust-lang.org/reference/paths.html
395 /// [`use`]: https://doc.rust-lang.org/reference/items/use-declarations.html
396 /// [`extern crate`]: https://doc.rust-lang.org/reference/items/extern-crates.html
397 pub UNUSED_CRATE_DEPENDENCIES
,
399 "crate dependencies that are never used",
404 /// The `unused_qualifications` lint detects unnecessarily qualified
409 /// ```rust,compile_fail
410 /// #![deny(unused_qualifications)]
425 /// If an item from another module is already brought into scope, then
426 /// there is no need to qualify it in this case. You can call `bar()`
427 /// directly, without the `foo::`.
429 /// This lint is "allow" by default because it is somewhat pedantic, and
430 /// doesn't indicate an actual problem, but rather a stylistic choice, and
431 /// can be noisy when refactoring or moving around code.
432 pub UNUSED_QUALIFICATIONS
,
434 "detects unnecessarily qualified names"
438 /// The `unknown_lints` lint detects unrecognized lint attribute.
443 /// #![allow(not_a_real_lint)]
450 /// It is usually a mistake to specify a lint that does not exist. Check
451 /// the spelling, and check the lint listing for the correct name. Also
452 /// consider if you are using an old version of the compiler, and the lint
453 /// is only available in a newer version.
456 "unrecognized lint attribute"
460 /// The `unused_variables` lint detects variables which are not used in
473 /// Unused variables may signal a mistake or unfinished code. To silence
474 /// the warning for the individual variable, prefix it with an underscore
476 pub UNUSED_VARIABLES
,
478 "detect variables which are not used in any way"
482 /// The `unused_assignments` lint detects assignments that will never be read.
495 /// Unused assignments may signal a mistake or unfinished code. If the
496 /// variable is never used after being assigned, then the assignment can
497 /// be removed. Variables with an underscore prefix such as `_x` will not
498 /// trigger this lint.
499 pub UNUSED_ASSIGNMENTS
,
501 "detect assignments that will never be read"
505 /// The `dead_code` lint detects unused, unexported items.
517 /// Dead code may signal a mistake or unfinished code. To silence the
518 /// warning for individual items, prefix the name with an underscore such
519 /// as `_foo`. If it was intended to expose the item outside of the crate,
520 /// consider adding a visibility modifier like `pub`. Otherwise consider
521 /// removing the unused code.
524 "detect unused, unexported items"
528 /// The `unused_attributes` lint detects attributes that were not used by
541 /// Unused [attributes] may indicate the attribute is placed in the wrong
542 /// position. Consider removing it, or placing it in the correct position.
543 /// Also consider if you intended to use an _inner attribute_ (with a `!`
544 /// such as `#![allow(unused)]`) which applies to the item the attribute
545 /// is within, or an _outer attribute_ (without a `!` such as
546 /// `#[allow(unused)]`) which applies to the item *following* the
549 /// [attributes]: https://doc.rust-lang.org/reference/attributes.html
550 pub UNUSED_ATTRIBUTES
,
552 "detects attributes that were not used by the compiler"
556 /// The `unreachable_code` lint detects unreachable code paths.
561 /// panic!("we never go past here!");
570 /// Unreachable code may signal a mistake or unfinished code. If the code
571 /// is no longer in use, consider removing it.
572 pub UNREACHABLE_CODE
,
574 "detects unreachable code paths",
575 report_in_external_macro
579 /// The `unreachable_patterns` lint detects unreachable patterns.
595 /// This usually indicates a mistake in how the patterns are specified or
596 /// ordered. In this example, the `y` pattern will always match, so the
597 /// five is impossible to reach. Remember, match arms match in order, you
598 /// probably wanted to put the `5` case above the `y` case.
599 pub UNREACHABLE_PATTERNS
,
601 "detects unreachable patterns"
605 /// The `overlapping_range_endpoints` lint detects `match` arms that have [range patterns] that
606 /// overlap on their endpoints.
608 /// [range patterns]: https://doc.rust-lang.org/nightly/reference/patterns.html#range-patterns
615 /// 0..=100 => { println!("small"); }
616 /// 100..=255 => { println!("large"); }
624 /// It is likely a mistake to have range patterns in a match expression that overlap in this
625 /// way. Check that the beginning and end values are what you expect, and keep in mind that
626 /// with `..=` the left and right bounds are inclusive.
627 pub OVERLAPPING_RANGE_ENDPOINTS
,
629 "detects range patterns with overlapping endpoints"
633 /// The `bindings_with_variant_name` lint detects pattern bindings with
634 /// the same name as one of the matched variants.
644 /// pub fn foo(x: Enum) {
656 /// It is usually a mistake to specify an enum variant name as an
657 /// [identifier pattern]. In the example above, the `match` arms are
658 /// specifying a variable name to bind the value of `x` to. The second arm
659 /// is ignored because the first one matches *all* values. The likely
660 /// intent is that the arm was intended to match on the enum variant.
662 /// Two possible solutions are:
664 /// * Specify the enum variant using a [path pattern], such as
666 /// * Bring the enum variants into local scope, such as adding `use
667 /// Enum::*;` to the beginning of the `foo` function in the example
670 /// [identifier pattern]: https://doc.rust-lang.org/reference/patterns.html#identifier-patterns
671 /// [path pattern]: https://doc.rust-lang.org/reference/patterns.html#path-patterns
672 pub BINDINGS_WITH_VARIANT_NAME
,
674 "detects pattern bindings with the same name as one of the matched variants"
678 /// The `unused_macros` lint detects macros that were not used.
683 /// macro_rules! unused {
695 /// Unused macros may signal a mistake or unfinished code. To silence the
696 /// warning for the individual macro, prefix the name with an underscore
697 /// such as `_my_macro`. If you intended to export the macro to make it
698 /// available outside of the crate, use the [`macro_export` attribute].
700 /// [`macro_export` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
703 "detects macros that were not used"
707 /// The `warnings` lint allows you to change the level of other
708 /// lints which produce warnings.
713 /// #![deny(warnings)]
721 /// The `warnings` lint is a bit special; by changing its level, you
722 /// change every other warning that would produce a warning to whatever
723 /// value you'd like. As such, you won't ever trigger this lint in your
727 "mass-change the level for lints which produce warnings"
731 /// The `unused_features` lint detects unused or unknown features found in
732 /// crate-level [`feature` attributes].
734 /// [`feature` attributes]: https://doc.rust-lang.org/nightly/unstable-book/
736 /// Note: This lint is currently not functional, see [issue #44232] for
739 /// [issue #44232]: https://github.com/rust-lang/rust/issues/44232
742 "unused features found in crate-level `#[feature]` directives"
746 /// The `stable_features` lint detects a [`feature` attribute] that
747 /// has since been made stable.
749 /// [`feature` attribute]: https://doc.rust-lang.org/nightly/unstable-book/
754 /// #![feature(test_accepted_feature)]
762 /// When a feature is stabilized, it is no longer necessary to include a
763 /// `#![feature]` attribute for it. To fix, simply remove the
764 /// `#![feature]` attribute.
767 "stable features found in `#[feature]` directive"
771 /// The `unknown_crate_types` lint detects an unknown crate type found in
772 /// a [`crate_type` attribute].
776 /// ```rust,compile_fail
777 /// #![crate_type="lol"]
785 /// An unknown value give to the `crate_type` attribute is almost
786 /// certainly a mistake.
788 /// [`crate_type` attribute]: https://doc.rust-lang.org/reference/linkage.html
789 pub UNKNOWN_CRATE_TYPES
,
791 "unknown crate type found in `#[crate_type]` directive",
796 /// The `trivial_casts` lint detects trivial casts which could be replaced
797 /// with coercion, which may require [type ascription] or a temporary
802 /// ```rust,compile_fail
803 /// #![deny(trivial_casts)]
804 /// let x: &u32 = &42;
805 /// let y = x as *const u32;
812 /// A trivial cast is a cast `e as T` where `e` has type `U` and `U` is a
813 /// subtype of `T`. This type of cast is usually unnecessary, as it can be
814 /// usually be inferred.
816 /// This lint is "allow" by default because there are situations, such as
817 /// with FFI interfaces or complex type aliases, where it triggers
818 /// incorrectly, or in situations where it will be more difficult to
819 /// clearly express the intent. It may be possible that this will become a
820 /// warning in the future, possibly with [type ascription] providing a
821 /// convenient way to work around the current issues. See [RFC 401] for
822 /// historical context.
824 /// [type ascription]: https://github.com/rust-lang/rust/issues/23416
825 /// [RFC 401]: https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md
828 "detects trivial casts which could be removed"
832 /// The `trivial_numeric_casts` lint detects trivial numeric casts of types
833 /// which could be removed.
837 /// ```rust,compile_fail
838 /// #![deny(trivial_numeric_casts)]
839 /// let x = 42_i32 as i32;
846 /// A trivial numeric cast is a cast of a numeric type to the same numeric
847 /// type. This type of cast is usually unnecessary.
849 /// This lint is "allow" by default because there are situations, such as
850 /// with FFI interfaces or complex type aliases, where it triggers
851 /// incorrectly, or in situations where it will be more difficult to
852 /// clearly express the intent. It may be possible that this will become a
853 /// warning in the future, possibly with [type ascription] providing a
854 /// convenient way to work around the current issues. See [RFC 401] for
855 /// historical context.
857 /// [type ascription]: https://github.com/rust-lang/rust/issues/23416
858 /// [RFC 401]: https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md
859 pub TRIVIAL_NUMERIC_CASTS
,
861 "detects trivial casts of numeric types which could be removed"
865 /// The `private_in_public` lint detects private items in public
866 /// interfaces not caught by the old implementation.
871 /// # #![allow(unused)]
876 /// impl super::SemiPriv {
877 /// pub fn f(_: Priv) {}
887 /// The visibility rules are intended to prevent exposing private items in
888 /// public interfaces. This is a [future-incompatible] lint to transition
889 /// this to a hard error in the future. See [issue #34537] for more
892 /// [issue #34537]: https://github.com/rust-lang/rust/issues/34537
893 /// [future-incompatible]: ../index.md#future-incompatible-lints
894 pub PRIVATE_IN_PUBLIC
,
896 "detect private items in public interfaces not caught by the old implementation",
897 @future_incompatible
= FutureIncompatibleInfo
{
898 reference
: "issue #34537 <https://github.com/rust-lang/rust/issues/34537>",
903 /// The `exported_private_dependencies` lint detects private dependencies
904 /// that are exposed in a public interface.
908 /// ```rust,ignore (needs-dependency)
909 /// pub fn foo() -> Option<some_private_dependency::Thing> {
914 /// This will produce:
917 /// warning: type `bar::Thing` from private dependency 'bar' in public interface
918 /// --> src/lib.rs:3:1
920 /// 3 | pub fn foo() -> Option<bar::Thing> {
921 /// | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
923 /// = note: `#[warn(exported_private_dependencies)]` on by default
928 /// Dependencies can be marked as "private" to indicate that they are not
929 /// exposed in the public interface of a crate. This can be used by Cargo
930 /// to independently resolve those dependencies because it can assume it
931 /// does not need to unify them with other packages using that same
932 /// dependency. This lint is an indication of a violation of that
935 /// To fix this, avoid exposing the dependency in your public interface.
936 /// Or, switch the dependency to a public dependency.
938 /// Note that support for this is only available on the nightly channel.
939 /// See [RFC 1977] for more details, as well as the [Cargo documentation].
941 /// [RFC 1977]: https://github.com/rust-lang/rfcs/blob/master/text/1977-public-private-dependencies.md
942 /// [Cargo documentation]: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#public-dependency
943 pub EXPORTED_PRIVATE_DEPENDENCIES
,
945 "public interface leaks type from a private dependency"
949 /// The `pub_use_of_private_extern_crate` lint detects a specific
950 /// situation of re-exporting a private `extern crate`.
954 /// ```rust,compile_fail
955 /// extern crate core;
956 /// pub use core as reexported_core;
963 /// A public `use` declaration should not be used to publicly re-export a
964 /// private `extern crate`. `pub extern crate` should be used instead.
966 /// This was historically allowed, but is not the intended behavior
967 /// according to the visibility rules. This is a [future-incompatible]
968 /// lint to transition this to a hard error in the future. See [issue
969 /// #34537] for more details.
971 /// [issue #34537]: https://github.com/rust-lang/rust/issues/34537
972 /// [future-incompatible]: ../index.md#future-incompatible-lints
973 pub PUB_USE_OF_PRIVATE_EXTERN_CRATE
,
975 "detect public re-exports of private extern crates",
976 @future_incompatible
= FutureIncompatibleInfo
{
977 reference
: "issue #34537 <https://github.com/rust-lang/rust/issues/34537>",
982 /// The `invalid_type_param_default` lint detects type parameter defaults
983 /// erroneously allowed in an invalid location.
987 /// ```rust,compile_fail
988 /// fn foo<T=i32>(t: T) {}
995 /// Default type parameters were only intended to be allowed in certain
996 /// situations, but historically the compiler allowed them everywhere.
997 /// This is a [future-incompatible] lint to transition this to a hard
998 /// error in the future. See [issue #36887] for more details.
1000 /// [issue #36887]: https://github.com/rust-lang/rust/issues/36887
1001 /// [future-incompatible]: ../index.md#future-incompatible-lints
1002 pub INVALID_TYPE_PARAM_DEFAULT
,
1004 "type parameter default erroneously allowed in invalid location",
1005 @future_incompatible
= FutureIncompatibleInfo
{
1006 reference
: "issue #36887 <https://github.com/rust-lang/rust/issues/36887>",
1011 /// The `renamed_and_removed_lints` lint detects lints that have been
1012 /// renamed or removed.
1017 /// #![deny(raw_pointer_derive)]
1024 /// To fix this, either remove the lint or use the new name. This can help
1025 /// avoid confusion about lints that are no longer valid, and help
1026 /// maintain consistency for renamed lints.
1027 pub RENAMED_AND_REMOVED_LINTS
,
1029 "lints that have been renamed or removed"
1033 /// The `unaligned_references` lint detects unaligned references to fields
1034 /// of [packed] structs.
1036 /// [packed]: https://doc.rust-lang.org/reference/type-layout.html#the-alignment-modifiers
1040 /// ```rust,compile_fail
1041 /// #![deny(unaligned_references)]
1044 /// pub struct Foo {
1051 /// let foo = Foo { field1: 0, field2: 0 };
1052 /// let _ = &foo.field1;
1053 /// println!("{}", foo.field1); // An implicit `&` is added here, triggering the lint.
1062 /// Creating a reference to an insufficiently aligned packed field is [undefined behavior] and
1063 /// should be disallowed. Using an `unsafe` block does not change anything about this. Instead,
1064 /// the code should do a copy of the data in the packed field or use raw pointers and unaligned
1065 /// accesses. See [issue #82523] for more information.
1067 /// [undefined behavior]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html
1068 /// [issue #82523]: https://github.com/rust-lang/rust/issues/82523
1069 pub UNALIGNED_REFERENCES
,
1071 "detects unaligned references to fields of packed structs",
1072 @future_incompatible
= FutureIncompatibleInfo
{
1073 reference
: "issue #82523 <https://github.com/rust-lang/rust/issues/82523>",
1075 report_in_external_macro
1079 /// The `const_item_mutation` lint detects attempts to mutate a `const`
1085 /// const FOO: [i32; 1] = [0];
1089 /// // This will print "[0]".
1090 /// println!("{:?}", FOO);
1098 /// Trying to directly mutate a `const` item is almost always a mistake.
1099 /// What is happening in the example above is that a temporary copy of the
1100 /// `const` is mutated, but the original `const` is not. Each time you
1101 /// refer to the `const` by name (such as `FOO` in the example above), a
1102 /// separate copy of the value is inlined at that location.
1104 /// This lint checks for writing directly to a field (`FOO.field =
1105 /// some_value`) or array entry (`FOO[0] = val`), or taking a mutable
1106 /// reference to the const item (`&mut FOO`), including through an
1107 /// autoderef (`FOO.some_mut_self_method()`).
1109 /// There are various alternatives depending on what you are trying to
1112 /// * First, always reconsider using mutable globals, as they can be
1113 /// difficult to use correctly, and can make the code more difficult to
1114 /// use or understand.
1115 /// * If you are trying to perform a one-time initialization of a global:
1116 /// * If the value can be computed at compile-time, consider using
1117 /// const-compatible values (see [Constant Evaluation]).
1118 /// * For more complex single-initialization cases, consider using a
1119 /// third-party crate, such as [`lazy_static`] or [`once_cell`].
1120 /// * If you are using the [nightly channel], consider the new
1121 /// [`lazy`] module in the standard library.
1122 /// * If you truly need a mutable global, consider using a [`static`],
1123 /// which has a variety of options:
1124 /// * Simple data types can be directly defined and mutated with an
1125 /// [`atomic`] type.
1126 /// * More complex types can be placed in a synchronization primitive
1127 /// like a [`Mutex`], which can be initialized with one of the options
1129 /// * A [mutable `static`] is a low-level primitive, requiring unsafe.
1130 /// Typically This should be avoided in preference of something
1131 /// higher-level like one of the above.
1133 /// [Constant Evaluation]: https://doc.rust-lang.org/reference/const_eval.html
1134 /// [`static`]: https://doc.rust-lang.org/reference/items/static-items.html
1135 /// [mutable `static`]: https://doc.rust-lang.org/reference/items/static-items.html#mutable-statics
1136 /// [`lazy`]: https://doc.rust-lang.org/nightly/std/lazy/index.html
1137 /// [`lazy_static`]: https://crates.io/crates/lazy_static
1138 /// [`once_cell`]: https://crates.io/crates/once_cell
1139 /// [`atomic`]: https://doc.rust-lang.org/std/sync/atomic/index.html
1140 /// [`Mutex`]: https://doc.rust-lang.org/std/sync/struct.Mutex.html
1141 pub CONST_ITEM_MUTATION
,
1143 "detects attempts to mutate a `const` item",
1147 /// The `patterns_in_fns_without_body` lint detects `mut` identifier
1148 /// patterns as a parameter in functions without a body.
1152 /// ```rust,compile_fail
1154 /// fn foo(mut arg: u8);
1162 /// To fix this, remove `mut` from the parameter in the trait definition;
1163 /// it can be used in the implementation. That is, the following is OK:
1167 /// fn foo(arg: u8); // Removed `mut` here
1170 /// impl Trait for i32 {
1171 /// fn foo(mut arg: u8) { // `mut` here is OK
1177 /// Trait definitions can define functions without a body to specify a
1178 /// function that implementors must define. The parameter names in the
1179 /// body-less functions are only allowed to be `_` or an [identifier] for
1180 /// documentation purposes (only the type is relevant). Previous versions
1181 /// of the compiler erroneously allowed [identifier patterns] with the
1182 /// `mut` keyword, but this was not intended to be allowed. This is a
1183 /// [future-incompatible] lint to transition this to a hard error in the
1184 /// future. See [issue #35203] for more details.
1186 /// [identifier]: https://doc.rust-lang.org/reference/identifiers.html
1187 /// [identifier patterns]: https://doc.rust-lang.org/reference/patterns.html#identifier-patterns
1188 /// [issue #35203]: https://github.com/rust-lang/rust/issues/35203
1189 /// [future-incompatible]: ../index.md#future-incompatible-lints
1190 pub PATTERNS_IN_FNS_WITHOUT_BODY
,
1192 "patterns in functions without body were erroneously allowed",
1193 @future_incompatible
= FutureIncompatibleInfo
{
1194 reference
: "issue #35203 <https://github.com/rust-lang/rust/issues/35203>",
1199 /// The `missing_fragment_specifier` lint is issued when an unused pattern in a
1200 /// `macro_rules!` macro definition has a meta-variable (e.g. `$e`) that is not
1201 /// followed by a fragment specifier (e.g. `:expr`).
1203 /// This warning can always be fixed by removing the unused pattern in the
1204 /// `macro_rules!` macro definition.
1208 /// ```rust,compile_fail
1209 /// macro_rules! foo {
1223 /// To fix this, remove the unused pattern from the `macro_rules!` macro definition:
1226 /// macro_rules! foo {
1233 pub MISSING_FRAGMENT_SPECIFIER
,
1235 "detects missing fragment specifiers in unused `macro_rules!` patterns",
1236 @future_incompatible
= FutureIncompatibleInfo
{
1237 reference
: "issue #40107 <https://github.com/rust-lang/rust/issues/40107>",
1242 /// The `late_bound_lifetime_arguments` lint detects generic lifetime
1243 /// arguments in path segments with late bound lifetime parameters.
1251 /// fn late<'a, 'b>(self, _: &'a u8, _: &'b u8) {}
1255 /// S.late::<'static>(&0, &0);
1263 /// It is not clear how to provide arguments for early-bound lifetime
1264 /// parameters if they are intermixed with late-bound parameters in the
1265 /// same list. For now, providing any explicit arguments will trigger this
1266 /// lint if late-bound parameters are present, so in the future a solution
1267 /// can be adopted without hitting backward compatibility issues. This is
1268 /// a [future-incompatible] lint to transition this to a hard error in the
1269 /// future. See [issue #42868] for more details, along with a description
1270 /// of the difference between early and late-bound parameters.
1272 /// [issue #42868]: https://github.com/rust-lang/rust/issues/42868
1273 /// [future-incompatible]: ../index.md#future-incompatible-lints
1274 pub LATE_BOUND_LIFETIME_ARGUMENTS
,
1276 "detects generic lifetime arguments in path segments with late bound lifetime parameters",
1277 @future_incompatible
= FutureIncompatibleInfo
{
1278 reference
: "issue #42868 <https://github.com/rust-lang/rust/issues/42868>",
1283 /// The `order_dependent_trait_objects` lint detects a trait coherency
1284 /// violation that would allow creating two trait impls for the same
1285 /// dynamic trait object involving marker traits.
1289 /// ```rust,compile_fail
1290 /// pub trait Trait {}
1292 /// impl Trait for dyn Send + Sync { }
1293 /// impl Trait for dyn Sync + Send { }
1300 /// A previous bug caused the compiler to interpret traits with different
1301 /// orders (such as `Send + Sync` and `Sync + Send`) as distinct types
1302 /// when they were intended to be treated the same. This allowed code to
1303 /// define separate trait implementations when there should be a coherence
1304 /// error. This is a [future-incompatible] lint to transition this to a
1305 /// hard error in the future. See [issue #56484] for more details.
1307 /// [issue #56484]: https://github.com/rust-lang/rust/issues/56484
1308 /// [future-incompatible]: ../index.md#future-incompatible-lints
1309 pub ORDER_DEPENDENT_TRAIT_OBJECTS
,
1311 "trait-object types were treated as different depending on marker-trait order",
1312 @future_incompatible
= FutureIncompatibleInfo
{
1313 reference
: "issue #56484 <https://github.com/rust-lang/rust/issues/56484>",
1318 /// The `coherence_leak_check` lint detects conflicting implementations of
1319 /// a trait that are only distinguished by the old leak-check code.
1324 /// trait SomeTrait { }
1325 /// impl SomeTrait for for<'a> fn(&'a u8) { }
1326 /// impl<'a> SomeTrait for fn(&'a u8) { }
1333 /// In the past, the compiler would accept trait implementations for
1334 /// identical functions that differed only in where the lifetime binder
1335 /// appeared. Due to a change in the borrow checker implementation to fix
1336 /// several bugs, this is no longer allowed. However, since this affects
1337 /// existing code, this is a [future-incompatible] lint to transition this
1338 /// to a hard error in the future.
1340 /// Code relying on this pattern should introduce "[newtypes]",
1341 /// like `struct Foo(for<'a> fn(&'a u8))`.
1343 /// See [issue #56105] for more details.
1345 /// [issue #56105]: https://github.com/rust-lang/rust/issues/56105
1346 /// [newtypes]: https://doc.rust-lang.org/book/ch19-04-advanced-types.html#using-the-newtype-pattern-for-type-safety-and-abstraction
1347 /// [future-incompatible]: ../index.md#future-incompatible-lints
1348 pub COHERENCE_LEAK_CHECK
,
1350 "distinct impls distinguished only by the leak-check code",
1351 @future_incompatible
= FutureIncompatibleInfo
{
1352 reference
: "issue #56105 <https://github.com/rust-lang/rust/issues/56105>",
1357 /// The `deprecated` lint detects use of deprecated items.
1374 /// Items may be marked "deprecated" with the [`deprecated` attribute] to
1375 /// indicate that they should no longer be used. Usually the attribute
1376 /// should include a note on what to use instead, or check the
1379 /// [`deprecated` attribute]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute
1382 "detects use of deprecated items",
1383 report_in_external_macro
1387 /// The `unused_unsafe` lint detects unnecessary use of an `unsafe` block.
1399 /// If nothing within the block requires `unsafe`, then remove the
1400 /// `unsafe` marker because it is not required and may cause confusion.
1403 "unnecessary use of an `unsafe` block"
1407 /// The `unused_mut` lint detects mut variables which don't need to be
1420 /// The preferred style is to only mark variables as `mut` if it is
1424 "detect mut variables which don't need to be mutable"
1428 /// The `unconditional_recursion` lint detects functions that cannot
1429 /// return without calling themselves.
1443 /// It is usually a mistake to have a recursive call that does not have
1444 /// some condition to cause it to terminate. If you really intend to have
1445 /// an infinite loop, using a `loop` expression is recommended.
1446 pub UNCONDITIONAL_RECURSION
,
1448 "functions that cannot return without calling themselves"
1452 /// The `single_use_lifetimes` lint detects lifetimes that are only used
1457 /// ```rust,compile_fail
1458 /// #![deny(single_use_lifetimes)]
1460 /// fn foo<'a>(x: &'a u32) {}
1467 /// Specifying an explicit lifetime like `'a` in a function or `impl`
1468 /// should only be used to link together two things. Otherwise, you should
1469 /// just use `'_` to indicate that the lifetime is not linked to anything,
1470 /// or elide the lifetime altogether if possible.
1472 /// This lint is "allow" by default because it was introduced at a time
1473 /// when `'_` and elided lifetimes were first being introduced, and this
1474 /// lint would be too noisy. Also, there are some known false positives
1475 /// that it produces. See [RFC 2115] for historical context, and [issue
1476 /// #44752] for more details.
1478 /// [RFC 2115]: https://github.com/rust-lang/rfcs/blob/master/text/2115-argument-lifetimes.md
1479 /// [issue #44752]: https://github.com/rust-lang/rust/issues/44752
1480 pub SINGLE_USE_LIFETIMES
,
1482 "detects lifetime parameters that are only used once"
1486 /// The `unused_lifetimes` lint detects lifetime parameters that are never
1491 /// ```rust,compile_fail
1492 /// #[deny(unused_lifetimes)]
1494 /// pub fn foo<'a>() {}
1501 /// Unused lifetime parameters may signal a mistake or unfinished code.
1502 /// Consider removing the parameter.
1503 pub UNUSED_LIFETIMES
,
1505 "detects lifetime parameters that are never used"
1509 /// The `tyvar_behind_raw_pointer` lint detects raw pointer to an
1510 /// inference variable.
1514 /// ```rust,edition2015
1516 /// let data = std::ptr::null();
1517 /// let _ = &data as *const *const ();
1519 /// if data.is_null() {}
1526 /// This kind of inference was previously allowed, but with the future
1527 /// arrival of [arbitrary self types], this can introduce ambiguity. To
1528 /// resolve this, use an explicit type instead of relying on type
1531 /// This is a [future-incompatible] lint to transition this to a hard
1532 /// error in the 2018 edition. See [issue #46906] for more details. This
1533 /// is currently a hard-error on the 2018 edition, and is "warn" by
1534 /// default in the 2015 edition.
1536 /// [arbitrary self types]: https://github.com/rust-lang/rust/issues/44874
1537 /// [issue #46906]: https://github.com/rust-lang/rust/issues/46906
1538 /// [future-incompatible]: ../index.md#future-incompatible-lints
1539 pub TYVAR_BEHIND_RAW_POINTER
,
1541 "raw pointer to an inference variable",
1542 @future_incompatible
= FutureIncompatibleInfo
{
1543 reference
: "issue #46906 <https://github.com/rust-lang/rust/issues/46906>",
1544 reason
: FutureIncompatibilityReason
::EditionError(Edition
::Edition2018
),
1549 /// The `elided_lifetimes_in_paths` lint detects the use of hidden
1550 /// lifetime parameters.
1554 /// ```rust,compile_fail
1555 /// #![deny(elided_lifetimes_in_paths)]
1556 /// struct Foo<'a> {
1560 /// fn foo(x: &Foo) {
1568 /// Elided lifetime parameters can make it difficult to see at a glance
1569 /// that borrowing is occurring. This lint ensures that lifetime
1570 /// parameters are always explicitly stated, even if it is the `'_`
1571 /// [placeholder lifetime].
1573 /// This lint is "allow" by default because it has some known issues, and
1574 /// may require a significant transition for old code.
1576 /// [placeholder lifetime]: https://doc.rust-lang.org/reference/lifetime-elision.html#lifetime-elision-in-functions
1577 pub ELIDED_LIFETIMES_IN_PATHS
,
1579 "hidden lifetime parameters in types are deprecated",
1584 /// The `bare_trait_objects` lint suggests using `dyn Trait` for trait
1592 /// fn takes_trait_object(_: Box<Trait>) {
1600 /// Without the `dyn` indicator, it can be ambiguous or confusing when
1601 /// reading code as to whether or not you are looking at a trait object.
1602 /// The `dyn` keyword makes it explicit, and adds a symmetry to contrast
1603 /// with [`impl Trait`].
1605 /// [`impl Trait`]: https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
1606 pub BARE_TRAIT_OBJECTS
,
1608 "suggest using `dyn Trait` for trait objects",
1609 @future_incompatible
= FutureIncompatibleInfo
{
1610 reference
: "issue #80165 <https://github.com/rust-lang/rust/issues/80165>",
1611 reason
: FutureIncompatibilityReason
::EditionError(Edition
::Edition2021
),
1616 /// The `absolute_paths_not_starting_with_crate` lint detects fully
1617 /// qualified paths that start with a module name instead of `crate`,
1618 /// `self`, or an extern crate name
1622 /// ```rust,edition2015,compile_fail
1623 /// #![deny(absolute_paths_not_starting_with_crate)]
1638 /// Rust [editions] allow the language to evolve without breaking
1639 /// backwards compatibility. This lint catches code that uses absolute
1640 /// paths in the style of the 2015 edition. In the 2015 edition, absolute
1641 /// paths (those starting with `::`) refer to either the crate root or an
1642 /// external crate. In the 2018 edition it was changed so that they only
1643 /// refer to external crates. The path prefix `crate::` should be used
1644 /// instead to reference items from the crate root.
1646 /// If you switch the compiler from the 2015 to 2018 edition without
1647 /// updating the code, then it will fail to compile if the old style paths
1648 /// are used. You can manually change the paths to use the `crate::`
1649 /// prefix to transition to the 2018 edition.
1651 /// This lint solves the problem automatically. It is "allow" by default
1652 /// because the code is perfectly valid in the 2015 edition. The [`cargo
1653 /// fix`] tool with the `--edition` flag will switch this lint to "warn"
1654 /// and automatically apply the suggested fix from the compiler. This
1655 /// provides a completely automated way to update old code to the 2018
1658 /// [editions]: https://doc.rust-lang.org/edition-guide/
1659 /// [`cargo fix`]: https://doc.rust-lang.org/cargo/commands/cargo-fix.html
1660 pub ABSOLUTE_PATHS_NOT_STARTING_WITH_CRATE
,
1662 "fully qualified paths that start with a module name \
1663 instead of `crate`, `self`, or an extern crate name",
1664 @future_incompatible
= FutureIncompatibleInfo
{
1665 reference
: "issue #53130 <https://github.com/rust-lang/rust/issues/53130>",
1666 reason
: FutureIncompatibilityReason
::EditionError(Edition
::Edition2018
),
1671 /// The `illegal_floating_point_literal_pattern` lint detects
1672 /// floating-point literals used in patterns.
1689 /// Previous versions of the compiler accepted floating-point literals in
1690 /// patterns, but it was later determined this was a mistake. The
1691 /// semantics of comparing floating-point values may not be clear in a
1692 /// pattern when contrasted with "structural equality". Typically you can
1693 /// work around this by using a [match guard], such as:
1699 /// y if y == 5.0 => {}
1704 /// This is a [future-incompatible] lint to transition this to a hard
1705 /// error in the future. See [issue #41620] for more details.
1707 /// [issue #41620]: https://github.com/rust-lang/rust/issues/41620
1708 /// [match guard]: https://doc.rust-lang.org/reference/expressions/match-expr.html#match-guards
1709 /// [future-incompatible]: ../index.md#future-incompatible-lints
1710 pub ILLEGAL_FLOATING_POINT_LITERAL_PATTERN
,
1712 "floating-point literals cannot be used in patterns",
1713 @future_incompatible
= FutureIncompatibleInfo
{
1714 reference
: "issue #41620 <https://github.com/rust-lang/rust/issues/41620>",
1719 /// The `unstable_name_collisions` lint detects that you have used a name
1720 /// that the standard library plans to add in the future.
1725 /// trait MyIterator : Iterator {
1726 /// // is_sorted is an unstable method that already exists on the Iterator trait
1727 /// fn is_sorted(self) -> bool where Self: Sized {true}
1730 /// impl<T: ?Sized> MyIterator for T where T: Iterator { }
1732 /// let x = vec![1, 2, 3];
1733 /// let _ = x.iter().is_sorted();
1740 /// When new methods are added to traits in the standard library, they are
1741 /// usually added in an "unstable" form which is only available on the
1742 /// [nightly channel] with a [`feature` attribute]. If there is any
1743 /// pre-existing code which extends a trait to have a method with the same
1744 /// name, then the names will collide. In the future, when the method is
1745 /// stabilized, this will cause an error due to the ambiguity. This lint
1746 /// is an early-warning to let you know that there may be a collision in
1747 /// the future. This can be avoided by adding type annotations to
1748 /// disambiguate which trait method you intend to call, such as
1749 /// `MyIterator::is_sorted(my_iter)` or renaming or removing the method.
1751 /// [nightly channel]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
1752 /// [`feature` attribute]: https://doc.rust-lang.org/nightly/unstable-book/
1753 pub UNSTABLE_NAME_COLLISIONS
,
1755 "detects name collision with an existing but unstable method",
1756 @future_incompatible
= FutureIncompatibleInfo
{
1757 reference
: "issue #48919 <https://github.com/rust-lang/rust/issues/48919>",
1758 // Note: this item represents future incompatibility of all unstable functions in the
1759 // standard library, and thus should never be removed or changed to an error.
1764 /// The `irrefutable_let_patterns` lint detects [irrefutable patterns]
1765 /// in [`if let`]s, [`while let`]s, and `if let` guards.
1770 /// if let _ = 123 {
1771 /// println!("always runs!");
1779 /// There usually isn't a reason to have an irrefutable pattern in an
1780 /// `if let` or `while let` statement, because the pattern will always match
1781 /// successfully. A [`let`] or [`loop`] statement will suffice. However,
1782 /// when generating code with a macro, forbidding irrefutable patterns
1783 /// would require awkward workarounds in situations where the macro
1784 /// doesn't know if the pattern is refutable or not. This lint allows
1785 /// macros to accept this form, while alerting for a possibly incorrect
1786 /// use in normal code.
1788 /// See [RFC 2086] for more details.
1790 /// [irrefutable patterns]: https://doc.rust-lang.org/reference/patterns.html#refutability
1791 /// [`if let`]: https://doc.rust-lang.org/reference/expressions/if-expr.html#if-let-expressions
1792 /// [`while let`]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#predicate-pattern-loops
1793 /// [`let`]: https://doc.rust-lang.org/reference/statements.html#let-statements
1794 /// [`loop`]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#infinite-loops
1795 /// [RFC 2086]: https://github.com/rust-lang/rfcs/blob/master/text/2086-allow-if-let-irrefutables.md
1796 pub IRREFUTABLE_LET_PATTERNS
,
1798 "detects irrefutable patterns in `if let` and `while let` statements"
1802 /// The `unused_labels` lint detects [labels] that are never used.
1804 /// [labels]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#loop-labels
1809 /// 'unused_label: loop {}
1816 /// Unused labels may signal a mistake or unfinished code. To silence the
1817 /// warning for the individual label, prefix it with an underscore such as
1821 "detects labels that are never used"
1825 /// The `where_clauses_object_safety` lint detects for [object safety] of
1826 /// [where clauses].
1828 /// [object safety]: https://doc.rust-lang.org/reference/items/traits.html#object-safety
1829 /// [where clauses]: https://doc.rust-lang.org/reference/items/generics.html#where-clauses
1836 /// trait X { fn foo(&self) where Self: Trait; }
1838 /// impl X for () { fn foo(&self) {} }
1840 /// impl Trait for dyn X {}
1842 /// // Segfault at opt-level 0, SIGILL otherwise.
1843 /// pub fn main() { <dyn X as X>::foo(&()); }
1850 /// The compiler previously allowed these object-unsafe bounds, which was
1851 /// incorrect. This is a [future-incompatible] lint to transition this to
1852 /// a hard error in the future. See [issue #51443] for more details.
1854 /// [issue #51443]: https://github.com/rust-lang/rust/issues/51443
1855 /// [future-incompatible]: ../index.md#future-incompatible-lints
1856 pub WHERE_CLAUSES_OBJECT_SAFETY
,
1858 "checks the object safety of where clauses",
1859 @future_incompatible
= FutureIncompatibleInfo
{
1860 reference
: "issue #51443 <https://github.com/rust-lang/rust/issues/51443>",
1865 /// The `proc_macro_derive_resolution_fallback` lint detects proc macro
1866 /// derives using inaccessible names from parent modules.
1870 /// ```rust,ignore (proc-macro)
1872 /// #![crate_type = "proc-macro"]
1874 /// extern crate proc_macro;
1876 /// use proc_macro::*;
1878 /// #[proc_macro_derive(Foo)]
1879 /// pub fn foo1(a: TokenStream) -> TokenStream {
1881 /// "mod __bar { static mut BAR: Option<Something> = None; }".parse().unwrap()
1885 /// ```rust,ignore (needs-dependency)
1888 /// extern crate foo;
1890 /// struct Something;
1898 /// This will produce:
1901 /// warning: cannot find type `Something` in this scope
1902 /// --> src/main.rs:8:10
1904 /// 8 | #[derive(Foo)]
1905 /// | ^^^ names from parent modules are not accessible without an explicit import
1907 /// = note: `#[warn(proc_macro_derive_resolution_fallback)]` on by default
1908 /// = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
1909 /// = note: for more information, see issue #50504 <https://github.com/rust-lang/rust/issues/50504>
1914 /// If a proc-macro generates a module, the compiler unintentionally
1915 /// allowed items in that module to refer to items in the crate root
1916 /// without importing them. This is a [future-incompatible] lint to
1917 /// transition this to a hard error in the future. See [issue #50504] for
1920 /// [issue #50504]: https://github.com/rust-lang/rust/issues/50504
1921 /// [future-incompatible]: ../index.md#future-incompatible-lints
1922 pub PROC_MACRO_DERIVE_RESOLUTION_FALLBACK
,
1924 "detects proc macro derives using inaccessible names from parent modules",
1925 @future_incompatible
= FutureIncompatibleInfo
{
1926 reference
: "issue #83583 <https://github.com/rust-lang/rust/issues/83583>",
1931 /// The `macro_use_extern_crate` lint detects the use of the
1932 /// [`macro_use` attribute].
1936 /// ```rust,ignore (needs extern crate)
1937 /// #![deny(macro_use_extern_crate)]
1940 /// extern crate serde_json;
1943 /// let _ = json!{{}};
1947 /// This will produce:
1950 /// error: deprecated `#[macro_use]` attribute used to import macros should be replaced at use sites with a `use` item to import the macro instead
1951 /// --> src/main.rs:3:1
1953 /// 3 | #[macro_use]
1956 /// note: the lint level is defined here
1957 /// --> src/main.rs:1:9
1959 /// 1 | #![deny(macro_use_extern_crate)]
1960 /// | ^^^^^^^^^^^^^^^^^^^^^^
1965 /// The [`macro_use` attribute] on an [`extern crate`] item causes
1966 /// macros in that external crate to be brought into the prelude of the
1967 /// crate, making the macros in scope everywhere. As part of the efforts
1968 /// to simplify handling of dependencies in the [2018 edition], the use of
1969 /// `extern crate` is being phased out. To bring macros from extern crates
1970 /// into scope, it is recommended to use a [`use` import].
1972 /// This lint is "allow" by default because this is a stylistic choice
1973 /// that has not been settled, see [issue #52043] for more information.
1975 /// [`macro_use` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#the-macro_use-attribute
1976 /// [`use` import]: https://doc.rust-lang.org/reference/items/use-declarations.html
1977 /// [issue #52043]: https://github.com/rust-lang/rust/issues/52043
1978 pub MACRO_USE_EXTERN_CRATE
,
1980 "the `#[macro_use]` attribute is now deprecated in favor of using macros \
1981 via the module system"
1985 /// The `macro_expanded_macro_exports_accessed_by_absolute_paths` lint
1986 /// detects macro-expanded [`macro_export`] macros from the current crate
1987 /// that cannot be referred to by absolute paths.
1989 /// [`macro_export`]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
1993 /// ```rust,compile_fail
1994 /// macro_rules! define_exported {
1997 /// macro_rules! exported {
2003 /// define_exported!();
2006 /// crate::exported!();
2014 /// The intent is that all macros marked with the `#[macro_export]`
2015 /// attribute are made available in the root of the crate. However, when a
2016 /// `macro_rules!` definition is generated by another macro, the macro
2017 /// expansion is unable to uphold this rule. This is a
2018 /// [future-incompatible] lint to transition this to a hard error in the
2019 /// future. See [issue #53495] for more details.
2021 /// [issue #53495]: https://github.com/rust-lang/rust/issues/53495
2022 /// [future-incompatible]: ../index.md#future-incompatible-lints
2023 pub MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS
,
2025 "macro-expanded `macro_export` macros from the current crate \
2026 cannot be referred to by absolute paths",
2027 @future_incompatible
= FutureIncompatibleInfo
{
2028 reference
: "issue #52234 <https://github.com/rust-lang/rust/issues/52234>",
2034 /// The `explicit_outlives_requirements` lint detects unnecessary
2035 /// lifetime bounds that can be inferred.
2039 /// ```rust,compile_fail
2040 /// # #![allow(unused)]
2041 /// #![deny(explicit_outlives_requirements)]
2043 /// struct SharedRef<'a, T>
2055 /// If a `struct` contains a reference, such as `&'a T`, the compiler
2056 /// requires that `T` outlives the lifetime `'a`. This historically
2057 /// required writing an explicit lifetime bound to indicate this
2058 /// requirement. However, this can be overly explicit, causing clutter and
2059 /// unnecessary complexity. The language was changed to automatically
2060 /// infer the bound if it is not specified. Specifically, if the struct
2061 /// contains a reference, directly or indirectly, to `T` with lifetime
2062 /// `'x`, then it will infer that `T: 'x` is a requirement.
2064 /// This lint is "allow" by default because it can be noisy for existing
2065 /// code that already had these requirements. This is a stylistic choice,
2066 /// as it is still valid to explicitly state the bound. It also has some
2067 /// false positives that can cause confusion.
2069 /// See [RFC 2093] for more details.
2071 /// [RFC 2093]: https://github.com/rust-lang/rfcs/blob/master/text/2093-infer-outlives.md
2072 pub EXPLICIT_OUTLIVES_REQUIREMENTS
,
2074 "outlives requirements can be inferred"
2078 /// The `indirect_structural_match` lint detects a `const` in a pattern
2079 /// that manually implements [`PartialEq`] and [`Eq`].
2081 /// [`PartialEq`]: https://doc.rust-lang.org/std/cmp/trait.PartialEq.html
2082 /// [`Eq`]: https://doc.rust-lang.org/std/cmp/trait.Eq.html
2086 /// ```rust,compile_fail
2087 /// #![deny(indirect_structural_match)]
2089 /// struct NoDerive(i32);
2090 /// impl PartialEq for NoDerive { fn eq(&self, _: &Self) -> bool { false } }
2091 /// impl Eq for NoDerive { }
2092 /// #[derive(PartialEq, Eq)]
2093 /// struct WrapParam<T>(T);
2094 /// const WRAP_INDIRECT_PARAM: & &WrapParam<NoDerive> = & &WrapParam(NoDerive(0));
2096 /// match WRAP_INDIRECT_PARAM {
2097 /// WRAP_INDIRECT_PARAM => { }
2107 /// The compiler unintentionally accepted this form in the past. This is a
2108 /// [future-incompatible] lint to transition this to a hard error in the
2109 /// future. See [issue #62411] for a complete description of the problem,
2110 /// and some possible solutions.
2112 /// [issue #62411]: https://github.com/rust-lang/rust/issues/62411
2113 /// [future-incompatible]: ../index.md#future-incompatible-lints
2114 pub INDIRECT_STRUCTURAL_MATCH
,
2116 "constant used in pattern contains value of non-structural-match type in a field or a variant",
2117 @future_incompatible
= FutureIncompatibleInfo
{
2118 reference
: "issue #62411 <https://github.com/rust-lang/rust/issues/62411>",
2123 /// The `deprecated_in_future` lint is internal to rustc and should not be
2124 /// used by user code.
2126 /// This lint is only enabled in the standard library. It works with the
2127 /// use of `#[rustc_deprecated]` with a `since` field of a version in the
2128 /// future. This allows something to be marked as deprecated in a future
2129 /// version, and then this lint will ensure that the item is no longer
2130 /// used in the standard library. See the [stability documentation] for
2133 /// [stability documentation]: https://rustc-dev-guide.rust-lang.org/stability.html#rustc_deprecated
2134 pub DEPRECATED_IN_FUTURE
,
2136 "detects use of items that will be deprecated in a future version",
2137 report_in_external_macro
2141 /// The `pointer_structural_match` lint detects pointers used in patterns whose behaviour
2142 /// cannot be relied upon across compiler versions and optimization levels.
2146 /// ```rust,compile_fail
2147 /// #![deny(pointer_structural_match)]
2148 /// fn foo(a: usize, b: usize) -> usize { a + b }
2149 /// const FOO: fn(usize, usize) -> usize = foo;
2162 /// Previous versions of Rust allowed function pointers and wide raw pointers in patterns.
2163 /// While these work in many cases as expected by users, it is possible that due to
2164 /// optimizations pointers are "not equal to themselves" or pointers to different functions
2165 /// compare as equal during runtime. This is because LLVM optimizations can deduplicate
2166 /// functions if their bodies are the same, thus also making pointers to these functions point
2167 /// to the same location. Additionally functions may get duplicated if they are instantiated
2168 /// in different crates and not deduplicated again via LTO.
2169 pub POINTER_STRUCTURAL_MATCH
,
2171 "pointers are not structural-match",
2172 @future_incompatible
= FutureIncompatibleInfo
{
2173 reference
: "issue #62411 <https://github.com/rust-lang/rust/issues/70861>",
2178 /// The `nontrivial_structural_match` lint detects constants that are used in patterns,
2179 /// whose type is not structural-match and whose initializer body actually uses values
2180 /// that are not structural-match. So `Option<NotStruturalMatch>` is ok if the constant
2185 /// ```rust,compile_fail
2186 /// #![deny(nontrivial_structural_match)]
2188 /// #[derive(Copy, Clone, Debug)]
2189 /// struct NoDerive(u32);
2190 /// impl PartialEq for NoDerive { fn eq(&self, _: &Self) -> bool { false } }
2191 /// impl Eq for NoDerive { }
2193 /// const INDEX: Option<NoDerive> = [None, Some(NoDerive(10))][0];
2194 /// match None { Some(_) => panic!("whoops"), INDEX => dbg!(INDEX), };
2202 /// Previous versions of Rust accepted constants in patterns, even if those constants's types
2203 /// did not have `PartialEq` derived. Thus the compiler falls back to runtime execution of
2204 /// `PartialEq`, which can report that two constants are not equal even if they are
2206 pub NONTRIVIAL_STRUCTURAL_MATCH
,
2208 "constant used in pattern of non-structural-match type and the constant's initializer \
2209 expression contains values of non-structural-match types",
2210 @future_incompatible
= FutureIncompatibleInfo
{
2211 reference
: "issue #73448 <https://github.com/rust-lang/rust/issues/73448>",
2216 /// The `ambiguous_associated_items` lint detects ambiguity between
2217 /// [associated items] and [enum variants].
2219 /// [associated items]: https://doc.rust-lang.org/reference/items/associated-items.html
2220 /// [enum variants]: https://doc.rust-lang.org/reference/items/enumerations.html
2224 /// ```rust,compile_fail
2231 /// fn foo() -> Self::V;
2236 /// // `Self::V` is ambiguous because it may refer to the associated type or
2237 /// // the enum variant.
2238 /// fn foo() -> Self::V { 0 }
2246 /// Previous versions of Rust did not allow accessing enum variants
2247 /// through [type aliases]. When this ability was added (see [RFC 2338]), this
2248 /// introduced some situations where it can be ambiguous what a type
2249 /// was referring to.
2251 /// To fix this ambiguity, you should use a [qualified path] to explicitly
2252 /// state which type to use. For example, in the above example the
2253 /// function can be written as `fn f() -> <Self as Tr>::V { 0 }` to
2254 /// specifically refer to the associated type.
2256 /// This is a [future-incompatible] lint to transition this to a hard
2257 /// error in the future. See [issue #57644] for more details.
2259 /// [issue #57644]: https://github.com/rust-lang/rust/issues/57644
2260 /// [type aliases]: https://doc.rust-lang.org/reference/items/type-aliases.html#type-aliases
2261 /// [RFC 2338]: https://github.com/rust-lang/rfcs/blob/master/text/2338-type-alias-enum-variants.md
2262 /// [qualified path]: https://doc.rust-lang.org/reference/paths.html#qualified-paths
2263 /// [future-incompatible]: ../index.md#future-incompatible-lints
2264 pub AMBIGUOUS_ASSOCIATED_ITEMS
,
2266 "ambiguous associated items",
2267 @future_incompatible
= FutureIncompatibleInfo
{
2268 reference
: "issue #57644 <https://github.com/rust-lang/rust/issues/57644>",
2273 /// The `mutable_borrow_reservation_conflict` lint detects the reservation
2274 /// of a two-phased borrow that conflicts with other shared borrows.
2279 /// let mut v = vec![0, 1, 2];
2280 /// let shared = &v;
2281 /// v.push(shared.len());
2288 /// This is a [future-incompatible] lint to transition this to a hard error
2289 /// in the future. See [issue #59159] for a complete description of the
2290 /// problem, and some possible solutions.
2292 /// [issue #59159]: https://github.com/rust-lang/rust/issues/59159
2293 /// [future-incompatible]: ../index.md#future-incompatible-lints
2294 pub MUTABLE_BORROW_RESERVATION_CONFLICT
,
2296 "reservation of a two-phased borrow conflicts with other shared borrows",
2297 @future_incompatible
= FutureIncompatibleInfo
{
2298 reference
: "issue #59159 <https://github.com/rust-lang/rust/issues/59159>",
2303 /// The `soft_unstable` lint detects unstable features that were
2304 /// unintentionally allowed on stable.
2308 /// ```rust,compile_fail
2310 /// extern crate test;
2313 /// fn name(b: &mut test::Bencher) {
2322 /// The [`bench` attribute] was accidentally allowed to be specified on
2323 /// the [stable release channel]. Turning this to a hard error would have
2324 /// broken some projects. This lint allows those projects to continue to
2325 /// build correctly when [`--cap-lints`] is used, but otherwise signal an
2326 /// error that `#[bench]` should not be used on the stable channel. This
2327 /// is a [future-incompatible] lint to transition this to a hard error in
2328 /// the future. See [issue #64266] for more details.
2330 /// [issue #64266]: https://github.com/rust-lang/rust/issues/64266
2331 /// [`bench` attribute]: https://doc.rust-lang.org/nightly/unstable-book/library-features/test.html
2332 /// [stable release channel]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
2333 /// [`--cap-lints`]: https://doc.rust-lang.org/rustc/lints/levels.html#capping-lints
2334 /// [future-incompatible]: ../index.md#future-incompatible-lints
2337 "a feature gate that doesn't break dependent crates",
2338 @future_incompatible
= FutureIncompatibleInfo
{
2339 reference
: "issue #64266 <https://github.com/rust-lang/rust/issues/64266>",
2344 /// The `inline_no_sanitize` lint detects incompatible use of
2345 /// [`#[inline(always)]`][inline] and [`#[no_sanitize(...)]`][no_sanitize].
2347 /// [inline]: https://doc.rust-lang.org/reference/attributes/codegen.html#the-inline-attribute
2348 /// [no_sanitize]: https://doc.rust-lang.org/nightly/unstable-book/language-features/no-sanitize.html
2353 /// #![feature(no_sanitize)]
2355 /// #[inline(always)]
2356 /// #[no_sanitize(address)]
2368 /// The use of the [`#[inline(always)]`][inline] attribute prevents the
2369 /// the [`#[no_sanitize(...)]`][no_sanitize] attribute from working.
2370 /// Consider temporarily removing `inline` attribute.
2371 pub INLINE_NO_SANITIZE
,
2373 "detects incompatible use of `#[inline(always)]` and `#[no_sanitize(...)]`",
2377 /// The `asm_sub_register` lint detects using only a subset of a register
2378 /// for inline asm inputs.
2382 /// ```rust,ignore (fails on system llvm)
2383 /// #![feature(asm)]
2386 /// #[cfg(target_arch="x86_64")]
2388 /// asm!("mov {0}, {0}", in(reg) 0i16);
2393 /// This will produce:
2396 /// warning: formatting may not be suitable for sub-register argument
2397 /// --> src/main.rs:6:19
2399 /// 6 | asm!("mov {0}, {0}", in(reg) 0i16);
2400 /// | ^^^ ^^^ ---- for this argument
2402 /// = note: `#[warn(asm_sub_register)]` on by default
2403 /// = help: use the `x` modifier to have the register formatted as `ax`
2404 /// = help: or use the `r` modifier to keep the default formatting of `rax`
2409 /// Registers on some architectures can use different names to refer to a
2410 /// subset of the register. By default, the compiler will use the name for
2411 /// the full register size. To explicitly use a subset of the register,
2412 /// you can override the default by using a modifier on the template
2413 /// string operand to specify when subregister to use. This lint is issued
2414 /// if you pass in a value with a smaller data type than the default
2415 /// register size, to alert you of possibly using the incorrect width. To
2416 /// fix this, add the suggested modifier to the template, or cast the
2417 /// value to the correct size.
2419 /// See [register template modifiers] for more details.
2421 /// [register template modifiers]: https://doc.rust-lang.org/nightly/unstable-book/library-features/asm.html#register-template-modifiers
2422 pub ASM_SUB_REGISTER
,
2424 "using only a subset of a register for inline asm inputs",
2428 /// The `bad_asm_style` lint detects the use of the `.intel_syntax` and
2429 /// `.att_syntax` directives.
2433 /// ```rust,ignore (fails on system llvm)
2434 /// #![feature(asm)]
2437 /// #[cfg(target_arch="x86_64")]
2441 /// "movl {0}, {0}", in(reg) 0usize
2447 /// This will produce:
2450 /// warning: avoid using `.att_syntax`, prefer using `options(att_syntax)` instead
2451 /// --> test.rs:7:14
2453 /// 7 | ".att_syntax",
2455 /// 8 | "movq {0}, {0}", out(reg) _,
2457 /// | - help: add option: `, options(att_syntax)`
2459 /// = note: `#[warn(bad_asm_style)]` on by default
2464 /// On x86, `asm!` uses the intel assembly syntax by default. While this
2465 /// can be switched using assembler directives like `.att_syntax`, using the
2466 /// `att_syntax` option is recommended instead because it will also properly
2467 /// prefix register placeholders with `%` as required by AT&T syntax.
2470 "incorrect use of inline assembly",
2474 /// The `unsafe_op_in_unsafe_fn` lint detects unsafe operations in unsafe
2475 /// functions without an explicit unsafe block.
2479 /// ```rust,compile_fail
2480 /// #![deny(unsafe_op_in_unsafe_fn)]
2482 /// unsafe fn foo() {}
2484 /// unsafe fn bar() {
2495 /// Currently, an [`unsafe fn`] allows any [unsafe] operation within its
2496 /// body. However, this can increase the surface area of code that needs
2497 /// to be scrutinized for proper behavior. The [`unsafe` block] provides a
2498 /// convenient way to make it clear exactly which parts of the code are
2499 /// performing unsafe operations. In the future, it is desired to change
2500 /// it so that unsafe operations cannot be performed in an `unsafe fn`
2501 /// without an `unsafe` block.
2503 /// The fix to this is to wrap the unsafe code in an `unsafe` block.
2505 /// This lint is "allow" by default since this will affect a large amount
2506 /// of existing code, and the exact plan for increasing the severity is
2507 /// still being considered. See [RFC #2585] and [issue #71668] for more
2510 /// [`unsafe fn`]: https://doc.rust-lang.org/reference/unsafe-functions.html
2511 /// [`unsafe` block]: https://doc.rust-lang.org/reference/expressions/block-expr.html#unsafe-blocks
2512 /// [unsafe]: https://doc.rust-lang.org/reference/unsafety.html
2513 /// [RFC #2585]: https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md
2514 /// [issue #71668]: https://github.com/rust-lang/rust/issues/71668
2515 pub UNSAFE_OP_IN_UNSAFE_FN
,
2517 "unsafe operations in unsafe functions without an explicit unsafe block are deprecated",
2521 /// The `cenum_impl_drop_cast` lint detects an `as` cast of a field-less
2522 /// `enum` that implements [`Drop`].
2524 /// [`Drop`]: https://doc.rust-lang.org/std/ops/trait.Drop.html
2529 /// # #![allow(unused)]
2534 /// impl Drop for E {
2535 /// fn drop(&mut self) {
2536 /// println!("Drop");
2542 /// let i = e as u32;
2550 /// Casting a field-less `enum` that does not implement [`Copy`] to an
2551 /// integer moves the value without calling `drop`. This can result in
2552 /// surprising behavior if it was expected that `drop` should be called.
2553 /// Calling `drop` automatically would be inconsistent with other move
2554 /// operations. Since neither behavior is clear or consistent, it was
2555 /// decided that a cast of this nature will no longer be allowed.
2557 /// This is a [future-incompatible] lint to transition this to a hard error
2558 /// in the future. See [issue #73333] for more details.
2560 /// [future-incompatible]: ../index.md#future-incompatible-lints
2561 /// [issue #73333]: https://github.com/rust-lang/rust/issues/73333
2562 /// [`Copy`]: https://doc.rust-lang.org/std/marker/trait.Copy.html
2563 pub CENUM_IMPL_DROP_CAST
,
2565 "a C-like enum implementing Drop is cast",
2566 @future_incompatible
= FutureIncompatibleInfo
{
2567 reference
: "issue #73333 <https://github.com/rust-lang/rust/issues/73333>",
2572 /// The `const_evaluatable_unchecked` lint detects a generic constant used
2578 /// const fn foo<T>() -> usize {
2579 /// if std::mem::size_of::<*mut T>() < 8 { // size of *mut T does not depend on T
2587 /// let _ = [0; foo::<T>()];
2595 /// In the 1.43 release, some uses of generic parameters in array repeat
2596 /// expressions were accidentally allowed. This is a [future-incompatible]
2597 /// lint to transition this to a hard error in the future. See [issue
2598 /// #76200] for a more detailed description and possible fixes.
2600 /// [future-incompatible]: ../index.md#future-incompatible-lints
2601 /// [issue #76200]: https://github.com/rust-lang/rust/issues/76200
2602 pub CONST_EVALUATABLE_UNCHECKED
,
2604 "detects a generic constant is used in a type without a emitting a warning",
2605 @future_incompatible
= FutureIncompatibleInfo
{
2606 reference
: "issue #76200 <https://github.com/rust-lang/rust/issues/76200>",
2611 /// The `function_item_references` lint detects function references that are
2612 /// formatted with [`fmt::Pointer`] or transmuted.
2614 /// [`fmt::Pointer`]: https://doc.rust-lang.org/std/fmt/trait.Pointer.html
2622 /// println!("{:p}", &foo);
2630 /// Taking a reference to a function may be mistaken as a way to obtain a
2631 /// pointer to that function. This can give unexpected results when
2632 /// formatting the reference as a pointer or transmuting it. This lint is
2633 /// issued when function references are formatted as pointers, passed as
2634 /// arguments bound by [`fmt::Pointer`] or transmuted.
2635 pub FUNCTION_ITEM_REFERENCES
,
2637 "suggest casting to a function pointer when attempting to take references to function items",
2641 /// The `uninhabited_static` lint detects uninhabited statics.
2648 /// static EXTERN: Void;
2656 /// Statics with an uninhabited type can never be initialized, so they are impossible to define.
2657 /// However, this can be side-stepped with an `extern static`, leading to problems later in the
2658 /// compiler which assumes that there are no initialized uninhabited places (such as locals or
2659 /// statics). This was accidentally allowed, but is being phased out.
2660 pub UNINHABITED_STATIC
,
2662 "uninhabited static",
2663 @future_incompatible
= FutureIncompatibleInfo
{
2664 reference
: "issue #74840 <https://github.com/rust-lang/rust/issues/74840>",
2669 /// The `useless_deprecated` lint detects deprecation attributes with no effect.
2673 /// ```rust,compile_fail
2676 /// #[deprecated = "message"]
2677 /// impl Default for X {
2678 /// fn default() -> Self {
2688 /// Deprecation attributes have no effect on trait implementations.
2689 pub USELESS_DEPRECATED
,
2691 "detects deprecation attributes with no effect",
2695 /// The `unsupported_naked_functions` lint detects naked function
2696 /// definitions that are unsupported but were previously accepted.
2701 /// #![feature(naked_functions)]
2704 /// pub fn f() -> u32 {
2713 /// The naked functions must be defined using a single inline assembly
2716 /// The execution must never fall through past the end of the assembly
2717 /// code so the block must use `noreturn` option. The asm block can also
2718 /// use `att_syntax` option, but other options are not allowed.
2720 /// The asm block must not contain any operands other than `const` and
2721 /// `sym`. Additionally, naked function should specify a non-Rust ABI.
2723 /// While other definitions of naked functions were previously accepted,
2724 /// they are unsupported and might not work reliably. This is a
2725 /// [future-incompatible] lint that will transition into hard error in
2728 /// [future-incompatible]: ../index.md#future-incompatible-lints
2729 pub UNSUPPORTED_NAKED_FUNCTIONS
,
2731 "unsupported naked function definitions",
2732 @future_incompatible
= FutureIncompatibleInfo
{
2733 reference
: "issue #32408 <https://github.com/rust-lang/rust/issues/32408>",
2738 /// The `ineffective_unstable_trait_impl` lint detects `#[unstable]` attributes which are not used.
2743 /// #![feature(staged_api)]
2745 /// #[derive(Clone)]
2746 /// #[stable(feature = "x", since = "1")]
2749 /// #[unstable(feature = "y", issue = "none")]
2750 /// impl Copy for S {}
2757 /// `staged_api` does not currently support using a stability attribute on `impl` blocks.
2758 /// `impl`s are always stable if both the type and trait are stable, and always unstable otherwise.
2759 pub INEFFECTIVE_UNSTABLE_TRAIT_IMPL
,
2761 "detects `#[unstable]` on stable trait implementations for stable types"
2765 /// The `semicolon_in_expressions_from_macros` lint detects trailing semicolons
2766 /// in macro bodies when the macro is invoked in expression position.
2767 /// This was previous accepted, but is being phased out.
2771 /// ```rust,compile_fail
2772 /// #![deny(semicolon_in_expressions_from_macros)]
2773 /// macro_rules! foo {
2778 /// let val = match true {
2789 /// Previous, Rust ignored trailing semicolon in a macro
2790 /// body when a macro was invoked in expression position.
2791 /// However, this makes the treatment of semicolons in the language
2792 /// inconsistent, and could lead to unexpected runtime behavior
2793 /// in some circumstances (e.g. if the macro author expects
2794 /// a value to be dropped).
2796 /// This is a [future-incompatible] lint to transition this
2797 /// to a hard error in the future. See [issue #79813] for more details.
2799 /// [issue #79813]: https://github.com/rust-lang/rust/issues/79813
2800 /// [future-incompatible]: ../index.md#future-incompatible-lints
2801 pub SEMICOLON_IN_EXPRESSIONS_FROM_MACROS
,
2803 "trailing semicolon in macro body used as expression",
2804 @future_incompatible
= FutureIncompatibleInfo
{
2805 reference
: "issue #79813 <https://github.com/rust-lang/rust/issues/79813>",
2810 /// The `legacy_derive_helpers` lint detects derive helper attributes
2811 /// that are used before they are introduced.
2815 /// ```rust,ignore (needs extern crate)
2816 /// #[serde(rename_all = "camelCase")]
2817 /// #[derive(Deserialize)]
2818 /// struct S { /* fields */ }
2824 /// warning: derive helper attribute is used before it is introduced
2825 /// --> $DIR/legacy-derive-helpers.rs:1:3
2827 /// 1 | #[serde(rename_all = "camelCase")]
2830 /// 2 | #[derive(Deserialize)]
2831 /// | ----------- the attribute is introduced here
2836 /// Attributes like this work for historical reasons, but attribute expansion works in
2837 /// left-to-right order in general, so, to resolve `#[serde]`, compiler has to try to "look
2838 /// into the future" at not yet expanded part of the item , but such attempts are not always
2841 /// To fix the warning place the helper attribute after its corresponding derive.
2842 /// ```rust,ignore (needs extern crate)
2843 /// #[derive(Deserialize)]
2844 /// #[serde(rename_all = "camelCase")]
2845 /// struct S { /* fields */ }
2847 pub LEGACY_DERIVE_HELPERS
,
2849 "detects derive helper attributes that are used before they are introduced",
2850 @future_incompatible
= FutureIncompatibleInfo
{
2851 reference
: "issue #79202 <https://github.com/rust-lang/rust/issues/79202>",
2856 /// The `large_assignments` lint detects when objects of large
2857 /// types are being moved around.
2861 /// ```rust,ignore (can crash on some platforms)
2862 /// let x = [0; 50000];
2869 /// warning: moving a large value
2870 /// --> $DIR/move-large.rs:1:3
2872 /// - Copied large value here
2877 /// When using a large type in a plain assignment or in a function
2878 /// argument, idiomatic code can be inefficient.
2879 /// Ideally appropriate optimizations would resolve this, but such
2880 /// optimizations are only done in a best-effort manner.
2881 /// This lint will trigger on all sites of large moves and thus allow the
2882 /// user to resolve them in code.
2883 pub LARGE_ASSIGNMENTS
,
2885 "detects large moves or copies",
2888 declare_lint_pass
! {
2889 /// Does nothing as a lint pass, but registers some `Lint`s
2890 /// that are used by other parts of the compiler.
2892 FORBIDDEN_LINT_GROUPS
,
2893 ILLEGAL_FLOATING_POINT_LITERAL_PATTERN
,
2894 ARITHMETIC_OVERFLOW
,
2895 UNCONDITIONAL_PANIC
,
2897 UNUSED_EXTERN_CRATES
,
2898 UNUSED_CRATE_DEPENDENCIES
,
2899 UNUSED_QUALIFICATIONS
,
2905 UNREACHABLE_PATTERNS
,
2906 OVERLAPPING_RANGE_ENDPOINTS
,
2907 BINDINGS_WITH_VARIANT_NAME
,
2912 UNKNOWN_CRATE_TYPES
,
2914 TRIVIAL_NUMERIC_CASTS
,
2916 EXPORTED_PRIVATE_DEPENDENCIES
,
2917 PUB_USE_OF_PRIVATE_EXTERN_CRATE
,
2918 INVALID_TYPE_PARAM_DEFAULT
,
2920 RENAMED_AND_REMOVED_LINTS
,
2921 UNALIGNED_REFERENCES
,
2922 CONST_ITEM_MUTATION
,
2923 PATTERNS_IN_FNS_WITHOUT_BODY
,
2924 MISSING_FRAGMENT_SPECIFIER
,
2925 LATE_BOUND_LIFETIME_ARGUMENTS
,
2926 ORDER_DEPENDENT_TRAIT_OBJECTS
,
2927 COHERENCE_LEAK_CHECK
,
2931 UNCONDITIONAL_RECURSION
,
2932 SINGLE_USE_LIFETIMES
,
2935 TYVAR_BEHIND_RAW_POINTER
,
2936 ELIDED_LIFETIMES_IN_PATHS
,
2938 ABSOLUTE_PATHS_NOT_STARTING_WITH_CRATE
,
2939 UNSTABLE_NAME_COLLISIONS
,
2940 IRREFUTABLE_LET_PATTERNS
,
2941 WHERE_CLAUSES_OBJECT_SAFETY
,
2942 PROC_MACRO_DERIVE_RESOLUTION_FALLBACK
,
2943 MACRO_USE_EXTERN_CRATE
,
2944 MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS
,
2945 ILL_FORMED_ATTRIBUTE_INPUT
,
2946 CONFLICTING_REPR_HINTS
,
2947 META_VARIABLE_MISUSE
,
2948 DEPRECATED_IN_FUTURE
,
2949 AMBIGUOUS_ASSOCIATED_ITEMS
,
2950 MUTABLE_BORROW_RESERVATION_CONFLICT
,
2951 INDIRECT_STRUCTURAL_MATCH
,
2952 POINTER_STRUCTURAL_MATCH
,
2953 NONTRIVIAL_STRUCTURAL_MATCH
,
2958 UNSAFE_OP_IN_UNSAFE_FN
,
2960 CENUM_IMPL_DROP_CAST
,
2961 CONST_EVALUATABLE_UNCHECKED
,
2962 INEFFECTIVE_UNSTABLE_TRAIT_IMPL
,
2964 FUNCTION_ITEM_REFERENCES
,
2966 UNSUPPORTED_NAKED_FUNCTIONS
,
2968 INVALID_DOC_ATTRIBUTES
,
2969 SEMICOLON_IN_EXPRESSIONS_FROM_MACROS
,
2970 RUST_2021_INCOMPATIBLE_CLOSURE_CAPTURES
,
2971 LEGACY_DERIVE_HELPERS
,
2972 PROC_MACRO_BACK_COMPAT
,
2973 RUST_2021_INCOMPATIBLE_OR_PATTERNS
,
2975 RUST_2021_PRELUDE_COLLISIONS
,
2976 RUST_2021_PREFIXES_INCOMPATIBLE_SYNTAX
,
2977 UNSUPPORTED_CALLING_CONVENTIONS
,
2982 /// The `unused_doc_comments` lint detects doc comments that aren't used
2996 /// `rustdoc` does not use doc comments in all positions, and so the doc
2997 /// comment will be ignored. Try changing it to a normal comment with `//`
2998 /// to avoid the warning.
2999 pub UNUSED_DOC_COMMENTS
,
3001 "detects doc comments that aren't used by rustdoc"
3005 /// The `rust_2021_incompatible_closure_captures` lint detects variables that aren't completely
3006 /// captured in Rust 2021 and affect the Drop order of at least one path starting at this variable.
3007 /// It can also detect when a variable implements a trait, but one of its field does not and
3008 /// the field is captured by a closure and used with the assumption that said field implements
3009 /// the same trait as the root variable.
3011 /// ### Example of drop reorder
3013 /// ```rust,compile_fail
3014 /// # #![deny(rust_2021_incompatible_closure_captures)]
3015 /// # #![allow(unused)]
3016 /// struct FancyInteger(i32);
3018 /// impl Drop for FancyInteger {
3019 /// fn drop(&mut self) {
3020 /// println!("Just dropped {}", self.0);
3024 /// struct Point { x: FancyInteger, y: FancyInteger }
3027 /// let p = Point { x: FancyInteger(10), y: FancyInteger(20) };
3035 /// // ... More code ...
3043 /// In the above example, `p.y` will be dropped at the end of `f` instead of
3044 /// with `c` in Rust 2021.
3046 /// ### Example of auto-trait
3048 /// ```rust,compile_fail
3049 /// #![deny(rust_2021_incompatible_closure_captures)]
3050 /// use std::thread;
3052 /// struct Pointer(*mut i32);
3053 /// unsafe impl Send for Pointer {}
3057 /// let fptr = Pointer(&mut f as *mut i32);
3058 /// thread::spawn(move || unsafe {
3068 /// In the above example, only `fptr.0` is captured in Rust 2021.
3069 /// The field is of type *mut i32 which doesn't implement Send, making the code invalid as the
3070 /// field cannot be sent between thread safely.
3071 pub RUST_2021_INCOMPATIBLE_CLOSURE_CAPTURES
,
3073 "detects closures affected by Rust 2021 changes",
3074 @future_incompatible
= FutureIncompatibleInfo
{
3075 reason
: FutureIncompatibilityReason
::EditionSemanticsChange(Edition
::Edition2021
),
3076 explain_reason
: false,
3080 declare_lint_pass
!(UnusedDocComment
=> [UNUSED_DOC_COMMENTS
]);
3083 /// The `missing_abi` lint detects cases where the ABI is omitted from
3084 /// extern declarations.
3088 /// ```rust,compile_fail
3089 /// #![deny(missing_abi)]
3091 /// extern fn foo() {}
3098 /// Historically, Rust implicitly selected C as the ABI for extern
3099 /// declarations. We expect to add new ABIs, like `C-unwind`, in the future,
3100 /// though this has not yet happened, and especially with their addition
3101 /// seeing the ABI easily will make code review easier.
3104 "No declared ABI for extern declaration"
3108 /// The `invalid_doc_attributes` lint detects when the `#[doc(...)]` is
3113 /// ```rust,compile_fail
3114 /// #![deny(warnings)]
3116 /// pub mod submodule {
3117 /// #![doc(test(no_crate_inject))]
3125 /// Previously, there were very like checks being performed on `#[doc(..)]`
3126 /// unlike the other attributes. It'll now catch all the issues that it
3127 /// silently ignored previously.
3128 pub INVALID_DOC_ATTRIBUTES
,
3130 "detects invalid `#[doc(...)]` attributes",
3131 @future_incompatible
= FutureIncompatibleInfo
{
3132 reference
: "issue #82730 <https://github.com/rust-lang/rust/issues/82730>",
3137 /// The `proc_macro_back_compat` lint detects uses of old versions of certain
3138 /// proc-macro crates, which have hardcoded workarounds in the compiler.
3142 /// ```rust,ignore (needs-dependency)
3144 /// use time_macros_impl::impl_macros;
3146 /// impl_macros!(Foo);
3149 /// This will produce:
3152 /// warning: using an old version of `time-macros-impl`
3153 /// ::: $DIR/group-compat-hack.rs:27:5
3155 /// LL | impl_macros!(Foo);
3156 /// | ------------------ in this macro invocation
3158 /// = note: `#[warn(proc_macro_back_compat)]` on by default
3159 /// = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
3160 /// = note: for more information, see issue #83125 <https://github.com/rust-lang/rust/issues/83125>
3161 /// = note: the `time-macros-impl` crate will stop compiling in futures version of Rust. Please update to the latest version of the `time` crate to avoid breakage
3162 /// = note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
3167 /// Eventually, the backwards-compatibility hacks present in the compiler will be removed,
3168 /// causing older versions of certain crates to stop compiling.
3169 /// This is a [future-incompatible] lint to ease the transition to an error.
3170 /// See [issue #83125] for more details.
3172 /// [issue #83125]: https://github.com/rust-lang/rust/issues/83125
3173 /// [future-incompatible]: ../index.md#future-incompatible-lints
3174 pub PROC_MACRO_BACK_COMPAT
,
3176 "detects usage of old versions of certain proc-macro crates",
3177 @future_incompatible
= FutureIncompatibleInfo
{
3178 reference
: "issue #83125 <https://github.com/rust-lang/rust/issues/83125>",
3179 reason
: FutureIncompatibilityReason
::FutureReleaseErrorReportNow
,
3184 /// The `rust_2021_incompatible_or_patterns` lint detects usage of old versions of or-patterns.
3188 /// ```rust,compile_fail
3189 /// #![deny(rust_2021_incompatible_or_patterns)]
3190 /// macro_rules! match_any {
3191 /// ( $expr:expr , $( $( $pat:pat )|+ => $expr_arm:expr ),+ ) => {
3194 /// $( $pat => $expr_arm, )+
3201 /// let result: Result<i64, i32> = Err(42);
3202 /// let int: i64 = match_any!(result, Ok(i) | Err(i) => i.into());
3203 /// assert_eq!(int, 42);
3211 /// In Rust 2021, the pat matcher will match new patterns, which include the | character.
3212 pub RUST_2021_INCOMPATIBLE_OR_PATTERNS
,
3214 "detects usage of old versions of or-patterns",
3215 @future_incompatible
= FutureIncompatibleInfo
{
3216 reference
: "issue #84869 <https://github.com/rust-lang/rust/issues/84869>",
3217 reason
: FutureIncompatibilityReason
::EditionError(Edition
::Edition2021
),
3222 /// The `rust_2021_prelude_collisions` lint detects the usage of trait methods which are ambiguous
3223 /// with traits added to the prelude in future editions.
3227 /// ```rust,compile_fail
3228 /// #![deny(rust_2021_prelude_collisions)]
3231 /// fn try_into(self) -> Result<String, !>;
3234 /// impl Foo for &str {
3235 /// fn try_into(self) -> Result<String, !> {
3236 /// Ok(String::from(self))
3241 /// let x: String = "3".try_into().unwrap();
3243 /// // This call to try_into matches both Foo:try_into and TryInto::try_into as
3244 /// // `TryInto` has been added to the Rust prelude in 2021 edition.
3245 /// println!("{}", x);
3253 /// In Rust 2021, one of the important introductions is the [prelude changes], which add
3254 /// `TryFrom`, `TryInto`, and `FromIterator` into the standard library's prelude. Since this
3255 /// results in an ambiguity as to which method/function to call when an existing `try_into`
3256 /// method is called via dot-call syntax or a `try_from`/`from_iter` associated function
3257 /// is called directly on a type.
3259 /// [prelude changes]: https://blog.rust-lang.org/inside-rust/2021/03/04/planning-rust-2021.html#prelude-changes
3260 pub RUST_2021_PRELUDE_COLLISIONS
,
3262 "detects the usage of trait methods which are ambiguous with traits added to the \
3263 prelude in future editions",
3264 @future_incompatible
= FutureIncompatibleInfo
{
3265 reference
: "issue #85684 <https://github.com/rust-lang/rust/issues/85684>",
3266 reason
: FutureIncompatibilityReason
::EditionError(Edition
::Edition2021
),
3271 /// The `rust_2021_prefixes_incompatible_syntax` lint detects identifiers that will be parsed as a
3272 /// prefix instead in Rust 2021.
3276 /// ```rust,compile_fail
3277 /// #![deny(rust_2021_prefixes_incompatible_syntax)]
3279 /// macro_rules! m {
3280 /// (z $x:expr) => ();
3290 /// In Rust 2015 and 2018, `z"hey"` is two tokens: the identifier `z`
3291 /// followed by the string literal `"hey"`. In Rust 2021, the `z` is
3292 /// considered a prefix for `"hey"`.
3294 /// This lint suggests to add whitespace between the `z` and `"hey"` tokens
3295 /// to keep them separated in Rust 2021.
3296 pub RUST_2021_PREFIXES_INCOMPATIBLE_SYNTAX
,
3298 "identifiers that will be parsed as a prefix in Rust 2021",
3299 @future_incompatible
= FutureIncompatibleInfo
{
3300 reference
: "issue #84978 <https://github.com/rust-lang/rust/issues/84978>",
3301 reason
: FutureIncompatibilityReason
::EditionError(Edition
::Edition2021
),
3307 /// The `unsupported_calling_conventions` lint is output whenever there is an use of the
3308 /// `stdcall`, `fastcall`, `thiscall`, `vectorcall` calling conventions (or their unwind
3309 /// variants) on targets that cannot meaningfully be supported for the requested target.
3311 /// For example `stdcall` does not make much sense for a x86_64 or, more apparently, powerpc
3312 /// code, because this calling convention was never specified for those targets.
3314 /// Historically MSVC toolchains have fallen back to the regular C calling convention for
3315 /// targets other than x86, but Rust doesn't really see a similar need to introduce a similar
3316 /// hack across many more targets.
3320 /// ```rust,ignore (needs specific targets)
3321 /// extern "stdcall" fn stdcall() {}
3324 /// This will produce:
3327 /// warning: use of calling convention not supported on this target
3328 /// --> $DIR/unsupported.rs:39:1
3330 /// LL | extern "stdcall" fn stdcall() {}
3331 /// | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3333 /// = note: `#[warn(unsupported_calling_conventions)]` on by default
3334 /// = warning: this was previously accepted by the compiler but is being phased out;
3335 /// it will become a hard error in a future release!
3336 /// = note: for more information, see issue ...
3341 /// On most of the targets the behaviour of `stdcall` and similar calling conventions is not
3342 /// defined at all, but was previously accepted due to a bug in the implementation of the
3344 pub UNSUPPORTED_CALLING_CONVENTIONS
,
3346 "use of unsupported calling convention",
3347 @future_incompatible
= FutureIncompatibleInfo
{
3348 reference
: "issue #87678 <https://github.com/rust-lang/rust/issues/87678>",