rustc_lint_defs/
builtin.rs

1//! Some lints that are built in to the compiler.
2//!
3//! These are the built-in lints that are emitted direct in the main
4//! compiler code, rather than using their own custom pass. Those
5//! lints are all available in `rustc_lint::builtin`.
6//!
7//! When removing a lint, make sure to also add a call to `register_removed` in
8//! compiler/rustc_lint/src/lib.rs.
9
10use rustc_span::edition::Edition;
11
12use crate::{FutureIncompatibilityReason, declare_lint, declare_lint_pass};
13
14declare_lint_pass! {
15    /// Does nothing as a lint pass, but registers some `Lint`s
16    /// that are used by other parts of the compiler.
17    HardwiredLints => [
18        // tidy-alphabetical-start
19        ABI_UNSUPPORTED_VECTOR_TYPES,
20        ABSOLUTE_PATHS_NOT_STARTING_WITH_CRATE,
21        AMBIGUOUS_ASSOCIATED_ITEMS,
22        AMBIGUOUS_GLOB_IMPORTS,
23        AMBIGUOUS_GLOB_REEXPORTS,
24        ARITHMETIC_OVERFLOW,
25        ASM_SUB_REGISTER,
26        BAD_ASM_STYLE,
27        BARE_TRAIT_OBJECTS,
28        BINDINGS_WITH_VARIANT_NAME,
29        BREAK_WITH_LABEL_AND_LOOP,
30        COHERENCE_LEAK_CHECK,
31        CONFLICTING_REPR_HINTS,
32        CONST_EVALUATABLE_UNCHECKED,
33        CONST_ITEM_MUTATION,
34        DEAD_CODE,
35        DEPENDENCY_ON_UNIT_NEVER_TYPE_FALLBACK,
36        DEPRECATED,
37        DEPRECATED_IN_FUTURE,
38        DEPRECATED_SAFE_2024,
39        DEPRECATED_WHERE_CLAUSE_LOCATION,
40        DUPLICATE_MACRO_ATTRIBUTES,
41        ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT,
42        ELIDED_LIFETIMES_IN_PATHS,
43        ELIDED_NAMED_LIFETIMES,
44        EXPLICIT_BUILTIN_CFGS_IN_FLAGS,
45        EXPORTED_PRIVATE_DEPENDENCIES,
46        FFI_UNWIND_CALLS,
47        FORBIDDEN_LINT_GROUPS,
48        FUNCTION_ITEM_REFERENCES,
49        FUZZY_PROVENANCE_CASTS,
50        HIDDEN_GLOB_REEXPORTS,
51        ILL_FORMED_ATTRIBUTE_INPUT,
52        INCOMPLETE_INCLUDE,
53        INEFFECTIVE_UNSTABLE_TRAIT_IMPL,
54        INLINE_NO_SANITIZE,
55        INVALID_DOC_ATTRIBUTES,
56        INVALID_MACRO_EXPORT_ARGUMENTS,
57        INVALID_TYPE_PARAM_DEFAULT,
58        IRREFUTABLE_LET_PATTERNS,
59        LARGE_ASSIGNMENTS,
60        LATE_BOUND_LIFETIME_ARGUMENTS,
61        LEGACY_DERIVE_HELPERS,
62        LINKER_MESSAGES,
63        LONG_RUNNING_CONST_EVAL,
64        LOSSY_PROVENANCE_CASTS,
65        MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS,
66        MACRO_USE_EXTERN_CRATE,
67        META_VARIABLE_MISUSE,
68        MISSING_ABI,
69        MISSING_FRAGMENT_SPECIFIER,
70        MISSING_UNSAFE_ON_EXTERN,
71        MUST_NOT_SUSPEND,
72        NAMED_ARGUMENTS_USED_POSITIONALLY,
73        NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE,
74        NON_CONTIGUOUS_RANGE_ENDPOINTS,
75        NON_EXHAUSTIVE_OMITTED_PATTERNS,
76        OUT_OF_SCOPE_MACRO_CALLS,
77        OVERLAPPING_RANGE_ENDPOINTS,
78        PATTERNS_IN_FNS_WITHOUT_BODY,
79        PRIVATE_BOUNDS,
80        PRIVATE_INTERFACES,
81        PROC_MACRO_DERIVE_RESOLUTION_FALLBACK,
82        PTR_TO_INTEGER_TRANSMUTE_IN_CONSTS,
83        PUB_USE_OF_PRIVATE_EXTERN_CRATE,
84        REDUNDANT_IMPORTS,
85        REDUNDANT_LIFETIMES,
86        REFINING_IMPL_TRAIT_INTERNAL,
87        REFINING_IMPL_TRAIT_REACHABLE,
88        RENAMED_AND_REMOVED_LINTS,
89        REPR_TRANSPARENT_EXTERNAL_PRIVATE_FIELDS,
90        RUST_2021_INCOMPATIBLE_CLOSURE_CAPTURES,
91        RUST_2021_INCOMPATIBLE_OR_PATTERNS,
92        RUST_2021_PREFIXES_INCOMPATIBLE_SYNTAX,
93        RUST_2021_PRELUDE_COLLISIONS,
94        RUST_2024_GUARDED_STRING_INCOMPATIBLE_SYNTAX,
95        RUST_2024_INCOMPATIBLE_PAT,
96        RUST_2024_PRELUDE_COLLISIONS,
97        SELF_CONSTRUCTOR_FROM_OUTER_ITEM,
98        SEMICOLON_IN_EXPRESSIONS_FROM_MACROS,
99        SINGLE_USE_LIFETIMES,
100        SOFT_UNSTABLE,
101        STABLE_FEATURES,
102        SUPERTRAIT_ITEM_SHADOWING_DEFINITION,
103        SUPERTRAIT_ITEM_SHADOWING_USAGE,
104        TAIL_EXPR_DROP_ORDER,
105        TEST_UNSTABLE_LINT,
106        TEXT_DIRECTION_CODEPOINT_IN_COMMENT,
107        TRIVIAL_CASTS,
108        TRIVIAL_NUMERIC_CASTS,
109        TYVAR_BEHIND_RAW_POINTER,
110        UNCONDITIONAL_PANIC,
111        UNCONDITIONAL_RECURSION,
112        UNCOVERED_PARAM_IN_PROJECTION,
113        UNEXPECTED_CFGS,
114        UNFULFILLED_LINT_EXPECTATIONS,
115        UNINHABITED_STATIC,
116        UNKNOWN_CRATE_TYPES,
117        UNKNOWN_LINTS,
118        UNKNOWN_OR_MALFORMED_DIAGNOSTIC_ATTRIBUTES,
119        UNNAMEABLE_TEST_ITEMS,
120        UNNAMEABLE_TYPES,
121        UNREACHABLE_CODE,
122        UNREACHABLE_PATTERNS,
123        UNSAFE_ATTR_OUTSIDE_UNSAFE,
124        UNSAFE_OP_IN_UNSAFE_FN,
125        UNSTABLE_NAME_COLLISIONS,
126        UNSTABLE_SYNTAX_PRE_EXPANSION,
127        UNSUPPORTED_FN_PTR_CALLING_CONVENTIONS,
128        UNUSED_ASSIGNMENTS,
129        UNUSED_ASSOCIATED_TYPE_BOUNDS,
130        UNUSED_ATTRIBUTES,
131        UNUSED_CRATE_DEPENDENCIES,
132        UNUSED_EXTERN_CRATES,
133        UNUSED_FEATURES,
134        UNUSED_IMPORTS,
135        UNUSED_LABELS,
136        UNUSED_LIFETIMES,
137        UNUSED_MACRO_RULES,
138        UNUSED_MACROS,
139        UNUSED_MUT,
140        UNUSED_QUALIFICATIONS,
141        UNUSED_UNSAFE,
142        UNUSED_VARIABLES,
143        USELESS_DEPRECATED,
144        WARNINGS,
145        WASM_C_ABI,
146        // tidy-alphabetical-end
147    ]
148}
149
150declare_lint! {
151    /// The `forbidden_lint_groups` lint detects violations of
152    /// `forbid` applied to a lint group. Due to a bug in the compiler,
153    /// these used to be overlooked entirely. They now generate a warning.
154    ///
155    /// ### Example
156    ///
157    /// ```rust
158    /// #![forbid(warnings)]
159    /// #![warn(bad_style)]
160    ///
161    /// fn main() {}
162    /// ```
163    ///
164    /// {{produces}}
165    ///
166    /// ### Recommended fix
167    ///
168    /// If your crate is using `#![forbid(warnings)]`,
169    /// we recommend that you change to `#![deny(warnings)]`.
170    ///
171    /// ### Explanation
172    ///
173    /// Due to a compiler bug, applying `forbid` to lint groups
174    /// previously had no effect. The bug is now fixed but instead of
175    /// enforcing `forbid` we issue this future-compatibility warning
176    /// to avoid breaking existing crates.
177    pub FORBIDDEN_LINT_GROUPS,
178    Warn,
179    "applying forbid to lint-groups",
180    @future_incompatible = FutureIncompatibleInfo {
181        reason: FutureIncompatibilityReason::FutureReleaseErrorReportInDeps,
182        reference: "issue #81670 <https://github.com/rust-lang/rust/issues/81670>",
183    };
184}
185
186declare_lint! {
187    /// The `ill_formed_attribute_input` lint detects ill-formed attribute
188    /// inputs that were previously accepted and used in practice.
189    ///
190    /// ### Example
191    ///
192    /// ```rust,compile_fail
193    /// #[inline = "this is not valid"]
194    /// fn foo() {}
195    /// ```
196    ///
197    /// {{produces}}
198    ///
199    /// ### Explanation
200    ///
201    /// Previously, inputs for many built-in attributes weren't validated and
202    /// nonsensical attribute inputs were accepted. After validation was
203    /// added, it was determined that some existing projects made use of these
204    /// invalid forms. This is a [future-incompatible] lint to transition this
205    /// to a hard error in the future. See [issue #57571] for more details.
206    ///
207    /// Check the [attribute reference] for details on the valid inputs for
208    /// attributes.
209    ///
210    /// [issue #57571]: https://github.com/rust-lang/rust/issues/57571
211    /// [attribute reference]: https://doc.rust-lang.org/nightly/reference/attributes.html
212    /// [future-incompatible]: ../index.md#future-incompatible-lints
213    pub ILL_FORMED_ATTRIBUTE_INPUT,
214    Deny,
215    "ill-formed attribute inputs that were previously accepted and used in practice",
216    @future_incompatible = FutureIncompatibleInfo {
217        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
218        reference: "issue #57571 <https://github.com/rust-lang/rust/issues/57571>",
219    };
220    crate_level_only
221}
222
223declare_lint! {
224    /// The `conflicting_repr_hints` lint detects [`repr` attributes] with
225    /// conflicting hints.
226    ///
227    /// [`repr` attributes]: https://doc.rust-lang.org/reference/type-layout.html#representations
228    ///
229    /// ### Example
230    ///
231    /// ```rust,compile_fail
232    /// #[repr(u32, u64)]
233    /// enum Foo {
234    ///     Variant1,
235    /// }
236    /// ```
237    ///
238    /// {{produces}}
239    ///
240    /// ### Explanation
241    ///
242    /// The compiler incorrectly accepted these conflicting representations in
243    /// the past. This is a [future-incompatible] lint to transition this to a
244    /// hard error in the future. See [issue #68585] for more details.
245    ///
246    /// To correct the issue, remove one of the conflicting hints.
247    ///
248    /// [issue #68585]: https://github.com/rust-lang/rust/issues/68585
249    /// [future-incompatible]: ../index.md#future-incompatible-lints
250    pub CONFLICTING_REPR_HINTS,
251    Deny,
252    "conflicts between `#[repr(..)]` hints that were previously accepted and used in practice",
253    @future_incompatible = FutureIncompatibleInfo {
254        reason: FutureIncompatibilityReason::FutureReleaseErrorReportInDeps,
255        reference: "issue #68585 <https://github.com/rust-lang/rust/issues/68585>",
256    };
257}
258
259declare_lint! {
260    /// The `meta_variable_misuse` lint detects possible meta-variable misuse
261    /// in macro definitions.
262    ///
263    /// ### Example
264    ///
265    /// ```rust,compile_fail
266    /// #![deny(meta_variable_misuse)]
267    ///
268    /// macro_rules! foo {
269    ///     () => {};
270    ///     ($( $i:ident = $($j:ident),+ );*) => { $( $( $i = $k; )+ )* };
271    /// }
272    ///
273    /// fn main() {
274    ///     foo!();
275    /// }
276    /// ```
277    ///
278    /// {{produces}}
279    ///
280    /// ### Explanation
281    ///
282    /// There are quite a few different ways a [`macro_rules`] macro can be
283    /// improperly defined. Many of these errors were previously only detected
284    /// when the macro was expanded or not at all. This lint is an attempt to
285    /// catch some of these problems when the macro is *defined*.
286    ///
287    /// This lint is "allow" by default because it may have false positives
288    /// and other issues. See [issue #61053] for more details.
289    ///
290    /// [`macro_rules`]: https://doc.rust-lang.org/reference/macros-by-example.html
291    /// [issue #61053]: https://github.com/rust-lang/rust/issues/61053
292    pub META_VARIABLE_MISUSE,
293    Allow,
294    "possible meta-variable misuse at macro definition"
295}
296
297declare_lint! {
298    /// The `incomplete_include` lint detects the use of the [`include!`]
299    /// macro with a file that contains more than one expression.
300    ///
301    /// [`include!`]: https://doc.rust-lang.org/std/macro.include.html
302    ///
303    /// ### Example
304    ///
305    /// ```rust,ignore (needs separate file)
306    /// fn main() {
307    ///     include!("foo.txt");
308    /// }
309    /// ```
310    ///
311    /// where the file `foo.txt` contains:
312    ///
313    /// ```text
314    /// println!("hi!");
315    /// ```
316    ///
317    /// produces:
318    ///
319    /// ```text
320    /// error: include macro expected single expression in source
321    ///  --> foo.txt:1:14
322    ///   |
323    /// 1 | println!("1");
324    ///   |              ^
325    ///   |
326    ///   = note: `#[deny(incomplete_include)]` on by default
327    /// ```
328    ///
329    /// ### Explanation
330    ///
331    /// The [`include!`] macro is currently only intended to be used to
332    /// include a single [expression] or multiple [items]. Historically it
333    /// would ignore any contents after the first expression, but that can be
334    /// confusing. In the example above, the `println!` expression ends just
335    /// before the semicolon, making the semicolon "extra" information that is
336    /// ignored. Perhaps even more surprising, if the included file had
337    /// multiple print statements, the subsequent ones would be ignored!
338    ///
339    /// One workaround is to place the contents in braces to create a [block
340    /// expression]. Also consider alternatives, like using functions to
341    /// encapsulate the expressions, or use [proc-macros].
342    ///
343    /// This is a lint instead of a hard error because existing projects were
344    /// found to hit this error. To be cautious, it is a lint for now. The
345    /// future semantics of the `include!` macro are also uncertain, see
346    /// [issue #35560].
347    ///
348    /// [items]: https://doc.rust-lang.org/reference/items.html
349    /// [expression]: https://doc.rust-lang.org/reference/expressions.html
350    /// [block expression]: https://doc.rust-lang.org/reference/expressions/block-expr.html
351    /// [proc-macros]: https://doc.rust-lang.org/reference/procedural-macros.html
352    /// [issue #35560]: https://github.com/rust-lang/rust/issues/35560
353    pub INCOMPLETE_INCLUDE,
354    Deny,
355    "trailing content in included file"
356}
357
358declare_lint! {
359    /// The `arithmetic_overflow` lint detects that an arithmetic operation
360    /// will [overflow].
361    ///
362    /// [overflow]: https://doc.rust-lang.org/reference/expressions/operator-expr.html#overflow
363    ///
364    /// ### Example
365    ///
366    /// ```rust,compile_fail
367    /// 1_i32 << 32;
368    /// ```
369    ///
370    /// {{produces}}
371    ///
372    /// ### Explanation
373    ///
374    /// It is very likely a mistake to perform an arithmetic operation that
375    /// overflows its value. If the compiler is able to detect these kinds of
376    /// overflows at compile-time, it will trigger this lint. Consider
377    /// adjusting the expression to avoid overflow, or use a data type that
378    /// will not overflow.
379    pub ARITHMETIC_OVERFLOW,
380    Deny,
381    "arithmetic operation overflows",
382    @eval_always = true
383}
384
385declare_lint! {
386    /// The `unconditional_panic` lint detects an operation that will cause a
387    /// panic at runtime.
388    ///
389    /// ### Example
390    ///
391    /// ```rust,compile_fail
392    /// # #![allow(unused)]
393    /// let x = 1 / 0;
394    /// ```
395    ///
396    /// {{produces}}
397    ///
398    /// ### Explanation
399    ///
400    /// This lint detects code that is very likely incorrect because it will
401    /// always panic, such as division by zero and out-of-bounds array
402    /// accesses. Consider adjusting your code if this is a bug, or using the
403    /// `panic!` or `unreachable!` macro instead in case the panic is intended.
404    pub UNCONDITIONAL_PANIC,
405    Deny,
406    "operation will cause a panic at runtime",
407    @eval_always = true
408}
409
410declare_lint! {
411    /// The `unused_imports` lint detects imports that are never used.
412    ///
413    /// ### Example
414    ///
415    /// ```rust
416    /// use std::collections::HashMap;
417    /// ```
418    ///
419    /// {{produces}}
420    ///
421    /// ### Explanation
422    ///
423    /// Unused imports may signal a mistake or unfinished code, and clutter
424    /// the code, and should be removed. If you intended to re-export the item
425    /// to make it available outside of the module, add a visibility modifier
426    /// like `pub`.
427    pub UNUSED_IMPORTS,
428    Warn,
429    "imports that are never used"
430}
431
432declare_lint! {
433    /// The `redundant_imports` lint detects imports that are redundant due to being
434    /// imported already; either through a previous import, or being present in
435    /// the prelude.
436    ///
437    /// ### Example
438    ///
439    /// ```rust,compile_fail
440    /// #![deny(redundant_imports)]
441    /// use std::option::Option::None;
442    /// fn foo() -> Option<i32> { None }
443    /// ```
444    ///
445    /// {{produces}}
446    ///
447    /// ### Explanation
448    ///
449    /// Redundant imports are unnecessary and can be removed to simplify code.
450    /// If you intended to re-export the item to make it available outside of the
451    /// module, add a visibility modifier like `pub`.
452    pub REDUNDANT_IMPORTS,
453    Allow,
454    "imports that are redundant due to being imported already"
455}
456
457declare_lint! {
458    /// The `must_not_suspend` lint guards against values that shouldn't be held across suspend points
459    /// (`.await`)
460    ///
461    /// ### Example
462    ///
463    /// ```rust
464    /// #![feature(must_not_suspend)]
465    /// #![warn(must_not_suspend)]
466    ///
467    /// #[must_not_suspend]
468    /// struct SyncThing {}
469    ///
470    /// async fn yield_now() {}
471    ///
472    /// pub async fn uhoh() {
473    ///     let guard = SyncThing {};
474    ///     yield_now().await;
475    ///     let _guard = guard;
476    /// }
477    /// ```
478    ///
479    /// {{produces}}
480    ///
481    /// ### Explanation
482    ///
483    /// The `must_not_suspend` lint detects values that are marked with the `#[must_not_suspend]`
484    /// attribute being held across suspend points. A "suspend" point is usually a `.await` in an async
485    /// function.
486    ///
487    /// This attribute can be used to mark values that are semantically incorrect across suspends
488    /// (like certain types of timers), values that have async alternatives, and values that
489    /// regularly cause problems with the `Send`-ness of async fn's returned futures (like
490    /// `MutexGuard`'s)
491    ///
492    pub MUST_NOT_SUSPEND,
493    Allow,
494    "use of a `#[must_not_suspend]` value across a yield point",
495    @feature_gate = must_not_suspend;
496}
497
498declare_lint! {
499    /// The `unused_extern_crates` lint guards against `extern crate` items
500    /// that are never used.
501    ///
502    /// ### Example
503    ///
504    /// ```rust,compile_fail
505    /// #![deny(unused_extern_crates)]
506    /// #![deny(warnings)]
507    /// extern crate proc_macro;
508    /// ```
509    ///
510    /// {{produces}}
511    ///
512    /// ### Explanation
513    ///
514    /// `extern crate` items that are unused have no effect and should be
515    /// removed. Note that there are some cases where specifying an `extern
516    /// crate` is desired for the side effect of ensuring the given crate is
517    /// linked, even though it is not otherwise directly referenced. The lint
518    /// can be silenced by aliasing the crate to an underscore, such as
519    /// `extern crate foo as _`. Also note that it is no longer idiomatic to
520    /// use `extern crate` in the [2018 edition], as extern crates are now
521    /// automatically added in scope.
522    ///
523    /// This lint is "allow" by default because it can be noisy, and produce
524    /// false-positives. If a dependency is being removed from a project, it
525    /// is recommended to remove it from the build configuration (such as
526    /// `Cargo.toml`) to ensure stale build entries aren't left behind.
527    ///
528    /// [2018 edition]: https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html#no-more-extern-crate
529    pub UNUSED_EXTERN_CRATES,
530    Allow,
531    "extern crates that are never used"
532}
533
534declare_lint! {
535    /// The `unused_crate_dependencies` lint detects crate dependencies that
536    /// are never used.
537    ///
538    /// ### Example
539    ///
540    /// ```rust,ignore (needs extern crate)
541    /// #![deny(unused_crate_dependencies)]
542    /// ```
543    ///
544    /// This will produce:
545    ///
546    /// ```text
547    /// error: extern crate `regex` is unused in crate `lint_example`
548    ///   |
549    ///   = help: remove the dependency or add `use regex as _;` to the crate root
550    /// note: the lint level is defined here
551    ///  --> src/lib.rs:1:9
552    ///   |
553    /// 1 | #![deny(unused_crate_dependencies)]
554    ///   |         ^^^^^^^^^^^^^^^^^^^^^^^^^
555    /// ```
556    ///
557    /// ### Explanation
558    ///
559    /// After removing the code that uses a dependency, this usually also
560    /// requires removing the dependency from the build configuration.
561    /// However, sometimes that step can be missed, which leads to time wasted
562    /// building dependencies that are no longer used. This lint can be
563    /// enabled to detect dependencies that are never used (more specifically,
564    /// any dependency passed with the `--extern` command-line flag that is
565    /// never referenced via [`use`], [`extern crate`], or in any [path]).
566    ///
567    /// This lint is "allow" by default because it can provide false positives
568    /// depending on how the build system is configured. For example, when
569    /// using Cargo, a "package" consists of multiple crates (such as a
570    /// library and a binary), but the dependencies are defined for the
571    /// package as a whole. If there is a dependency that is only used in the
572    /// binary, but not the library, then the lint will be incorrectly issued
573    /// in the library.
574    ///
575    /// [path]: https://doc.rust-lang.org/reference/paths.html
576    /// [`use`]: https://doc.rust-lang.org/reference/items/use-declarations.html
577    /// [`extern crate`]: https://doc.rust-lang.org/reference/items/extern-crates.html
578    pub UNUSED_CRATE_DEPENDENCIES,
579    Allow,
580    "crate dependencies that are never used",
581    crate_level_only
582}
583
584declare_lint! {
585    /// The `unused_qualifications` lint detects unnecessarily qualified
586    /// names.
587    ///
588    /// ### Example
589    ///
590    /// ```rust,compile_fail
591    /// #![deny(unused_qualifications)]
592    /// mod foo {
593    ///     pub fn bar() {}
594    /// }
595    ///
596    /// fn main() {
597    ///     use foo::bar;
598    ///     foo::bar();
599    ///     bar();
600    /// }
601    /// ```
602    ///
603    /// {{produces}}
604    ///
605    /// ### Explanation
606    ///
607    /// If an item from another module is already brought into scope, then
608    /// there is no need to qualify it in this case. You can call `bar()`
609    /// directly, without the `foo::`.
610    ///
611    /// This lint is "allow" by default because it is somewhat pedantic, and
612    /// doesn't indicate an actual problem, but rather a stylistic choice, and
613    /// can be noisy when refactoring or moving around code.
614    pub UNUSED_QUALIFICATIONS,
615    Allow,
616    "detects unnecessarily qualified names"
617}
618
619declare_lint! {
620    /// The `unknown_lints` lint detects unrecognized lint attributes.
621    ///
622    /// ### Example
623    ///
624    /// ```rust
625    /// #![allow(not_a_real_lint)]
626    /// ```
627    ///
628    /// {{produces}}
629    ///
630    /// ### Explanation
631    ///
632    /// It is usually a mistake to specify a lint that does not exist. Check
633    /// the spelling, and check the lint listing for the correct name. Also
634    /// consider if you are using an old version of the compiler, and the lint
635    /// is only available in a newer version.
636    pub UNKNOWN_LINTS,
637    Warn,
638    "unrecognized lint attribute",
639    @eval_always = true
640}
641
642declare_lint! {
643    /// The `unfulfilled_lint_expectations` lint detects when a lint expectation is
644    /// unfulfilled.
645    ///
646    /// ### Example
647    ///
648    /// ```rust
649    /// #[expect(unused_variables)]
650    /// let x = 10;
651    /// println!("{}", x);
652    /// ```
653    ///
654    /// {{produces}}
655    ///
656    /// ### Explanation
657    ///
658    /// The `#[expect]` attribute can be used to create a lint expectation. The
659    /// expectation is fulfilled, if a `#[warn]` attribute at the same location
660    /// would result in a lint emission. If the expectation is unfulfilled,
661    /// because no lint was emitted, this lint will be emitted on the attribute.
662    ///
663    pub UNFULFILLED_LINT_EXPECTATIONS,
664    Warn,
665    "unfulfilled lint expectation"
666}
667
668declare_lint! {
669    /// The `unused_variables` lint detects variables which are not used in
670    /// any way.
671    ///
672    /// ### Example
673    ///
674    /// ```rust
675    /// let x = 5;
676    /// ```
677    ///
678    /// {{produces}}
679    ///
680    /// ### Explanation
681    ///
682    /// Unused variables may signal a mistake or unfinished code. To silence
683    /// the warning for the individual variable, prefix it with an underscore
684    /// such as `_x`.
685    pub UNUSED_VARIABLES,
686    Warn,
687    "detect variables which are not used in any way"
688}
689
690declare_lint! {
691    /// The `unused_assignments` lint detects assignments that will never be read.
692    ///
693    /// ### Example
694    ///
695    /// ```rust
696    /// let mut x = 5;
697    /// x = 6;
698    /// ```
699    ///
700    /// {{produces}}
701    ///
702    /// ### Explanation
703    ///
704    /// Unused assignments may signal a mistake or unfinished code. If the
705    /// variable is never used after being assigned, then the assignment can
706    /// be removed. Variables with an underscore prefix such as `_x` will not
707    /// trigger this lint.
708    pub UNUSED_ASSIGNMENTS,
709    Warn,
710    "detect assignments that will never be read"
711}
712
713declare_lint! {
714    /// The `dead_code` lint detects unused, unexported items.
715    ///
716    /// ### Example
717    ///
718    /// ```rust
719    /// fn foo() {}
720    /// ```
721    ///
722    /// {{produces}}
723    ///
724    /// ### Explanation
725    ///
726    /// Dead code may signal a mistake or unfinished code. To silence the
727    /// warning for individual items, prefix the name with an underscore such
728    /// as `_foo`. If it was intended to expose the item outside of the crate,
729    /// consider adding a visibility modifier like `pub`.
730    ///
731    /// To preserve the numbering of tuple structs with unused fields,
732    /// change the unused fields to have unit type or use
733    /// `PhantomData`.
734    ///
735    /// Otherwise consider removing the unused code.
736    ///
737    /// ### Limitations
738    ///
739    /// Removing fields that are only used for side-effects and never
740    /// read will result in behavioral changes. Examples of this
741    /// include:
742    ///
743    /// - If a field's value performs an action when it is dropped.
744    /// - If a field's type does not implement an auto trait
745    ///   (e.g. `Send`, `Sync`, `Unpin`).
746    ///
747    /// For side-effects from dropping field values, this lint should
748    /// be allowed on those fields. For side-effects from containing
749    /// field types, `PhantomData` should be used.
750    pub DEAD_CODE,
751    Warn,
752    "detect unused, unexported items"
753}
754
755declare_lint! {
756    /// The `unused_attributes` lint detects attributes that were not used by
757    /// the compiler.
758    ///
759    /// ### Example
760    ///
761    /// ```rust
762    /// #![ignore]
763    /// ```
764    ///
765    /// {{produces}}
766    ///
767    /// ### Explanation
768    ///
769    /// Unused [attributes] may indicate the attribute is placed in the wrong
770    /// position. Consider removing it, or placing it in the correct position.
771    /// Also consider if you intended to use an _inner attribute_ (with a `!`
772    /// such as `#![allow(unused)]`) which applies to the item the attribute
773    /// is within, or an _outer attribute_ (without a `!` such as
774    /// `#[allow(unused)]`) which applies to the item *following* the
775    /// attribute.
776    ///
777    /// [attributes]: https://doc.rust-lang.org/reference/attributes.html
778    pub UNUSED_ATTRIBUTES,
779    Warn,
780    "detects attributes that were not used by the compiler"
781}
782
783declare_lint! {
784    /// The `unreachable_code` lint detects unreachable code paths.
785    ///
786    /// ### Example
787    ///
788    /// ```rust,no_run
789    /// panic!("we never go past here!");
790    ///
791    /// let x = 5;
792    /// ```
793    ///
794    /// {{produces}}
795    ///
796    /// ### Explanation
797    ///
798    /// Unreachable code may signal a mistake or unfinished code. If the code
799    /// is no longer in use, consider removing it.
800    pub UNREACHABLE_CODE,
801    Warn,
802    "detects unreachable code paths",
803    report_in_external_macro
804}
805
806declare_lint! {
807    /// The `unreachable_patterns` lint detects unreachable patterns.
808    ///
809    /// ### Example
810    ///
811    /// ```rust
812    /// let x = 5;
813    /// match x {
814    ///     y => (),
815    ///     5 => (),
816    /// }
817    /// ```
818    ///
819    /// {{produces}}
820    ///
821    /// ### Explanation
822    ///
823    /// This usually indicates a mistake in how the patterns are specified or
824    /// ordered. In this example, the `y` pattern will always match, so the
825    /// five is impossible to reach. Remember, match arms match in order, you
826    /// probably wanted to put the `5` case above the `y` case.
827    pub UNREACHABLE_PATTERNS,
828    Warn,
829    "detects unreachable patterns"
830}
831
832declare_lint! {
833    /// The `overlapping_range_endpoints` lint detects `match` arms that have [range patterns] that
834    /// overlap on their endpoints.
835    ///
836    /// [range patterns]: https://doc.rust-lang.org/nightly/reference/patterns.html#range-patterns
837    ///
838    /// ### Example
839    ///
840    /// ```rust
841    /// let x = 123u8;
842    /// match x {
843    ///     0..=100 => { println!("small"); }
844    ///     100..=255 => { println!("large"); }
845    /// }
846    /// ```
847    ///
848    /// {{produces}}
849    ///
850    /// ### Explanation
851    ///
852    /// It is likely a mistake to have range patterns in a match expression that overlap in this
853    /// way. Check that the beginning and end values are what you expect, and keep in mind that
854    /// with `..=` the left and right bounds are inclusive.
855    pub OVERLAPPING_RANGE_ENDPOINTS,
856    Warn,
857    "detects range patterns with overlapping endpoints"
858}
859
860declare_lint! {
861    /// The `non_contiguous_range_endpoints` lint detects likely off-by-one errors when using
862    /// exclusive [range patterns].
863    ///
864    /// [range patterns]: https://doc.rust-lang.org/nightly/reference/patterns.html#range-patterns
865    ///
866    /// ### Example
867    ///
868    /// ```rust
869    /// let x = 123u32;
870    /// match x {
871    ///     0..100 => { println!("small"); }
872    ///     101..1000 => { println!("large"); }
873    ///     _ => { println!("larger"); }
874    /// }
875    /// ```
876    ///
877    /// {{produces}}
878    ///
879    /// ### Explanation
880    ///
881    /// It is likely a mistake to have range patterns in a match expression that miss out a single
882    /// number. Check that the beginning and end values are what you expect, and keep in mind that
883    /// with `..=` the right bound is inclusive, and with `..` it is exclusive.
884    pub NON_CONTIGUOUS_RANGE_ENDPOINTS,
885    Warn,
886    "detects off-by-one errors with exclusive range patterns"
887}
888
889declare_lint! {
890    /// The `bindings_with_variant_name` lint detects pattern bindings with
891    /// the same name as one of the matched variants.
892    ///
893    /// ### Example
894    ///
895    /// ```rust,compile_fail
896    /// pub enum Enum {
897    ///     Foo,
898    ///     Bar,
899    /// }
900    ///
901    /// pub fn foo(x: Enum) {
902    ///     match x {
903    ///         Foo => {}
904    ///         Bar => {}
905    ///     }
906    /// }
907    /// ```
908    ///
909    /// {{produces}}
910    ///
911    /// ### Explanation
912    ///
913    /// It is usually a mistake to specify an enum variant name as an
914    /// [identifier pattern]. In the example above, the `match` arms are
915    /// specifying a variable name to bind the value of `x` to. The second arm
916    /// is ignored because the first one matches *all* values. The likely
917    /// intent is that the arm was intended to match on the enum variant.
918    ///
919    /// Two possible solutions are:
920    ///
921    /// * Specify the enum variant using a [path pattern], such as
922    ///   `Enum::Foo`.
923    /// * Bring the enum variants into local scope, such as adding `use
924    ///   Enum::*;` to the beginning of the `foo` function in the example
925    ///   above.
926    ///
927    /// [identifier pattern]: https://doc.rust-lang.org/reference/patterns.html#identifier-patterns
928    /// [path pattern]: https://doc.rust-lang.org/reference/patterns.html#path-patterns
929    pub BINDINGS_WITH_VARIANT_NAME,
930    Deny,
931    "detects pattern bindings with the same name as one of the matched variants"
932}
933
934declare_lint! {
935    /// The `unused_macros` lint detects macros that were not used.
936    ///
937    /// Note that this lint is distinct from the `unused_macro_rules` lint,
938    /// which checks for single rules that never match of an otherwise used
939    /// macro, and thus never expand.
940    ///
941    /// ### Example
942    ///
943    /// ```rust
944    /// macro_rules! unused {
945    ///     () => {};
946    /// }
947    ///
948    /// fn main() {
949    /// }
950    /// ```
951    ///
952    /// {{produces}}
953    ///
954    /// ### Explanation
955    ///
956    /// Unused macros may signal a mistake or unfinished code. To silence the
957    /// warning for the individual macro, prefix the name with an underscore
958    /// such as `_my_macro`. If you intended to export the macro to make it
959    /// available outside of the crate, use the [`macro_export` attribute].
960    ///
961    /// [`macro_export` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
962    pub UNUSED_MACROS,
963    Warn,
964    "detects macros that were not used"
965}
966
967declare_lint! {
968    /// The `unused_macro_rules` lint detects macro rules that were not used.
969    ///
970    /// Note that the lint is distinct from the `unused_macros` lint, which
971    /// fires if the entire macro is never called, while this lint fires for
972    /// single unused rules of the macro that is otherwise used.
973    /// `unused_macro_rules` fires only if `unused_macros` wouldn't fire.
974    ///
975    /// ### Example
976    ///
977    /// ```rust
978    /// #[warn(unused_macro_rules)]
979    /// macro_rules! unused_empty {
980    ///     (hello) => { println!("Hello, world!") }; // This rule is unused
981    ///     () => { println!("empty") }; // This rule is used
982    /// }
983    ///
984    /// fn main() {
985    ///     unused_empty!(hello);
986    /// }
987    /// ```
988    ///
989    /// {{produces}}
990    ///
991    /// ### Explanation
992    ///
993    /// Unused macro rules may signal a mistake or unfinished code. Furthermore,
994    /// they slow down compilation. Right now, silencing the warning is not
995    /// supported on a single rule level, so you have to add an allow to the
996    /// entire macro definition.
997    ///
998    /// If you intended to export the macro to make it
999    /// available outside of the crate, use the [`macro_export` attribute].
1000    ///
1001    /// [`macro_export` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
1002    pub UNUSED_MACRO_RULES,
1003    Allow,
1004    "detects macro rules that were not used"
1005}
1006
1007declare_lint! {
1008    /// The `warnings` lint allows you to change the level of other
1009    /// lints which produce warnings.
1010    ///
1011    /// ### Example
1012    ///
1013    /// ```rust
1014    /// #![deny(warnings)]
1015    /// fn foo() {}
1016    /// ```
1017    ///
1018    /// {{produces}}
1019    ///
1020    /// ### Explanation
1021    ///
1022    /// The `warnings` lint is a bit special; by changing its level, you
1023    /// change every other warning that would produce a warning to whatever
1024    /// value you'd like. As such, you won't ever trigger this lint in your
1025    /// code directly.
1026    pub WARNINGS,
1027    Warn,
1028    "mass-change the level for lints which produce warnings"
1029}
1030
1031declare_lint! {
1032    /// The `unused_features` lint detects unused or unknown features found in
1033    /// crate-level [`feature` attributes].
1034    ///
1035    /// [`feature` attributes]: https://doc.rust-lang.org/nightly/unstable-book/
1036    ///
1037    /// Note: This lint is currently not functional, see [issue #44232] for
1038    /// more details.
1039    ///
1040    /// [issue #44232]: https://github.com/rust-lang/rust/issues/44232
1041    pub UNUSED_FEATURES,
1042    Warn,
1043    "unused features found in crate-level `#[feature]` directives"
1044}
1045
1046declare_lint! {
1047    /// The `stable_features` lint detects a [`feature` attribute] that
1048    /// has since been made stable.
1049    ///
1050    /// [`feature` attribute]: https://doc.rust-lang.org/nightly/unstable-book/
1051    ///
1052    /// ### Example
1053    ///
1054    /// ```rust
1055    /// #![feature(test_accepted_feature)]
1056    /// fn main() {}
1057    /// ```
1058    ///
1059    /// {{produces}}
1060    ///
1061    /// ### Explanation
1062    ///
1063    /// When a feature is stabilized, it is no longer necessary to include a
1064    /// `#![feature]` attribute for it. To fix, simply remove the
1065    /// `#![feature]` attribute.
1066    pub STABLE_FEATURES,
1067    Warn,
1068    "stable features found in `#[feature]` directive"
1069}
1070
1071declare_lint! {
1072    /// The `unknown_crate_types` lint detects an unknown crate type found in
1073    /// a [`crate_type` attribute].
1074    ///
1075    /// ### Example
1076    ///
1077    /// ```rust,compile_fail
1078    /// #![crate_type="lol"]
1079    /// fn main() {}
1080    /// ```
1081    ///
1082    /// {{produces}}
1083    ///
1084    /// ### Explanation
1085    ///
1086    /// An unknown value give to the `crate_type` attribute is almost
1087    /// certainly a mistake.
1088    ///
1089    /// [`crate_type` attribute]: https://doc.rust-lang.org/reference/linkage.html
1090    pub UNKNOWN_CRATE_TYPES,
1091    Deny,
1092    "unknown crate type found in `#[crate_type]` directive",
1093    crate_level_only
1094}
1095
1096declare_lint! {
1097    /// The `trivial_casts` lint detects trivial casts which could be replaced
1098    /// with coercion, which may require a temporary variable.
1099    ///
1100    /// ### Example
1101    ///
1102    /// ```rust,compile_fail
1103    /// #![deny(trivial_casts)]
1104    /// let x: &u32 = &42;
1105    /// let y = x as *const u32;
1106    /// ```
1107    ///
1108    /// {{produces}}
1109    ///
1110    /// ### Explanation
1111    ///
1112    /// A trivial cast is a cast `e as T` where `e` has type `U` and `U` is a
1113    /// subtype of `T`. This type of cast is usually unnecessary, as it can be
1114    /// usually be inferred.
1115    ///
1116    /// This lint is "allow" by default because there are situations, such as
1117    /// with FFI interfaces or complex type aliases, where it triggers
1118    /// incorrectly, or in situations where it will be more difficult to
1119    /// clearly express the intent. It may be possible that this will become a
1120    /// warning in the future, possibly with an explicit syntax for coercions
1121    /// providing a convenient way to work around the current issues.
1122    /// See [RFC 401 (coercions)][rfc-401], [RFC 803 (type ascription)][rfc-803] and
1123    /// [RFC 3307 (remove type ascription)][rfc-3307] for historical context.
1124    ///
1125    /// [rfc-401]: https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md
1126    /// [rfc-803]: https://github.com/rust-lang/rfcs/blob/master/text/0803-type-ascription.md
1127    /// [rfc-3307]: https://github.com/rust-lang/rfcs/blob/master/text/3307-de-rfc-type-ascription.md
1128    pub TRIVIAL_CASTS,
1129    Allow,
1130    "detects trivial casts which could be removed"
1131}
1132
1133declare_lint! {
1134    /// The `trivial_numeric_casts` lint detects trivial numeric casts of types
1135    /// which could be removed.
1136    ///
1137    /// ### Example
1138    ///
1139    /// ```rust,compile_fail
1140    /// #![deny(trivial_numeric_casts)]
1141    /// let x = 42_i32 as i32;
1142    /// ```
1143    ///
1144    /// {{produces}}
1145    ///
1146    /// ### Explanation
1147    ///
1148    /// A trivial numeric cast is a cast of a numeric type to the same numeric
1149    /// type. This type of cast is usually unnecessary.
1150    ///
1151    /// This lint is "allow" by default because there are situations, such as
1152    /// with FFI interfaces or complex type aliases, where it triggers
1153    /// incorrectly, or in situations where it will be more difficult to
1154    /// clearly express the intent. It may be possible that this will become a
1155    /// warning in the future, possibly with an explicit syntax for coercions
1156    /// providing a convenient way to work around the current issues.
1157    /// See [RFC 401 (coercions)][rfc-401], [RFC 803 (type ascription)][rfc-803] and
1158    /// [RFC 3307 (remove type ascription)][rfc-3307] for historical context.
1159    ///
1160    /// [rfc-401]: https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md
1161    /// [rfc-803]: https://github.com/rust-lang/rfcs/blob/master/text/0803-type-ascription.md
1162    /// [rfc-3307]: https://github.com/rust-lang/rfcs/blob/master/text/3307-de-rfc-type-ascription.md
1163    pub TRIVIAL_NUMERIC_CASTS,
1164    Allow,
1165    "detects trivial casts of numeric types which could be removed"
1166}
1167
1168declare_lint! {
1169    /// The `exported_private_dependencies` lint detects private dependencies
1170    /// that are exposed in a public interface.
1171    ///
1172    /// ### Example
1173    ///
1174    /// ```rust,ignore (needs-dependency)
1175    /// pub fn foo() -> Option<some_private_dependency::Thing> {
1176    ///     None
1177    /// }
1178    /// ```
1179    ///
1180    /// This will produce:
1181    ///
1182    /// ```text
1183    /// warning: type `bar::Thing` from private dependency 'bar' in public interface
1184    ///  --> src/lib.rs:3:1
1185    ///   |
1186    /// 3 | pub fn foo() -> Option<bar::Thing> {
1187    ///   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1188    ///   |
1189    ///   = note: `#[warn(exported_private_dependencies)]` on by default
1190    /// ```
1191    ///
1192    /// ### Explanation
1193    ///
1194    /// Dependencies can be marked as "private" to indicate that they are not
1195    /// exposed in the public interface of a crate. This can be used by Cargo
1196    /// to independently resolve those dependencies because it can assume it
1197    /// does not need to unify them with other packages using that same
1198    /// dependency. This lint is an indication of a violation of that
1199    /// contract.
1200    ///
1201    /// To fix this, avoid exposing the dependency in your public interface.
1202    /// Or, switch the dependency to a public dependency.
1203    ///
1204    /// Note that support for this is only available on the nightly channel.
1205    /// See [RFC 1977] for more details, as well as the [Cargo documentation].
1206    ///
1207    /// [RFC 1977]: https://github.com/rust-lang/rfcs/blob/master/text/1977-public-private-dependencies.md
1208    /// [Cargo documentation]: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#public-dependency
1209    pub EXPORTED_PRIVATE_DEPENDENCIES,
1210    Warn,
1211    "public interface leaks type from a private dependency"
1212}
1213
1214declare_lint! {
1215    /// The `pub_use_of_private_extern_crate` lint detects a specific
1216    /// situation of re-exporting a private `extern crate`.
1217    ///
1218    /// ### Example
1219    ///
1220    /// ```rust,compile_fail
1221    /// extern crate core;
1222    /// pub use core as reexported_core;
1223    /// ```
1224    ///
1225    /// {{produces}}
1226    ///
1227    /// ### Explanation
1228    ///
1229    /// A public `use` declaration should not be used to publicly re-export a
1230    /// private `extern crate`. `pub extern crate` should be used instead.
1231    ///
1232    /// This was historically allowed, but is not the intended behavior
1233    /// according to the visibility rules. This is a [future-incompatible]
1234    /// lint to transition this to a hard error in the future. See [issue
1235    /// #127909] for more details.
1236    ///
1237    /// [issue #127909]: https://github.com/rust-lang/rust/issues/127909
1238    /// [future-incompatible]: ../index.md#future-incompatible-lints
1239    pub PUB_USE_OF_PRIVATE_EXTERN_CRATE,
1240    Deny,
1241    "detect public re-exports of private extern crates",
1242    @future_incompatible = FutureIncompatibleInfo {
1243        reason: FutureIncompatibilityReason::FutureReleaseErrorReportInDeps,
1244        reference: "issue #127909 <https://github.com/rust-lang/rust/issues/127909>",
1245    };
1246}
1247
1248declare_lint! {
1249    /// The `invalid_type_param_default` lint detects type parameter defaults
1250    /// erroneously allowed in an invalid location.
1251    ///
1252    /// ### Example
1253    ///
1254    /// ```rust,compile_fail
1255    /// fn foo<T=i32>(t: T) {}
1256    /// ```
1257    ///
1258    /// {{produces}}
1259    ///
1260    /// ### Explanation
1261    ///
1262    /// Default type parameters were only intended to be allowed in certain
1263    /// situations, but historically the compiler allowed them everywhere.
1264    /// This is a [future-incompatible] lint to transition this to a hard
1265    /// error in the future. See [issue #36887] for more details.
1266    ///
1267    /// [issue #36887]: https://github.com/rust-lang/rust/issues/36887
1268    /// [future-incompatible]: ../index.md#future-incompatible-lints
1269    pub INVALID_TYPE_PARAM_DEFAULT,
1270    Deny,
1271    "type parameter default erroneously allowed in invalid location",
1272    @future_incompatible = FutureIncompatibleInfo {
1273        reason: FutureIncompatibilityReason::FutureReleaseErrorReportInDeps,
1274        reference: "issue #36887 <https://github.com/rust-lang/rust/issues/36887>",
1275    };
1276}
1277
1278declare_lint! {
1279    /// The `renamed_and_removed_lints` lint detects lints that have been
1280    /// renamed or removed.
1281    ///
1282    /// ### Example
1283    ///
1284    /// ```rust
1285    /// #![deny(raw_pointer_derive)]
1286    /// ```
1287    ///
1288    /// {{produces}}
1289    ///
1290    /// ### Explanation
1291    ///
1292    /// To fix this, either remove the lint or use the new name. This can help
1293    /// avoid confusion about lints that are no longer valid, and help
1294    /// maintain consistency for renamed lints.
1295    pub RENAMED_AND_REMOVED_LINTS,
1296    Warn,
1297    "lints that have been renamed or removed"
1298}
1299
1300declare_lint! {
1301    /// The `const_item_mutation` lint detects attempts to mutate a `const`
1302    /// item.
1303    ///
1304    /// ### Example
1305    ///
1306    /// ```rust
1307    /// const FOO: [i32; 1] = [0];
1308    ///
1309    /// fn main() {
1310    ///     FOO[0] = 1;
1311    ///     // This will print "[0]".
1312    ///     println!("{:?}", FOO);
1313    /// }
1314    /// ```
1315    ///
1316    /// {{produces}}
1317    ///
1318    /// ### Explanation
1319    ///
1320    /// Trying to directly mutate a `const` item is almost always a mistake.
1321    /// What is happening in the example above is that a temporary copy of the
1322    /// `const` is mutated, but the original `const` is not. Each time you
1323    /// refer to the `const` by name (such as `FOO` in the example above), a
1324    /// separate copy of the value is inlined at that location.
1325    ///
1326    /// This lint checks for writing directly to a field (`FOO.field =
1327    /// some_value`) or array entry (`FOO[0] = val`), or taking a mutable
1328    /// reference to the const item (`&mut FOO`), including through an
1329    /// autoderef (`FOO.some_mut_self_method()`).
1330    ///
1331    /// There are various alternatives depending on what you are trying to
1332    /// accomplish:
1333    ///
1334    /// * First, always reconsider using mutable globals, as they can be
1335    ///   difficult to use correctly, and can make the code more difficult to
1336    ///   use or understand.
1337    /// * If you are trying to perform a one-time initialization of a global:
1338    ///     * If the value can be computed at compile-time, consider using
1339    ///       const-compatible values (see [Constant Evaluation]).
1340    ///     * For more complex single-initialization cases, consider using
1341    ///       [`std::sync::LazyLock`].
1342    /// * If you truly need a mutable global, consider using a [`static`],
1343    ///   which has a variety of options:
1344    ///   * Simple data types can be directly defined and mutated with an
1345    ///     [`atomic`] type.
1346    ///   * More complex types can be placed in a synchronization primitive
1347    ///     like a [`Mutex`], which can be initialized with one of the options
1348    ///     listed above.
1349    ///   * A [mutable `static`] is a low-level primitive, requiring unsafe.
1350    ///     Typically This should be avoided in preference of something
1351    ///     higher-level like one of the above.
1352    ///
1353    /// [Constant Evaluation]: https://doc.rust-lang.org/reference/const_eval.html
1354    /// [`static`]: https://doc.rust-lang.org/reference/items/static-items.html
1355    /// [mutable `static`]: https://doc.rust-lang.org/reference/items/static-items.html#mutable-statics
1356    /// [`std::sync::LazyLock`]: https://doc.rust-lang.org/stable/std/sync/struct.LazyLock.html
1357    /// [`atomic`]: https://doc.rust-lang.org/std/sync/atomic/index.html
1358    /// [`Mutex`]: https://doc.rust-lang.org/std/sync/struct.Mutex.html
1359    pub CONST_ITEM_MUTATION,
1360    Warn,
1361    "detects attempts to mutate a `const` item",
1362}
1363
1364declare_lint! {
1365    /// The `patterns_in_fns_without_body` lint detects `mut` identifier
1366    /// patterns as a parameter in functions without a body.
1367    ///
1368    /// ### Example
1369    ///
1370    /// ```rust,compile_fail
1371    /// trait Trait {
1372    ///     fn foo(mut arg: u8);
1373    /// }
1374    /// ```
1375    ///
1376    /// {{produces}}
1377    ///
1378    /// ### Explanation
1379    ///
1380    /// To fix this, remove `mut` from the parameter in the trait definition;
1381    /// it can be used in the implementation. That is, the following is OK:
1382    ///
1383    /// ```rust
1384    /// trait Trait {
1385    ///     fn foo(arg: u8); // Removed `mut` here
1386    /// }
1387    ///
1388    /// impl Trait for i32 {
1389    ///     fn foo(mut arg: u8) { // `mut` here is OK
1390    ///
1391    ///     }
1392    /// }
1393    /// ```
1394    ///
1395    /// Trait definitions can define functions without a body to specify a
1396    /// function that implementors must define. The parameter names in the
1397    /// body-less functions are only allowed to be `_` or an [identifier] for
1398    /// documentation purposes (only the type is relevant). Previous versions
1399    /// of the compiler erroneously allowed [identifier patterns] with the
1400    /// `mut` keyword, but this was not intended to be allowed. This is a
1401    /// [future-incompatible] lint to transition this to a hard error in the
1402    /// future. See [issue #35203] for more details.
1403    ///
1404    /// [identifier]: https://doc.rust-lang.org/reference/identifiers.html
1405    /// [identifier patterns]: https://doc.rust-lang.org/reference/patterns.html#identifier-patterns
1406    /// [issue #35203]: https://github.com/rust-lang/rust/issues/35203
1407    /// [future-incompatible]: ../index.md#future-incompatible-lints
1408    pub PATTERNS_IN_FNS_WITHOUT_BODY,
1409    Deny,
1410    "patterns in functions without body were erroneously allowed",
1411    @future_incompatible = FutureIncompatibleInfo {
1412        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
1413        reference: "issue #35203 <https://github.com/rust-lang/rust/issues/35203>",
1414    };
1415}
1416
1417declare_lint! {
1418    /// The `missing_fragment_specifier` lint is issued when an unused pattern in a
1419    /// `macro_rules!` macro definition has a meta-variable (e.g. `$e`) that is not
1420    /// followed by a fragment specifier (e.g. `:expr`).
1421    ///
1422    /// This warning can always be fixed by removing the unused pattern in the
1423    /// `macro_rules!` macro definition.
1424    ///
1425    /// ### Example
1426    ///
1427    /// ```rust,compile_fail
1428    /// macro_rules! foo {
1429    ///    () => {};
1430    ///    ($name) => { };
1431    /// }
1432    ///
1433    /// fn main() {
1434    ///    foo!();
1435    /// }
1436    /// ```
1437    ///
1438    /// {{produces}}
1439    ///
1440    /// ### Explanation
1441    ///
1442    /// To fix this, remove the unused pattern from the `macro_rules!` macro definition:
1443    ///
1444    /// ```rust
1445    /// macro_rules! foo {
1446    ///     () => {};
1447    /// }
1448    /// fn main() {
1449    ///     foo!();
1450    /// }
1451    /// ```
1452    pub MISSING_FRAGMENT_SPECIFIER,
1453    Deny,
1454    "detects missing fragment specifiers in unused `macro_rules!` patterns",
1455    @future_incompatible = FutureIncompatibleInfo {
1456        reason: FutureIncompatibilityReason::FutureReleaseErrorReportInDeps,
1457        reference: "issue #40107 <https://github.com/rust-lang/rust/issues/40107>",
1458    };
1459}
1460
1461declare_lint! {
1462    /// The `late_bound_lifetime_arguments` lint detects generic lifetime
1463    /// arguments in path segments with late bound lifetime parameters.
1464    ///
1465    /// ### Example
1466    ///
1467    /// ```rust
1468    /// struct S;
1469    ///
1470    /// impl S {
1471    ///     fn late(self, _: &u8, _: &u8) {}
1472    /// }
1473    ///
1474    /// fn main() {
1475    ///     S.late::<'static>(&0, &0);
1476    /// }
1477    /// ```
1478    ///
1479    /// {{produces}}
1480    ///
1481    /// ### Explanation
1482    ///
1483    /// It is not clear how to provide arguments for early-bound lifetime
1484    /// parameters if they are intermixed with late-bound parameters in the
1485    /// same list. For now, providing any explicit arguments will trigger this
1486    /// lint if late-bound parameters are present, so in the future a solution
1487    /// can be adopted without hitting backward compatibility issues. This is
1488    /// a [future-incompatible] lint to transition this to a hard error in the
1489    /// future. See [issue #42868] for more details, along with a description
1490    /// of the difference between early and late-bound parameters.
1491    ///
1492    /// [issue #42868]: https://github.com/rust-lang/rust/issues/42868
1493    /// [future-incompatible]: ../index.md#future-incompatible-lints
1494    pub LATE_BOUND_LIFETIME_ARGUMENTS,
1495    Warn,
1496    "detects generic lifetime arguments in path segments with late bound lifetime parameters",
1497    @future_incompatible = FutureIncompatibleInfo {
1498        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
1499        reference: "issue #42868 <https://github.com/rust-lang/rust/issues/42868>",
1500    };
1501}
1502
1503declare_lint! {
1504    /// The `coherence_leak_check` lint detects conflicting implementations of
1505    /// a trait that are only distinguished by the old leak-check code.
1506    ///
1507    /// ### Example
1508    ///
1509    /// ```rust
1510    /// trait SomeTrait { }
1511    /// impl SomeTrait for for<'a> fn(&'a u8) { }
1512    /// impl<'a> SomeTrait for fn(&'a u8) { }
1513    /// ```
1514    ///
1515    /// {{produces}}
1516    ///
1517    /// ### Explanation
1518    ///
1519    /// In the past, the compiler would accept trait implementations for
1520    /// identical functions that differed only in where the lifetime binder
1521    /// appeared. Due to a change in the borrow checker implementation to fix
1522    /// several bugs, this is no longer allowed. However, since this affects
1523    /// existing code, this is a [future-incompatible] lint to transition this
1524    /// to a hard error in the future.
1525    ///
1526    /// Code relying on this pattern should introduce "[newtypes]",
1527    /// like `struct Foo(for<'a> fn(&'a u8))`.
1528    ///
1529    /// See [issue #56105] for more details.
1530    ///
1531    /// [issue #56105]: https://github.com/rust-lang/rust/issues/56105
1532    /// [newtypes]: https://doc.rust-lang.org/book/ch19-04-advanced-types.html#using-the-newtype-pattern-for-type-safety-and-abstraction
1533    /// [future-incompatible]: ../index.md#future-incompatible-lints
1534    pub COHERENCE_LEAK_CHECK,
1535    Warn,
1536    "distinct impls distinguished only by the leak-check code",
1537    @future_incompatible = FutureIncompatibleInfo {
1538        reason: FutureIncompatibilityReason::Custom("the behavior may change in a future release"),
1539        reference: "issue #56105 <https://github.com/rust-lang/rust/issues/56105>",
1540    };
1541}
1542
1543declare_lint! {
1544    /// The `deprecated` lint detects use of deprecated items.
1545    ///
1546    /// ### Example
1547    ///
1548    /// ```rust
1549    /// #[deprecated]
1550    /// fn foo() {}
1551    ///
1552    /// fn bar() {
1553    ///     foo();
1554    /// }
1555    /// ```
1556    ///
1557    /// {{produces}}
1558    ///
1559    /// ### Explanation
1560    ///
1561    /// Items may be marked "deprecated" with the [`deprecated` attribute] to
1562    /// indicate that they should no longer be used. Usually the attribute
1563    /// should include a note on what to use instead, or check the
1564    /// documentation.
1565    ///
1566    /// [`deprecated` attribute]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute
1567    pub DEPRECATED,
1568    Warn,
1569    "detects use of deprecated items",
1570    report_in_external_macro
1571}
1572
1573declare_lint! {
1574    /// The `unused_unsafe` lint detects unnecessary use of an `unsafe` block.
1575    ///
1576    /// ### Example
1577    ///
1578    /// ```rust
1579    /// unsafe {}
1580    /// ```
1581    ///
1582    /// {{produces}}
1583    ///
1584    /// ### Explanation
1585    ///
1586    /// If nothing within the block requires `unsafe`, then remove the
1587    /// `unsafe` marker because it is not required and may cause confusion.
1588    pub UNUSED_UNSAFE,
1589    Warn,
1590    "unnecessary use of an `unsafe` block"
1591}
1592
1593declare_lint! {
1594    /// The `unused_mut` lint detects mut variables which don't need to be
1595    /// mutable.
1596    ///
1597    /// ### Example
1598    ///
1599    /// ```rust
1600    /// let mut x = 5;
1601    /// ```
1602    ///
1603    /// {{produces}}
1604    ///
1605    /// ### Explanation
1606    ///
1607    /// The preferred style is to only mark variables as `mut` if it is
1608    /// required.
1609    pub UNUSED_MUT,
1610    Warn,
1611    "detect mut variables which don't need to be mutable"
1612}
1613
1614declare_lint! {
1615    /// The `rust_2024_incompatible_pat` lint
1616    /// detects patterns whose meaning will change in the Rust 2024 edition.
1617    ///
1618    /// ### Example
1619    ///
1620    /// ```rust,edition2021
1621    /// #![warn(rust_2024_incompatible_pat)]
1622    ///
1623    /// if let Some(&a) = &Some(&0u8) {
1624    ///     let _: u8 = a;
1625    /// }
1626    /// if let Some(mut _a) = &mut Some(0u8) {
1627    ///     _a = 7u8;
1628    /// }
1629    /// ```
1630    ///
1631    /// {{produces}}
1632    ///
1633    /// ### Explanation
1634    ///
1635    /// In Rust 2024 and above, the `mut` keyword does not reset the pattern binding mode,
1636    /// and nor do `&` or `&mut` patterns. The lint will suggest code that
1637    /// has the same meaning in all editions.
1638    pub RUST_2024_INCOMPATIBLE_PAT,
1639    Allow,
1640    "detects patterns whose meaning will change in Rust 2024",
1641    @future_incompatible = FutureIncompatibleInfo {
1642        reason: FutureIncompatibilityReason::EditionSemanticsChange(Edition::Edition2024),
1643        reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2024/match-ergonomics.html>",
1644    };
1645}
1646
1647declare_lint! {
1648    /// The `unconditional_recursion` lint detects functions that cannot
1649    /// return without calling themselves.
1650    ///
1651    /// ### Example
1652    ///
1653    /// ```rust
1654    /// fn foo() {
1655    ///     foo();
1656    /// }
1657    /// ```
1658    ///
1659    /// {{produces}}
1660    ///
1661    /// ### Explanation
1662    ///
1663    /// It is usually a mistake to have a recursive call that does not have
1664    /// some condition to cause it to terminate. If you really intend to have
1665    /// an infinite loop, using a `loop` expression is recommended.
1666    pub UNCONDITIONAL_RECURSION,
1667    Warn,
1668    "functions that cannot return without calling themselves"
1669}
1670
1671declare_lint! {
1672    /// The `single_use_lifetimes` lint detects lifetimes that are only used
1673    /// once.
1674    ///
1675    /// ### Example
1676    ///
1677    /// ```rust,compile_fail
1678    /// #![deny(single_use_lifetimes)]
1679    ///
1680    /// fn foo<'a>(x: &'a u32) {}
1681    /// ```
1682    ///
1683    /// {{produces}}
1684    ///
1685    /// ### Explanation
1686    ///
1687    /// Specifying an explicit lifetime like `'a` in a function or `impl`
1688    /// should only be used to link together two things. Otherwise, you should
1689    /// just use `'_` to indicate that the lifetime is not linked to anything,
1690    /// or elide the lifetime altogether if possible.
1691    ///
1692    /// This lint is "allow" by default because it was introduced at a time
1693    /// when `'_` and elided lifetimes were first being introduced, and this
1694    /// lint would be too noisy. Also, there are some known false positives
1695    /// that it produces. See [RFC 2115] for historical context, and [issue
1696    /// #44752] for more details.
1697    ///
1698    /// [RFC 2115]: https://github.com/rust-lang/rfcs/blob/master/text/2115-argument-lifetimes.md
1699    /// [issue #44752]: https://github.com/rust-lang/rust/issues/44752
1700    pub SINGLE_USE_LIFETIMES,
1701    Allow,
1702    "detects lifetime parameters that are only used once"
1703}
1704
1705declare_lint! {
1706    /// The `unused_lifetimes` lint detects lifetime parameters that are never
1707    /// used.
1708    ///
1709    /// ### Example
1710    ///
1711    /// ```rust,compile_fail
1712    /// #[deny(unused_lifetimes)]
1713    ///
1714    /// pub fn foo<'a>() {}
1715    /// ```
1716    ///
1717    /// {{produces}}
1718    ///
1719    /// ### Explanation
1720    ///
1721    /// Unused lifetime parameters may signal a mistake or unfinished code.
1722    /// Consider removing the parameter.
1723    pub UNUSED_LIFETIMES,
1724    Allow,
1725    "detects lifetime parameters that are never used"
1726}
1727
1728declare_lint! {
1729    /// The `redundant_lifetimes` lint detects lifetime parameters that are
1730    /// redundant because they are equal to another named lifetime.
1731    ///
1732    /// ### Example
1733    ///
1734    /// ```rust,compile_fail
1735    /// #[deny(redundant_lifetimes)]
1736    ///
1737    /// // `'a = 'static`, so all usages of `'a` can be replaced with `'static`
1738    /// pub fn bar<'a: 'static>() {}
1739    ///
1740    /// // `'a = 'b`, so all usages of `'b` can be replaced with `'a`
1741    /// pub fn bar<'a: 'b, 'b: 'a>() {}
1742    /// ```
1743    ///
1744    /// {{produces}}
1745    ///
1746    /// ### Explanation
1747    ///
1748    /// Unused lifetime parameters may signal a mistake or unfinished code.
1749    /// Consider removing the parameter.
1750    pub REDUNDANT_LIFETIMES,
1751    Allow,
1752    "detects lifetime parameters that are redundant because they are equal to some other named lifetime"
1753}
1754
1755declare_lint! {
1756    /// The `tyvar_behind_raw_pointer` lint detects raw pointer to an
1757    /// inference variable.
1758    ///
1759    /// ### Example
1760    ///
1761    /// ```rust,edition2015
1762    /// // edition 2015
1763    /// let data = std::ptr::null();
1764    /// let _ = &data as *const *const ();
1765    ///
1766    /// if data.is_null() {}
1767    /// ```
1768    ///
1769    /// {{produces}}
1770    ///
1771    /// ### Explanation
1772    ///
1773    /// This kind of inference was previously allowed, but with the future
1774    /// arrival of [arbitrary self types], this can introduce ambiguity. To
1775    /// resolve this, use an explicit type instead of relying on type
1776    /// inference.
1777    ///
1778    /// This is a [future-incompatible] lint to transition this to a hard
1779    /// error in the 2018 edition. See [issue #46906] for more details. This
1780    /// is currently a hard-error on the 2018 edition, and is "warn" by
1781    /// default in the 2015 edition.
1782    ///
1783    /// [arbitrary self types]: https://github.com/rust-lang/rust/issues/44874
1784    /// [issue #46906]: https://github.com/rust-lang/rust/issues/46906
1785    /// [future-incompatible]: ../index.md#future-incompatible-lints
1786    pub TYVAR_BEHIND_RAW_POINTER,
1787    Warn,
1788    "raw pointer to an inference variable",
1789    @future_incompatible = FutureIncompatibleInfo {
1790        reason: FutureIncompatibilityReason::EditionError(Edition::Edition2018),
1791        reference: "issue #46906 <https://github.com/rust-lang/rust/issues/46906>",
1792    };
1793}
1794
1795declare_lint! {
1796    /// The `elided_lifetimes_in_paths` lint detects the use of hidden
1797    /// lifetime parameters.
1798    ///
1799    /// ### Example
1800    ///
1801    /// ```rust,compile_fail
1802    /// #![deny(elided_lifetimes_in_paths)]
1803    /// #![deny(warnings)]
1804    /// struct Foo<'a> {
1805    ///     x: &'a u32
1806    /// }
1807    ///
1808    /// fn foo(x: &Foo) {
1809    /// }
1810    /// ```
1811    ///
1812    /// {{produces}}
1813    ///
1814    /// ### Explanation
1815    ///
1816    /// Elided lifetime parameters can make it difficult to see at a glance
1817    /// that borrowing is occurring. This lint ensures that lifetime
1818    /// parameters are always explicitly stated, even if it is the `'_`
1819    /// [placeholder lifetime].
1820    ///
1821    /// This lint is "allow" by default because it has some known issues, and
1822    /// may require a significant transition for old code.
1823    ///
1824    /// [placeholder lifetime]: https://doc.rust-lang.org/reference/lifetime-elision.html#lifetime-elision-in-functions
1825    pub ELIDED_LIFETIMES_IN_PATHS,
1826    Allow,
1827    "hidden lifetime parameters in types are deprecated"
1828}
1829
1830declare_lint! {
1831    /// The `elided_named_lifetimes` lint detects when an elided
1832    /// lifetime ends up being a named lifetime, such as `'static`
1833    /// or some lifetime parameter `'a`.
1834    ///
1835    /// ### Example
1836    ///
1837    /// ```rust,compile_fail
1838    /// #![deny(elided_named_lifetimes)]
1839    /// struct Foo;
1840    /// impl Foo {
1841    ///     pub fn get_mut(&'static self, x: &mut u8) -> &mut u8 {
1842    ///         unsafe { &mut *(x as *mut _) }
1843    ///     }
1844    /// }
1845    /// ```
1846    ///
1847    /// {{produces}}
1848    ///
1849    /// ### Explanation
1850    ///
1851    /// Lifetime elision is quite useful, because it frees you from having
1852    /// to give each lifetime its own name, but sometimes it can produce
1853    /// somewhat surprising resolutions. In safe code, it is mostly okay,
1854    /// because the borrow checker prevents any unsoundness, so the worst
1855    /// case scenario is you get a confusing error message in some other place.
1856    /// But with `unsafe` code, such unexpected resolutions may lead to unsound code.
1857    pub ELIDED_NAMED_LIFETIMES,
1858    Warn,
1859    "detects when an elided lifetime gets resolved to be `'static` or some named parameter"
1860}
1861
1862declare_lint! {
1863    /// The `bare_trait_objects` lint suggests using `dyn Trait` for trait
1864    /// objects.
1865    ///
1866    /// ### Example
1867    ///
1868    /// ```rust,edition2018
1869    /// trait Trait { }
1870    ///
1871    /// fn takes_trait_object(_: Box<Trait>) {
1872    /// }
1873    /// ```
1874    ///
1875    /// {{produces}}
1876    ///
1877    /// ### Explanation
1878    ///
1879    /// Without the `dyn` indicator, it can be ambiguous or confusing when
1880    /// reading code as to whether or not you are looking at a trait object.
1881    /// The `dyn` keyword makes it explicit, and adds a symmetry to contrast
1882    /// with [`impl Trait`].
1883    ///
1884    /// [`impl Trait`]: https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
1885    pub BARE_TRAIT_OBJECTS,
1886    Warn,
1887    "suggest using `dyn Trait` for trait objects",
1888    @future_incompatible = FutureIncompatibleInfo {
1889        reason: FutureIncompatibilityReason::EditionError(Edition::Edition2021),
1890        reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html>",
1891    };
1892}
1893
1894declare_lint! {
1895    /// The `absolute_paths_not_starting_with_crate` lint detects fully
1896    /// qualified paths that start with a module name instead of `crate`,
1897    /// `self`, or an extern crate name
1898    ///
1899    /// ### Example
1900    ///
1901    /// ```rust,edition2015,compile_fail
1902    /// #![deny(absolute_paths_not_starting_with_crate)]
1903    ///
1904    /// mod foo {
1905    ///     pub fn bar() {}
1906    /// }
1907    ///
1908    /// fn main() {
1909    ///     ::foo::bar();
1910    /// }
1911    /// ```
1912    ///
1913    /// {{produces}}
1914    ///
1915    /// ### Explanation
1916    ///
1917    /// Rust [editions] allow the language to evolve without breaking
1918    /// backwards compatibility. This lint catches code that uses absolute
1919    /// paths in the style of the 2015 edition. In the 2015 edition, absolute
1920    /// paths (those starting with `::`) refer to either the crate root or an
1921    /// external crate. In the 2018 edition it was changed so that they only
1922    /// refer to external crates. The path prefix `crate::` should be used
1923    /// instead to reference items from the crate root.
1924    ///
1925    /// If you switch the compiler from the 2015 to 2018 edition without
1926    /// updating the code, then it will fail to compile if the old style paths
1927    /// are used. You can manually change the paths to use the `crate::`
1928    /// prefix to transition to the 2018 edition.
1929    ///
1930    /// This lint solves the problem automatically. It is "allow" by default
1931    /// because the code is perfectly valid in the 2015 edition. The [`cargo
1932    /// fix`] tool with the `--edition` flag will switch this lint to "warn"
1933    /// and automatically apply the suggested fix from the compiler. This
1934    /// provides a completely automated way to update old code to the 2018
1935    /// edition.
1936    ///
1937    /// [editions]: https://doc.rust-lang.org/edition-guide/
1938    /// [`cargo fix`]: https://doc.rust-lang.org/cargo/commands/cargo-fix.html
1939    pub ABSOLUTE_PATHS_NOT_STARTING_WITH_CRATE,
1940    Allow,
1941    "fully qualified paths that start with a module name \
1942     instead of `crate`, `self`, or an extern crate name",
1943     @future_incompatible = FutureIncompatibleInfo {
1944        reason: FutureIncompatibilityReason::EditionError(Edition::Edition2018),
1945        reference: "issue #53130 <https://github.com/rust-lang/rust/issues/53130>",
1946     };
1947}
1948
1949declare_lint! {
1950    /// The `unstable_name_collisions` lint detects that you have used a name
1951    /// that the standard library plans to add in the future.
1952    ///
1953    /// ### Example
1954    ///
1955    /// ```rust
1956    /// trait MyIterator : Iterator {
1957    ///     // is_partitioned is an unstable method that already exists on the Iterator trait
1958    ///     fn is_partitioned<P>(self, predicate: P) -> bool
1959    ///     where
1960    ///         Self: Sized,
1961    ///         P: FnMut(Self::Item) -> bool,
1962    ///     {true}
1963    /// }
1964    ///
1965    /// impl<T: ?Sized> MyIterator for T where T: Iterator { }
1966    ///
1967    /// let x = vec![1, 2, 3];
1968    /// let _ = x.iter().is_partitioned(|_| true);
1969    /// ```
1970    ///
1971    /// {{produces}}
1972    ///
1973    /// ### Explanation
1974    ///
1975    /// When new methods are added to traits in the standard library, they are
1976    /// usually added in an "unstable" form which is only available on the
1977    /// [nightly channel] with a [`feature` attribute]. If there is any
1978    /// preexisting code which extends a trait to have a method with the same
1979    /// name, then the names will collide. In the future, when the method is
1980    /// stabilized, this will cause an error due to the ambiguity. This lint
1981    /// is an early-warning to let you know that there may be a collision in
1982    /// the future. This can be avoided by adding type annotations to
1983    /// disambiguate which trait method you intend to call, such as
1984    /// `MyIterator::is_partitioned(my_iter, my_predicate)` or renaming or removing the method.
1985    ///
1986    /// [nightly channel]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
1987    /// [`feature` attribute]: https://doc.rust-lang.org/nightly/unstable-book/
1988    pub UNSTABLE_NAME_COLLISIONS,
1989    Warn,
1990    "detects name collision with an existing but unstable method",
1991    @future_incompatible = FutureIncompatibleInfo {
1992        reason: FutureIncompatibilityReason::Custom(
1993            "once this associated item is added to the standard library, \
1994             the ambiguity may cause an error or change in behavior!"
1995        ),
1996        reference: "issue #48919 <https://github.com/rust-lang/rust/issues/48919>",
1997        // Note: this item represents future incompatibility of all unstable functions in the
1998        //       standard library, and thus should never be removed or changed to an error.
1999    };
2000}
2001
2002declare_lint! {
2003    /// The `irrefutable_let_patterns` lint detects [irrefutable patterns]
2004    /// in [`if let`]s, [`while let`]s, and `if let` guards.
2005    ///
2006    /// ### Example
2007    ///
2008    /// ```rust
2009    /// if let _ = 123 {
2010    ///     println!("always runs!");
2011    /// }
2012    /// ```
2013    ///
2014    /// {{produces}}
2015    ///
2016    /// ### Explanation
2017    ///
2018    /// There usually isn't a reason to have an irrefutable pattern in an
2019    /// `if let` or `while let` statement, because the pattern will always match
2020    /// successfully. A [`let`] or [`loop`] statement will suffice. However,
2021    /// when generating code with a macro, forbidding irrefutable patterns
2022    /// would require awkward workarounds in situations where the macro
2023    /// doesn't know if the pattern is refutable or not. This lint allows
2024    /// macros to accept this form, while alerting for a possibly incorrect
2025    /// use in normal code.
2026    ///
2027    /// See [RFC 2086] for more details.
2028    ///
2029    /// [irrefutable patterns]: https://doc.rust-lang.org/reference/patterns.html#refutability
2030    /// [`if let`]: https://doc.rust-lang.org/reference/expressions/if-expr.html#if-let-expressions
2031    /// [`while let`]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#predicate-pattern-loops
2032    /// [`let`]: https://doc.rust-lang.org/reference/statements.html#let-statements
2033    /// [`loop`]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#infinite-loops
2034    /// [RFC 2086]: https://github.com/rust-lang/rfcs/blob/master/text/2086-allow-if-let-irrefutables.md
2035    pub IRREFUTABLE_LET_PATTERNS,
2036    Warn,
2037    "detects irrefutable patterns in `if let` and `while let` statements"
2038}
2039
2040declare_lint! {
2041    /// The `unused_labels` lint detects [labels] that are never used.
2042    ///
2043    /// [labels]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#loop-labels
2044    ///
2045    /// ### Example
2046    ///
2047    /// ```rust,no_run
2048    /// 'unused_label: loop {}
2049    /// ```
2050    ///
2051    /// {{produces}}
2052    ///
2053    /// ### Explanation
2054    ///
2055    /// Unused labels may signal a mistake or unfinished code. To silence the
2056    /// warning for the individual label, prefix it with an underscore such as
2057    /// `'_my_label:`.
2058    pub UNUSED_LABELS,
2059    Warn,
2060    "detects labels that are never used"
2061}
2062
2063declare_lint! {
2064    /// The `proc_macro_derive_resolution_fallback` lint detects proc macro
2065    /// derives using inaccessible names from parent modules.
2066    ///
2067    /// ### Example
2068    ///
2069    /// ```rust,ignore (proc-macro)
2070    /// // foo.rs
2071    /// #![crate_type = "proc-macro"]
2072    ///
2073    /// extern crate proc_macro;
2074    ///
2075    /// use proc_macro::*;
2076    ///
2077    /// #[proc_macro_derive(Foo)]
2078    /// pub fn foo1(a: TokenStream) -> TokenStream {
2079    ///     drop(a);
2080    ///     "mod __bar { static mut BAR: Option<Something> = None; }".parse().unwrap()
2081    /// }
2082    /// ```
2083    ///
2084    /// ```rust,ignore (needs-dependency)
2085    /// // bar.rs
2086    /// #[macro_use]
2087    /// extern crate foo;
2088    ///
2089    /// struct Something;
2090    ///
2091    /// #[derive(Foo)]
2092    /// struct Another;
2093    ///
2094    /// fn main() {}
2095    /// ```
2096    ///
2097    /// This will produce:
2098    ///
2099    /// ```text
2100    /// warning: cannot find type `Something` in this scope
2101    ///  --> src/main.rs:8:10
2102    ///   |
2103    /// 8 | #[derive(Foo)]
2104    ///   |          ^^^ names from parent modules are not accessible without an explicit import
2105    ///   |
2106    ///   = note: `#[warn(proc_macro_derive_resolution_fallback)]` on by default
2107    ///   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
2108    ///   = note: for more information, see issue #50504 <https://github.com/rust-lang/rust/issues/50504>
2109    /// ```
2110    ///
2111    /// ### Explanation
2112    ///
2113    /// If a proc-macro generates a module, the compiler unintentionally
2114    /// allowed items in that module to refer to items in the crate root
2115    /// without importing them. This is a [future-incompatible] lint to
2116    /// transition this to a hard error in the future. See [issue #50504] for
2117    /// more details.
2118    ///
2119    /// [issue #50504]: https://github.com/rust-lang/rust/issues/50504
2120    /// [future-incompatible]: ../index.md#future-incompatible-lints
2121    pub PROC_MACRO_DERIVE_RESOLUTION_FALLBACK,
2122    Deny,
2123    "detects proc macro derives using inaccessible names from parent modules",
2124    @future_incompatible = FutureIncompatibleInfo {
2125        reason: FutureIncompatibilityReason::FutureReleaseErrorReportInDeps,
2126        reference: "issue #83583 <https://github.com/rust-lang/rust/issues/83583>",
2127    };
2128}
2129
2130declare_lint! {
2131    /// The `macro_use_extern_crate` lint detects the use of the [`macro_use` attribute].
2132    ///
2133    /// ### Example
2134    ///
2135    /// ```rust,ignore (needs extern crate)
2136    /// #![deny(macro_use_extern_crate)]
2137    ///
2138    /// #[macro_use]
2139    /// extern crate serde_json;
2140    ///
2141    /// fn main() {
2142    ///     let _ = json!{{}};
2143    /// }
2144    /// ```
2145    ///
2146    /// This will produce:
2147    ///
2148    /// ```text
2149    /// error: applying the `#[macro_use]` attribute to an `extern crate` item is deprecated
2150    ///  --> src/main.rs:3:1
2151    ///   |
2152    /// 3 | #[macro_use]
2153    ///   | ^^^^^^^^^^^^
2154    ///   |
2155    ///   = help: remove it and import macros at use sites with a `use` item instead
2156    /// note: the lint level is defined here
2157    ///  --> src/main.rs:1:9
2158    ///   |
2159    /// 1 | #![deny(macro_use_extern_crate)]
2160    ///   |         ^^^^^^^^^^^^^^^^^^^^^^
2161    /// ```
2162    ///
2163    /// ### Explanation
2164    ///
2165    /// The [`macro_use` attribute] on an [`extern crate`] item causes
2166    /// macros in that external crate to be brought into the prelude of the
2167    /// crate, making the macros in scope everywhere. As part of the efforts
2168    /// to simplify handling of dependencies in the [2018 edition], the use of
2169    /// `extern crate` is being phased out. To bring macros from extern crates
2170    /// into scope, it is recommended to use a [`use` import].
2171    ///
2172    /// This lint is "allow" by default because this is a stylistic choice
2173    /// that has not been settled, see [issue #52043] for more information.
2174    ///
2175    /// [`macro_use` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#the-macro_use-attribute
2176    /// [`use` import]: https://doc.rust-lang.org/reference/items/use-declarations.html
2177    /// [issue #52043]: https://github.com/rust-lang/rust/issues/52043
2178    pub MACRO_USE_EXTERN_CRATE,
2179    Allow,
2180    "the `#[macro_use]` attribute is now deprecated in favor of using macros \
2181     via the module system"
2182}
2183
2184declare_lint! {
2185    /// The `macro_expanded_macro_exports_accessed_by_absolute_paths` lint
2186    /// detects macro-expanded [`macro_export`] macros from the current crate
2187    /// that cannot be referred to by absolute paths.
2188    ///
2189    /// [`macro_export`]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
2190    ///
2191    /// ### Example
2192    ///
2193    /// ```rust,compile_fail
2194    /// macro_rules! define_exported {
2195    ///     () => {
2196    ///         #[macro_export]
2197    ///         macro_rules! exported {
2198    ///             () => {};
2199    ///         }
2200    ///     };
2201    /// }
2202    ///
2203    /// define_exported!();
2204    ///
2205    /// fn main() {
2206    ///     crate::exported!();
2207    /// }
2208    /// ```
2209    ///
2210    /// {{produces}}
2211    ///
2212    /// ### Explanation
2213    ///
2214    /// The intent is that all macros marked with the `#[macro_export]`
2215    /// attribute are made available in the root of the crate. However, when a
2216    /// `macro_rules!` definition is generated by another macro, the macro
2217    /// expansion is unable to uphold this rule. This is a
2218    /// [future-incompatible] lint to transition this to a hard error in the
2219    /// future. See [issue #53495] for more details.
2220    ///
2221    /// [issue #53495]: https://github.com/rust-lang/rust/issues/53495
2222    /// [future-incompatible]: ../index.md#future-incompatible-lints
2223    pub MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS,
2224    Deny,
2225    "macro-expanded `macro_export` macros from the current crate \
2226     cannot be referred to by absolute paths",
2227    @future_incompatible = FutureIncompatibleInfo {
2228        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
2229        reference: "issue #52234 <https://github.com/rust-lang/rust/issues/52234>",
2230    };
2231    crate_level_only
2232}
2233
2234declare_lint! {
2235    /// The `explicit_outlives_requirements` lint detects unnecessary
2236    /// lifetime bounds that can be inferred.
2237    ///
2238    /// ### Example
2239    ///
2240    /// ```rust,compile_fail
2241    /// # #![allow(unused)]
2242    /// #![deny(explicit_outlives_requirements)]
2243    /// #![deny(warnings)]
2244    ///
2245    /// struct SharedRef<'a, T>
2246    /// where
2247    ///     T: 'a,
2248    /// {
2249    ///     data: &'a T,
2250    /// }
2251    /// ```
2252    ///
2253    /// {{produces}}
2254    ///
2255    /// ### Explanation
2256    ///
2257    /// If a `struct` contains a reference, such as `&'a T`, the compiler
2258    /// requires that `T` outlives the lifetime `'a`. This historically
2259    /// required writing an explicit lifetime bound to indicate this
2260    /// requirement. However, this can be overly explicit, causing clutter and
2261    /// unnecessary complexity. The language was changed to automatically
2262    /// infer the bound if it is not specified. Specifically, if the struct
2263    /// contains a reference, directly or indirectly, to `T` with lifetime
2264    /// `'x`, then it will infer that `T: 'x` is a requirement.
2265    ///
2266    /// This lint is "allow" by default because it can be noisy for existing
2267    /// code that already had these requirements. This is a stylistic choice,
2268    /// as it is still valid to explicitly state the bound. It also has some
2269    /// false positives that can cause confusion.
2270    ///
2271    /// See [RFC 2093] for more details.
2272    ///
2273    /// [RFC 2093]: https://github.com/rust-lang/rfcs/blob/master/text/2093-infer-outlives.md
2274    pub EXPLICIT_OUTLIVES_REQUIREMENTS,
2275    Allow,
2276    "outlives requirements can be inferred"
2277}
2278
2279declare_lint! {
2280    /// The `deprecated_in_future` lint is internal to rustc and should not be
2281    /// used by user code.
2282    ///
2283    /// This lint is only enabled in the standard library. It works with the
2284    /// use of `#[deprecated]` with a `since` field of a version in the future.
2285    /// This allows something to be marked as deprecated in a future version,
2286    /// and then this lint will ensure that the item is no longer used in the
2287    /// standard library. See the [stability documentation] for more details.
2288    ///
2289    /// [stability documentation]: https://rustc-dev-guide.rust-lang.org/stability.html#deprecated
2290    pub DEPRECATED_IN_FUTURE,
2291    Allow,
2292    "detects use of items that will be deprecated in a future version",
2293    report_in_external_macro
2294}
2295
2296declare_lint! {
2297    /// The `ambiguous_associated_items` lint detects ambiguity between
2298    /// [associated items] and [enum variants].
2299    ///
2300    /// [associated items]: https://doc.rust-lang.org/reference/items/associated-items.html
2301    /// [enum variants]: https://doc.rust-lang.org/reference/items/enumerations.html
2302    ///
2303    /// ### Example
2304    ///
2305    /// ```rust,compile_fail
2306    /// enum E {
2307    ///     V
2308    /// }
2309    ///
2310    /// trait Tr {
2311    ///     type V;
2312    ///     fn foo() -> Self::V;
2313    /// }
2314    ///
2315    /// impl Tr for E {
2316    ///     type V = u8;
2317    ///     // `Self::V` is ambiguous because it may refer to the associated type or
2318    ///     // the enum variant.
2319    ///     fn foo() -> Self::V { 0 }
2320    /// }
2321    /// ```
2322    ///
2323    /// {{produces}}
2324    ///
2325    /// ### Explanation
2326    ///
2327    /// Previous versions of Rust did not allow accessing enum variants
2328    /// through [type aliases]. When this ability was added (see [RFC 2338]), this
2329    /// introduced some situations where it can be ambiguous what a type
2330    /// was referring to.
2331    ///
2332    /// To fix this ambiguity, you should use a [qualified path] to explicitly
2333    /// state which type to use. For example, in the above example the
2334    /// function can be written as `fn f() -> <Self as Tr>::V { 0 }` to
2335    /// specifically refer to the associated type.
2336    ///
2337    /// This is a [future-incompatible] lint to transition this to a hard
2338    /// error in the future. See [issue #57644] for more details.
2339    ///
2340    /// [issue #57644]: https://github.com/rust-lang/rust/issues/57644
2341    /// [type aliases]: https://doc.rust-lang.org/reference/items/type-aliases.html#type-aliases
2342    /// [RFC 2338]: https://github.com/rust-lang/rfcs/blob/master/text/2338-type-alias-enum-variants.md
2343    /// [qualified path]: https://doc.rust-lang.org/reference/paths.html#qualified-paths
2344    /// [future-incompatible]: ../index.md#future-incompatible-lints
2345    pub AMBIGUOUS_ASSOCIATED_ITEMS,
2346    Deny,
2347    "ambiguous associated items",
2348    @future_incompatible = FutureIncompatibleInfo {
2349        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
2350        reference: "issue #57644 <https://github.com/rust-lang/rust/issues/57644>",
2351    };
2352}
2353
2354declare_lint! {
2355    /// The `soft_unstable` lint detects unstable features that were
2356    /// unintentionally allowed on stable.
2357    ///
2358    /// ### Example
2359    ///
2360    /// ```rust,compile_fail
2361    /// #[cfg(test)]
2362    /// extern crate test;
2363    ///
2364    /// #[bench]
2365    /// fn name(b: &mut test::Bencher) {
2366    ///     b.iter(|| 123)
2367    /// }
2368    /// ```
2369    ///
2370    /// {{produces}}
2371    ///
2372    /// ### Explanation
2373    ///
2374    /// The [`bench` attribute] was accidentally allowed to be specified on
2375    /// the [stable release channel]. Turning this to a hard error would have
2376    /// broken some projects. This lint allows those projects to continue to
2377    /// build correctly when [`--cap-lints`] is used, but otherwise signal an
2378    /// error that `#[bench]` should not be used on the stable channel. This
2379    /// is a [future-incompatible] lint to transition this to a hard error in
2380    /// the future. See [issue #64266] for more details.
2381    ///
2382    /// [issue #64266]: https://github.com/rust-lang/rust/issues/64266
2383    /// [`bench` attribute]: https://doc.rust-lang.org/nightly/unstable-book/library-features/test.html
2384    /// [stable release channel]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
2385    /// [`--cap-lints`]: https://doc.rust-lang.org/rustc/lints/levels.html#capping-lints
2386    /// [future-incompatible]: ../index.md#future-incompatible-lints
2387    pub SOFT_UNSTABLE,
2388    Deny,
2389    "a feature gate that doesn't break dependent crates",
2390    @future_incompatible = FutureIncompatibleInfo {
2391        reason: FutureIncompatibilityReason::FutureReleaseErrorReportInDeps,
2392        reference: "issue #64266 <https://github.com/rust-lang/rust/issues/64266>",
2393    };
2394}
2395
2396declare_lint! {
2397    /// The `inline_no_sanitize` lint detects incompatible use of
2398    /// [`#[inline(always)]`][inline] and [`#[no_sanitize(...)]`][no_sanitize].
2399    ///
2400    /// [inline]: https://doc.rust-lang.org/reference/attributes/codegen.html#the-inline-attribute
2401    /// [no_sanitize]: https://doc.rust-lang.org/nightly/unstable-book/language-features/no-sanitize.html
2402    ///
2403    /// ### Example
2404    ///
2405    /// ```rust
2406    /// #![feature(no_sanitize)]
2407    ///
2408    /// #[inline(always)]
2409    /// #[no_sanitize(address)]
2410    /// fn x() {}
2411    ///
2412    /// fn main() {
2413    ///     x()
2414    /// }
2415    /// ```
2416    ///
2417    /// {{produces}}
2418    ///
2419    /// ### Explanation
2420    ///
2421    /// The use of the [`#[inline(always)]`][inline] attribute prevents the
2422    /// the [`#[no_sanitize(...)]`][no_sanitize] attribute from working.
2423    /// Consider temporarily removing `inline` attribute.
2424    pub INLINE_NO_SANITIZE,
2425    Warn,
2426    "detects incompatible use of `#[inline(always)]` and `#[no_sanitize(...)]`",
2427}
2428
2429declare_lint! {
2430    /// The `asm_sub_register` lint detects using only a subset of a register
2431    /// for inline asm inputs.
2432    ///
2433    /// ### Example
2434    ///
2435    /// ```rust,ignore (fails on non-x86_64)
2436    /// #[cfg(target_arch="x86_64")]
2437    /// use std::arch::asm;
2438    ///
2439    /// fn main() {
2440    ///     #[cfg(target_arch="x86_64")]
2441    ///     unsafe {
2442    ///         asm!("mov {0}, {0}", in(reg) 0i16);
2443    ///     }
2444    /// }
2445    /// ```
2446    ///
2447    /// This will produce:
2448    ///
2449    /// ```text
2450    /// warning: formatting may not be suitable for sub-register argument
2451    ///  --> src/main.rs:7:19
2452    ///   |
2453    /// 7 |         asm!("mov {0}, {0}", in(reg) 0i16);
2454    ///   |                   ^^^  ^^^           ---- for this argument
2455    ///   |
2456    ///   = note: `#[warn(asm_sub_register)]` on by default
2457    ///   = help: use the `x` modifier to have the register formatted as `ax`
2458    ///   = help: or use the `r` modifier to keep the default formatting of `rax`
2459    /// ```
2460    ///
2461    /// ### Explanation
2462    ///
2463    /// Registers on some architectures can use different names to refer to a
2464    /// subset of the register. By default, the compiler will use the name for
2465    /// the full register size. To explicitly use a subset of the register,
2466    /// you can override the default by using a modifier on the template
2467    /// string operand to specify when subregister to use. This lint is issued
2468    /// if you pass in a value with a smaller data type than the default
2469    /// register size, to alert you of possibly using the incorrect width. To
2470    /// fix this, add the suggested modifier to the template, or cast the
2471    /// value to the correct size.
2472    ///
2473    /// See [register template modifiers] in the reference for more details.
2474    ///
2475    /// [register template modifiers]: https://doc.rust-lang.org/nightly/reference/inline-assembly.html#template-modifiers
2476    pub ASM_SUB_REGISTER,
2477    Warn,
2478    "using only a subset of a register for inline asm inputs",
2479}
2480
2481declare_lint! {
2482    /// The `bad_asm_style` lint detects the use of the `.intel_syntax` and
2483    /// `.att_syntax` directives.
2484    ///
2485    /// ### Example
2486    ///
2487    /// ```rust,ignore (fails on non-x86_64)
2488    /// #[cfg(target_arch="x86_64")]
2489    /// use std::arch::asm;
2490    ///
2491    /// fn main() {
2492    ///     #[cfg(target_arch="x86_64")]
2493    ///     unsafe {
2494    ///         asm!(
2495    ///             ".att_syntax",
2496    ///             "movq %{0}, %{0}", in(reg) 0usize
2497    ///         );
2498    ///     }
2499    /// }
2500    /// ```
2501    ///
2502    /// This will produce:
2503    ///
2504    /// ```text
2505    /// warning: avoid using `.att_syntax`, prefer using `options(att_syntax)` instead
2506    ///  --> src/main.rs:8:14
2507    ///   |
2508    /// 8 |             ".att_syntax",
2509    ///   |              ^^^^^^^^^^^
2510    ///   |
2511    ///   = note: `#[warn(bad_asm_style)]` on by default
2512    /// ```
2513    ///
2514    /// ### Explanation
2515    ///
2516    /// On x86, `asm!` uses the intel assembly syntax by default. While this
2517    /// can be switched using assembler directives like `.att_syntax`, using the
2518    /// `att_syntax` option is recommended instead because it will also properly
2519    /// prefix register placeholders with `%` as required by AT&T syntax.
2520    pub BAD_ASM_STYLE,
2521    Warn,
2522    "incorrect use of inline assembly",
2523}
2524
2525declare_lint! {
2526    /// The `unsafe_op_in_unsafe_fn` lint detects unsafe operations in unsafe
2527    /// functions without an explicit unsafe block.
2528    ///
2529    /// ### Example
2530    ///
2531    /// ```rust,compile_fail
2532    /// #![deny(unsafe_op_in_unsafe_fn)]
2533    ///
2534    /// unsafe fn foo() {}
2535    ///
2536    /// unsafe fn bar() {
2537    ///     foo();
2538    /// }
2539    ///
2540    /// fn main() {}
2541    /// ```
2542    ///
2543    /// {{produces}}
2544    ///
2545    /// ### Explanation
2546    ///
2547    /// Currently, an [`unsafe fn`] allows any [unsafe] operation within its
2548    /// body. However, this can increase the surface area of code that needs
2549    /// to be scrutinized for proper behavior. The [`unsafe` block] provides a
2550    /// convenient way to make it clear exactly which parts of the code are
2551    /// performing unsafe operations. In the future, it is desired to change
2552    /// it so that unsafe operations cannot be performed in an `unsafe fn`
2553    /// without an `unsafe` block.
2554    ///
2555    /// The fix to this is to wrap the unsafe code in an `unsafe` block.
2556    ///
2557    /// This lint is "allow" by default on editions up to 2021, from 2024 it is
2558    /// "warn" by default; the plan for increasing severity further is
2559    /// still being considered. See [RFC #2585] and [issue #71668] for more
2560    /// details.
2561    ///
2562    /// [`unsafe fn`]: https://doc.rust-lang.org/reference/unsafe-functions.html
2563    /// [`unsafe` block]: https://doc.rust-lang.org/reference/expressions/block-expr.html#unsafe-blocks
2564    /// [unsafe]: https://doc.rust-lang.org/reference/unsafety.html
2565    /// [RFC #2585]: https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md
2566    /// [issue #71668]: https://github.com/rust-lang/rust/issues/71668
2567    pub UNSAFE_OP_IN_UNSAFE_FN,
2568    Allow,
2569    "unsafe operations in unsafe functions without an explicit unsafe block are deprecated",
2570    @future_incompatible = FutureIncompatibleInfo {
2571        reason: FutureIncompatibilityReason::EditionSemanticsChange(Edition::Edition2024),
2572        reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2024/unsafe-op-in-unsafe-fn.html>",
2573        explain_reason: false
2574    };
2575    @edition Edition2024 => Warn;
2576}
2577
2578declare_lint! {
2579    /// The `fuzzy_provenance_casts` lint detects an `as` cast between an integer
2580    /// and a pointer.
2581    ///
2582    /// ### Example
2583    ///
2584    /// ```rust
2585    /// #![feature(strict_provenance_lints)]
2586    /// #![warn(fuzzy_provenance_casts)]
2587    ///
2588    /// fn main() {
2589    ///     let _dangling = 16_usize as *const u8;
2590    /// }
2591    /// ```
2592    ///
2593    /// {{produces}}
2594    ///
2595    /// ### Explanation
2596    ///
2597    /// This lint is part of the strict provenance effort, see [issue #95228].
2598    /// Casting an integer to a pointer is considered bad style, as a pointer
2599    /// contains, besides the *address* also a *provenance*, indicating what
2600    /// memory the pointer is allowed to read/write. Casting an integer, which
2601    /// doesn't have provenance, to a pointer requires the compiler to assign
2602    /// (guess) provenance. The compiler assigns "all exposed valid" (see the
2603    /// docs of [`ptr::with_exposed_provenance`] for more information about this
2604    /// "exposing"). This penalizes the optimiser and is not well suited for
2605    /// dynamic analysis/dynamic program verification (e.g. Miri or CHERI
2606    /// platforms).
2607    ///
2608    /// It is much better to use [`ptr::with_addr`] instead to specify the
2609    /// provenance you want. If using this function is not possible because the
2610    /// code relies on exposed provenance then there is as an escape hatch
2611    /// [`ptr::with_exposed_provenance`].
2612    ///
2613    /// [issue #95228]: https://github.com/rust-lang/rust/issues/95228
2614    /// [`ptr::with_addr`]: https://doc.rust-lang.org/core/primitive.pointer.html#method.with_addr
2615    /// [`ptr::with_exposed_provenance`]: https://doc.rust-lang.org/core/ptr/fn.with_exposed_provenance.html
2616    pub FUZZY_PROVENANCE_CASTS,
2617    Allow,
2618    "a fuzzy integer to pointer cast is used",
2619    @feature_gate = strict_provenance_lints;
2620}
2621
2622declare_lint! {
2623    /// The `lossy_provenance_casts` lint detects an `as` cast between a pointer
2624    /// and an integer.
2625    ///
2626    /// ### Example
2627    ///
2628    /// ```rust
2629    /// #![feature(strict_provenance_lints)]
2630    /// #![warn(lossy_provenance_casts)]
2631    ///
2632    /// fn main() {
2633    ///     let x: u8 = 37;
2634    ///     let _addr: usize = &x as *const u8 as usize;
2635    /// }
2636    /// ```
2637    ///
2638    /// {{produces}}
2639    ///
2640    /// ### Explanation
2641    ///
2642    /// This lint is part of the strict provenance effort, see [issue #95228].
2643    /// Casting a pointer to an integer is a lossy operation, because beyond
2644    /// just an *address* a pointer may be associated with a particular
2645    /// *provenance*. This information is used by the optimiser and for dynamic
2646    /// analysis/dynamic program verification (e.g. Miri or CHERI platforms).
2647    ///
2648    /// Since this cast is lossy, it is considered good style to use the
2649    /// [`ptr::addr`] method instead, which has a similar effect, but doesn't
2650    /// "expose" the pointer provenance. This improves optimisation potential.
2651    /// See the docs of [`ptr::addr`] and [`ptr::expose_provenance`] for more information
2652    /// about exposing pointer provenance.
2653    ///
2654    /// If your code can't comply with strict provenance and needs to expose
2655    /// the provenance, then there is [`ptr::expose_provenance`] as an escape hatch,
2656    /// which preserves the behaviour of `as usize` casts while being explicit
2657    /// about the semantics.
2658    ///
2659    /// [issue #95228]: https://github.com/rust-lang/rust/issues/95228
2660    /// [`ptr::addr`]: https://doc.rust-lang.org/core/primitive.pointer.html#method.addr
2661    /// [`ptr::expose_provenance`]: https://doc.rust-lang.org/core/primitive.pointer.html#method.expose_provenance
2662    pub LOSSY_PROVENANCE_CASTS,
2663    Allow,
2664    "a lossy pointer to integer cast is used",
2665    @feature_gate = strict_provenance_lints;
2666}
2667
2668declare_lint! {
2669    /// The `const_evaluatable_unchecked` lint detects a generic constant used
2670    /// in a type.
2671    ///
2672    /// ### Example
2673    ///
2674    /// ```rust
2675    /// const fn foo<T>() -> usize {
2676    ///     if size_of::<*mut T>() < 8 { // size of *mut T does not depend on T
2677    ///         4
2678    ///     } else {
2679    ///         8
2680    ///     }
2681    /// }
2682    ///
2683    /// fn test<T>() {
2684    ///     let _ = [0; foo::<T>()];
2685    /// }
2686    /// ```
2687    ///
2688    /// {{produces}}
2689    ///
2690    /// ### Explanation
2691    ///
2692    /// In the 1.43 release, some uses of generic parameters in array repeat
2693    /// expressions were accidentally allowed. This is a [future-incompatible]
2694    /// lint to transition this to a hard error in the future. See [issue
2695    /// #76200] for a more detailed description and possible fixes.
2696    ///
2697    /// [future-incompatible]: ../index.md#future-incompatible-lints
2698    /// [issue #76200]: https://github.com/rust-lang/rust/issues/76200
2699    pub CONST_EVALUATABLE_UNCHECKED,
2700    Warn,
2701    "detects a generic constant is used in a type without a emitting a warning",
2702    @future_incompatible = FutureIncompatibleInfo {
2703        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
2704        reference: "issue #76200 <https://github.com/rust-lang/rust/issues/76200>",
2705    };
2706}
2707
2708declare_lint! {
2709    /// The `function_item_references` lint detects function references that are
2710    /// formatted with [`fmt::Pointer`] or transmuted.
2711    ///
2712    /// [`fmt::Pointer`]: https://doc.rust-lang.org/std/fmt/trait.Pointer.html
2713    ///
2714    /// ### Example
2715    ///
2716    /// ```rust
2717    /// fn foo() { }
2718    ///
2719    /// fn main() {
2720    ///     println!("{:p}", &foo);
2721    /// }
2722    /// ```
2723    ///
2724    /// {{produces}}
2725    ///
2726    /// ### Explanation
2727    ///
2728    /// Taking a reference to a function may be mistaken as a way to obtain a
2729    /// pointer to that function. This can give unexpected results when
2730    /// formatting the reference as a pointer or transmuting it. This lint is
2731    /// issued when function references are formatted as pointers, passed as
2732    /// arguments bound by [`fmt::Pointer`] or transmuted.
2733    pub FUNCTION_ITEM_REFERENCES,
2734    Warn,
2735    "suggest casting to a function pointer when attempting to take references to function items",
2736}
2737
2738declare_lint! {
2739    /// The `uninhabited_static` lint detects uninhabited statics.
2740    ///
2741    /// ### Example
2742    ///
2743    /// ```rust
2744    /// enum Void {}
2745    /// unsafe extern {
2746    ///     static EXTERN: Void;
2747    /// }
2748    /// ```
2749    ///
2750    /// {{produces}}
2751    ///
2752    /// ### Explanation
2753    ///
2754    /// Statics with an uninhabited type can never be initialized, so they are impossible to define.
2755    /// However, this can be side-stepped with an `extern static`, leading to problems later in the
2756    /// compiler which assumes that there are no initialized uninhabited places (such as locals or
2757    /// statics). This was accidentally allowed, but is being phased out.
2758    pub UNINHABITED_STATIC,
2759    Warn,
2760    "uninhabited static",
2761    @future_incompatible = FutureIncompatibleInfo {
2762        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
2763        reference: "issue #74840 <https://github.com/rust-lang/rust/issues/74840>",
2764    };
2765}
2766
2767declare_lint! {
2768    /// The `unnameable_test_items` lint detects [`#[test]`][test] functions
2769    /// that are not able to be run by the test harness because they are in a
2770    /// position where they are not nameable.
2771    ///
2772    /// [test]: https://doc.rust-lang.org/reference/attributes/testing.html#the-test-attribute
2773    ///
2774    /// ### Example
2775    ///
2776    /// ```rust,test
2777    /// fn main() {
2778    ///     #[test]
2779    ///     fn foo() {
2780    ///         // This test will not fail because it does not run.
2781    ///         assert_eq!(1, 2);
2782    ///     }
2783    /// }
2784    /// ```
2785    ///
2786    /// {{produces}}
2787    ///
2788    /// ### Explanation
2789    ///
2790    /// In order for the test harness to run a test, the test function must be
2791    /// located in a position where it can be accessed from the crate root.
2792    /// This generally means it must be defined in a module, and not anywhere
2793    /// else such as inside another function. The compiler previously allowed
2794    /// this without an error, so a lint was added as an alert that a test is
2795    /// not being used. Whether or not this should be allowed has not yet been
2796    /// decided, see [RFC 2471] and [issue #36629].
2797    ///
2798    /// [RFC 2471]: https://github.com/rust-lang/rfcs/pull/2471#issuecomment-397414443
2799    /// [issue #36629]: https://github.com/rust-lang/rust/issues/36629
2800    pub UNNAMEABLE_TEST_ITEMS,
2801    Warn,
2802    "detects an item that cannot be named being marked as `#[test_case]`",
2803    report_in_external_macro
2804}
2805
2806declare_lint! {
2807    /// The `useless_deprecated` lint detects deprecation attributes with no effect.
2808    ///
2809    /// ### Example
2810    ///
2811    /// ```rust,compile_fail
2812    /// struct X;
2813    ///
2814    /// #[deprecated = "message"]
2815    /// impl Default for X {
2816    ///     fn default() -> Self {
2817    ///         X
2818    ///     }
2819    /// }
2820    /// ```
2821    ///
2822    /// {{produces}}
2823    ///
2824    /// ### Explanation
2825    ///
2826    /// Deprecation attributes have no effect on trait implementations.
2827    pub USELESS_DEPRECATED,
2828    Deny,
2829    "detects deprecation attributes with no effect",
2830}
2831
2832declare_lint! {
2833    /// The `ineffective_unstable_trait_impl` lint detects `#[unstable]` attributes which are not used.
2834    ///
2835    /// ### Example
2836    ///
2837    /// ```rust,compile_fail
2838    /// #![feature(staged_api)]
2839    ///
2840    /// #[derive(Clone)]
2841    /// #[stable(feature = "x", since = "1")]
2842    /// struct S {}
2843    ///
2844    /// #[unstable(feature = "y", issue = "none")]
2845    /// impl Copy for S {}
2846    /// ```
2847    ///
2848    /// {{produces}}
2849    ///
2850    /// ### Explanation
2851    ///
2852    /// `staged_api` does not currently support using a stability attribute on `impl` blocks.
2853    /// `impl`s are always stable if both the type and trait are stable, and always unstable otherwise.
2854    pub INEFFECTIVE_UNSTABLE_TRAIT_IMPL,
2855    Deny,
2856    "detects `#[unstable]` on stable trait implementations for stable types"
2857}
2858
2859declare_lint! {
2860    /// The `self_constructor_from_outer_item` lint detects cases where the `Self` constructor
2861    /// was silently allowed due to a bug in the resolver, and which may produce surprising
2862    /// and unintended behavior.
2863    ///
2864    /// Using a `Self` type alias from an outer item was never intended, but was silently allowed.
2865    /// This is deprecated -- and is a hard error when the `Self` type alias references generics
2866    /// that are not in scope.
2867    ///
2868    /// ### Example
2869    ///
2870    /// ```rust,compile_fail
2871    /// #![deny(self_constructor_from_outer_item)]
2872    ///
2873    /// struct S0(usize);
2874    ///
2875    /// impl S0 {
2876    ///     fn foo() {
2877    ///         const C: S0 = Self(0);
2878    ///         fn bar() -> S0 {
2879    ///             Self(0)
2880    ///         }
2881    ///     }
2882    /// }
2883    /// ```
2884    ///
2885    /// {{produces}}
2886    ///
2887    /// ### Explanation
2888    ///
2889    /// The `Self` type alias should not be reachable because nested items are not associated with
2890    /// the scope of the parameters from the parent item.
2891    pub SELF_CONSTRUCTOR_FROM_OUTER_ITEM,
2892    Warn,
2893    "detect unsupported use of `Self` from outer item",
2894    @future_incompatible = FutureIncompatibleInfo {
2895        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
2896        reference: "issue #124186 <https://github.com/rust-lang/rust/issues/124186>",
2897    };
2898}
2899
2900declare_lint! {
2901    /// The `semicolon_in_expressions_from_macros` lint detects trailing semicolons
2902    /// in macro bodies when the macro is invoked in expression position.
2903    /// This was previous accepted, but is being phased out.
2904    ///
2905    /// ### Example
2906    ///
2907    /// ```rust,compile_fail
2908    /// #![deny(semicolon_in_expressions_from_macros)]
2909    /// macro_rules! foo {
2910    ///     () => { true; }
2911    /// }
2912    ///
2913    /// fn main() {
2914    ///     let val = match true {
2915    ///         true => false,
2916    ///         _ => foo!()
2917    ///     };
2918    /// }
2919    /// ```
2920    ///
2921    /// {{produces}}
2922    ///
2923    /// ### Explanation
2924    ///
2925    /// Previous, Rust ignored trailing semicolon in a macro
2926    /// body when a macro was invoked in expression position.
2927    /// However, this makes the treatment of semicolons in the language
2928    /// inconsistent, and could lead to unexpected runtime behavior
2929    /// in some circumstances (e.g. if the macro author expects
2930    /// a value to be dropped).
2931    ///
2932    /// This is a [future-incompatible] lint to transition this
2933    /// to a hard error in the future. See [issue #79813] for more details.
2934    ///
2935    /// [issue #79813]: https://github.com/rust-lang/rust/issues/79813
2936    /// [future-incompatible]: ../index.md#future-incompatible-lints
2937    pub SEMICOLON_IN_EXPRESSIONS_FROM_MACROS,
2938    Warn,
2939    "trailing semicolon in macro body used as expression",
2940    @future_incompatible = FutureIncompatibleInfo {
2941        reason: FutureIncompatibilityReason::FutureReleaseErrorReportInDeps,
2942        reference: "issue #79813 <https://github.com/rust-lang/rust/issues/79813>",
2943    };
2944}
2945
2946declare_lint! {
2947    /// The `legacy_derive_helpers` lint detects derive helper attributes
2948    /// that are used before they are introduced.
2949    ///
2950    /// ### Example
2951    ///
2952    /// ```rust,ignore (needs extern crate)
2953    /// #[serde(rename_all = "camelCase")]
2954    /// #[derive(Deserialize)]
2955    /// struct S { /* fields */ }
2956    /// ```
2957    ///
2958    /// produces:
2959    ///
2960    /// ```text
2961    /// warning: derive helper attribute is used before it is introduced
2962    ///   --> $DIR/legacy-derive-helpers.rs:1:3
2963    ///    |
2964    ///  1 | #[serde(rename_all = "camelCase")]
2965    ///    |   ^^^^^
2966    /// ...
2967    ///  2 | #[derive(Deserialize)]
2968    ///    |          ----------- the attribute is introduced here
2969    /// ```
2970    ///
2971    /// ### Explanation
2972    ///
2973    /// Attributes like this work for historical reasons, but attribute expansion works in
2974    /// left-to-right order in general, so, to resolve `#[serde]`, compiler has to try to "look
2975    /// into the future" at not yet expanded part of the item , but such attempts are not always
2976    /// reliable.
2977    ///
2978    /// To fix the warning place the helper attribute after its corresponding derive.
2979    /// ```rust,ignore (needs extern crate)
2980    /// #[derive(Deserialize)]
2981    /// #[serde(rename_all = "camelCase")]
2982    /// struct S { /* fields */ }
2983    /// ```
2984    pub LEGACY_DERIVE_HELPERS,
2985    Warn,
2986    "detects derive helper attributes that are used before they are introduced",
2987    @future_incompatible = FutureIncompatibleInfo {
2988        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
2989        reference: "issue #79202 <https://github.com/rust-lang/rust/issues/79202>",
2990    };
2991}
2992
2993declare_lint! {
2994    /// The `large_assignments` lint detects when objects of large
2995    /// types are being moved around.
2996    ///
2997    /// ### Example
2998    ///
2999    /// ```rust,ignore (can crash on some platforms)
3000    /// let x = [0; 50000];
3001    /// let y = x;
3002    /// ```
3003    ///
3004    /// produces:
3005    ///
3006    /// ```text
3007    /// warning: moving a large value
3008    ///   --> $DIR/move-large.rs:1:3
3009    ///   let y = x;
3010    ///           - Copied large value here
3011    /// ```
3012    ///
3013    /// ### Explanation
3014    ///
3015    /// When using a large type in a plain assignment or in a function
3016    /// argument, idiomatic code can be inefficient.
3017    /// Ideally appropriate optimizations would resolve this, but such
3018    /// optimizations are only done in a best-effort manner.
3019    /// This lint will trigger on all sites of large moves and thus allow the
3020    /// user to resolve them in code.
3021    pub LARGE_ASSIGNMENTS,
3022    Warn,
3023    "detects large moves or copies",
3024}
3025
3026declare_lint! {
3027    /// The `unexpected_cfgs` lint detects unexpected conditional compilation conditions.
3028    ///
3029    /// ### Example
3030    ///
3031    /// ```text
3032    /// rustc --check-cfg 'cfg()'
3033    /// ```
3034    ///
3035    /// ```rust,ignore (needs command line option)
3036    /// #[cfg(widnows)]
3037    /// fn foo() {}
3038    /// ```
3039    ///
3040    /// This will produce:
3041    ///
3042    /// ```text
3043    /// warning: unexpected `cfg` condition name: `widnows`
3044    ///  --> lint_example.rs:1:7
3045    ///   |
3046    /// 1 | #[cfg(widnows)]
3047    ///   |       ^^^^^^^
3048    ///   |
3049    ///   = note: `#[warn(unexpected_cfgs)]` on by default
3050    /// ```
3051    ///
3052    /// ### Explanation
3053    ///
3054    /// This lint is only active when [`--check-cfg`][check-cfg] arguments are being
3055    /// passed to the compiler and triggers whenever an unexpected condition name or value is
3056    /// used.
3057    ///
3058    /// See the [Checking Conditional Configurations][check-cfg] section for more
3059    /// details.
3060    ///
3061    /// See the [Cargo Specifics][unexpected_cfgs_lint_config] section for configuring this lint in
3062    /// `Cargo.toml`.
3063    ///
3064    /// [check-cfg]: https://doc.rust-lang.org/nightly/rustc/check-cfg.html
3065    /// [unexpected_cfgs_lint_config]: https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html#check-cfg-in-lintsrust-table
3066    pub UNEXPECTED_CFGS,
3067    Warn,
3068    "detects unexpected names and values in `#[cfg]` conditions",
3069    report_in_external_macro
3070}
3071
3072declare_lint! {
3073    /// The `explicit_builtin_cfgs_in_flags` lint detects builtin cfgs set via the `--cfg` flag.
3074    ///
3075    /// ### Example
3076    ///
3077    /// ```text
3078    /// rustc --cfg unix
3079    /// ```
3080    ///
3081    /// ```rust,ignore (needs command line option)
3082    /// fn main() {}
3083    /// ```
3084    ///
3085    /// This will produce:
3086    ///
3087    /// ```text
3088    /// error: unexpected `--cfg unix` flag
3089    ///   |
3090    ///   = note: config `unix` is only supposed to be controlled by `--target`
3091    ///   = note: manually setting a built-in cfg can and does create incoherent behaviors
3092    ///   = note: `#[deny(explicit_builtin_cfgs_in_flags)]` on by default
3093    /// ```
3094    ///
3095    /// ### Explanation
3096    ///
3097    /// Setting builtin cfgs can and does produce incoherent behavior, it's better to the use
3098    /// the appropriate `rustc` flag that controls the config. For example setting the `windows`
3099    /// cfg but on Linux based target.
3100    pub EXPLICIT_BUILTIN_CFGS_IN_FLAGS,
3101    Deny,
3102    "detects builtin cfgs set via the `--cfg`"
3103}
3104
3105declare_lint! {
3106    /// The `repr_transparent_external_private_fields` lint
3107    /// detects types marked `#[repr(transparent)]` that (transitively)
3108    /// contain an external ZST type marked `#[non_exhaustive]` or containing
3109    /// private fields
3110    ///
3111    /// ### Example
3112    ///
3113    /// ```rust,ignore (needs external crate)
3114    /// #![deny(repr_transparent_external_private_fields)]
3115    /// use foo::NonExhaustiveZst;
3116    ///
3117    /// #[repr(transparent)]
3118    /// struct Bar(u32, ([u32; 0], NonExhaustiveZst));
3119    /// ```
3120    ///
3121    /// This will produce:
3122    ///
3123    /// ```text
3124    /// error: zero-sized fields in repr(transparent) cannot contain external non-exhaustive types
3125    ///  --> src/main.rs:5:28
3126    ///   |
3127    /// 5 | struct Bar(u32, ([u32; 0], NonExhaustiveZst));
3128    ///   |                            ^^^^^^^^^^^^^^^^
3129    ///   |
3130    /// note: the lint level is defined here
3131    ///  --> src/main.rs:1:9
3132    ///   |
3133    /// 1 | #![deny(repr_transparent_external_private_fields)]
3134    ///   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3135    ///   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
3136    ///   = note: for more information, see issue #78586 <https://github.com/rust-lang/rust/issues/78586>
3137    ///   = note: this struct contains `NonExhaustiveZst`, which is marked with `#[non_exhaustive]`, and makes it not a breaking change to become non-zero-sized in the future.
3138    /// ```
3139    ///
3140    /// ### Explanation
3141    ///
3142    /// Previous, Rust accepted fields that contain external private zero-sized types,
3143    /// even though it should not be a breaking change to add a non-zero-sized field to
3144    /// that private type.
3145    ///
3146    /// This is a [future-incompatible] lint to transition this
3147    /// to a hard error in the future. See [issue #78586] for more details.
3148    ///
3149    /// [issue #78586]: https://github.com/rust-lang/rust/issues/78586
3150    /// [future-incompatible]: ../index.md#future-incompatible-lints
3151    pub REPR_TRANSPARENT_EXTERNAL_PRIVATE_FIELDS,
3152    Warn,
3153    "transparent type contains an external ZST that is marked #[non_exhaustive] or contains private fields",
3154    @future_incompatible = FutureIncompatibleInfo {
3155        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
3156        reference: "issue #78586 <https://github.com/rust-lang/rust/issues/78586>",
3157    };
3158}
3159
3160declare_lint! {
3161    /// The `unstable_syntax_pre_expansion` lint detects the use of unstable
3162    /// syntax that is discarded during attribute expansion.
3163    ///
3164    /// ### Example
3165    ///
3166    /// ```rust
3167    /// #[cfg(FALSE)]
3168    /// macro foo() {}
3169    /// ```
3170    ///
3171    /// {{produces}}
3172    ///
3173    /// ### Explanation
3174    ///
3175    /// The input to active attributes such as `#[cfg]` or procedural macro
3176    /// attributes is required to be valid syntax. Previously, the compiler only
3177    /// gated the use of unstable syntax features after resolving `#[cfg]` gates
3178    /// and expanding procedural macros.
3179    ///
3180    /// To avoid relying on unstable syntax, move the use of unstable syntax
3181    /// into a position where the compiler does not parse the syntax, such as a
3182    /// functionlike macro.
3183    ///
3184    /// ```rust
3185    /// # #![deny(unstable_syntax_pre_expansion)]
3186    ///
3187    /// macro_rules! identity {
3188    ///    ( $($tokens:tt)* ) => { $($tokens)* }
3189    /// }
3190    ///
3191    /// #[cfg(FALSE)]
3192    /// identity! {
3193    ///    macro foo() {}
3194    /// }
3195    /// ```
3196    ///
3197    /// This is a [future-incompatible] lint to transition this
3198    /// to a hard error in the future. See [issue #65860] for more details.
3199    ///
3200    /// [issue #65860]: https://github.com/rust-lang/rust/issues/65860
3201    /// [future-incompatible]: ../index.md#future-incompatible-lints
3202    pub UNSTABLE_SYNTAX_PRE_EXPANSION,
3203    Warn,
3204    "unstable syntax can change at any point in the future, causing a hard error!",
3205    @future_incompatible = FutureIncompatibleInfo {
3206        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
3207        reference: "issue #65860 <https://github.com/rust-lang/rust/issues/65860>",
3208    };
3209}
3210
3211declare_lint! {
3212    /// The `ambiguous_glob_reexports` lint detects cases where names re-exported via globs
3213    /// collide. Downstream users trying to use the same name re-exported from multiple globs
3214    /// will receive a warning pointing out redefinition of the same name.
3215    ///
3216    /// ### Example
3217    ///
3218    /// ```rust,compile_fail
3219    /// #![deny(ambiguous_glob_reexports)]
3220    /// pub mod foo {
3221    ///     pub type X = u8;
3222    /// }
3223    ///
3224    /// pub mod bar {
3225    ///     pub type Y = u8;
3226    ///     pub type X = u8;
3227    /// }
3228    ///
3229    /// pub use foo::*;
3230    /// pub use bar::*;
3231    ///
3232    ///
3233    /// pub fn main() {}
3234    /// ```
3235    ///
3236    /// {{produces}}
3237    ///
3238    /// ### Explanation
3239    ///
3240    /// This was previously accepted but it could silently break a crate's downstream users code.
3241    /// For example, if `foo::*` and `bar::*` were re-exported before `bar::X` was added to the
3242    /// re-exports, down stream users could use `this_crate::X` without problems. However, adding
3243    /// `bar::X` would cause compilation errors in downstream crates because `X` is defined
3244    /// multiple times in the same namespace of `this_crate`.
3245    pub AMBIGUOUS_GLOB_REEXPORTS,
3246    Warn,
3247    "ambiguous glob re-exports",
3248}
3249
3250declare_lint! {
3251    /// The `hidden_glob_reexports` lint detects cases where glob re-export items are shadowed by
3252    /// private items.
3253    ///
3254    /// ### Example
3255    ///
3256    /// ```rust,compile_fail
3257    /// #![deny(hidden_glob_reexports)]
3258    ///
3259    /// pub mod upstream {
3260    ///     mod inner { pub struct Foo {}; pub struct Bar {}; }
3261    ///     pub use self::inner::*;
3262    ///     struct Foo {} // private item shadows `inner::Foo`
3263    /// }
3264    ///
3265    /// // mod downstream {
3266    /// //     fn test() {
3267    /// //         let _ = crate::upstream::Foo; // inaccessible
3268    /// //     }
3269    /// // }
3270    ///
3271    /// pub fn main() {}
3272    /// ```
3273    ///
3274    /// {{produces}}
3275    ///
3276    /// ### Explanation
3277    ///
3278    /// This was previously accepted without any errors or warnings but it could silently break a
3279    /// crate's downstream user code. If the `struct Foo` was added, `dep::inner::Foo` would
3280    /// silently become inaccessible and trigger a "`struct `Foo` is private`" visibility error at
3281    /// the downstream use site.
3282    pub HIDDEN_GLOB_REEXPORTS,
3283    Warn,
3284    "name introduced by a private item shadows a name introduced by a public glob re-export",
3285}
3286
3287declare_lint! {
3288    /// The `long_running_const_eval` lint is emitted when const
3289    /// eval is running for a long time to ensure rustc terminates
3290    /// even if you accidentally wrote an infinite loop.
3291    ///
3292    /// ### Example
3293    ///
3294    /// ```rust,compile_fail
3295    /// const FOO: () = loop {};
3296    /// ```
3297    ///
3298    /// {{produces}}
3299    ///
3300    /// ### Explanation
3301    ///
3302    /// Loops allow const evaluation to compute arbitrary code, but may also
3303    /// cause infinite loops or just very long running computations.
3304    /// Users can enable long running computations by allowing the lint
3305    /// on individual constants or for entire crates.
3306    ///
3307    /// ### Unconditional warnings
3308    ///
3309    /// Note that regardless of whether the lint is allowed or set to warn,
3310    /// the compiler will issue warnings if constant evaluation runs significantly
3311    /// longer than this lint's limit. These warnings are also shown to downstream
3312    /// users from crates.io or similar registries. If you are above the lint's limit,
3313    /// both you and downstream users might be exposed to these warnings.
3314    /// They might also appear on compiler updates, as the compiler makes minor changes
3315    /// about how complexity is measured: staying below the limit ensures that there
3316    /// is enough room, and given that the lint is disabled for people who use your
3317    /// dependency it means you will be the only one to get the warning and can put
3318    /// out an update in your own time.
3319    pub LONG_RUNNING_CONST_EVAL,
3320    Deny,
3321    "detects long const eval operations",
3322    report_in_external_macro
3323}
3324
3325declare_lint! {
3326    /// The `unused_associated_type_bounds` lint is emitted when an
3327    /// associated type bound is added to a trait object, but the associated
3328    /// type has a `where Self: Sized` bound, and is thus unavailable on the
3329    /// trait object anyway.
3330    ///
3331    /// ### Example
3332    ///
3333    /// ```rust
3334    /// trait Foo {
3335    ///     type Bar where Self: Sized;
3336    /// }
3337    /// type Mop = dyn Foo<Bar = ()>;
3338    /// ```
3339    ///
3340    /// {{produces}}
3341    ///
3342    /// ### Explanation
3343    ///
3344    /// Just like methods with `Self: Sized` bounds are unavailable on trait
3345    /// objects, associated types can be removed from the trait object.
3346    pub UNUSED_ASSOCIATED_TYPE_BOUNDS,
3347    Warn,
3348    "detects unused `Foo = Bar` bounds in `dyn Trait<Foo = Bar>`"
3349}
3350
3351declare_lint! {
3352    /// The `unused_doc_comments` lint detects doc comments that aren't used
3353    /// by `rustdoc`.
3354    ///
3355    /// ### Example
3356    ///
3357    /// ```rust
3358    /// /// docs for x
3359    /// let x = 12;
3360    /// ```
3361    ///
3362    /// {{produces}}
3363    ///
3364    /// ### Explanation
3365    ///
3366    /// `rustdoc` does not use doc comments in all positions, and so the doc
3367    /// comment will be ignored. Try changing it to a normal comment with `//`
3368    /// to avoid the warning.
3369    pub UNUSED_DOC_COMMENTS,
3370    Warn,
3371    "detects doc comments that aren't used by rustdoc"
3372}
3373
3374declare_lint! {
3375    /// The `rust_2021_incompatible_closure_captures` lint detects variables that aren't completely
3376    /// captured in Rust 2021, such that the `Drop` order of their fields may differ between
3377    /// Rust 2018 and 2021.
3378    ///
3379    /// It can also detect when a variable implements a trait like `Send`, but one of its fields does not,
3380    /// and the field is captured by a closure and used with the assumption that said field implements
3381    /// the same trait as the root variable.
3382    ///
3383    /// ### Example of drop reorder
3384    ///
3385    /// ```rust,edition2018,compile_fail
3386    /// #![deny(rust_2021_incompatible_closure_captures)]
3387    /// # #![allow(unused)]
3388    ///
3389    /// struct FancyInteger(i32);
3390    ///
3391    /// impl Drop for FancyInteger {
3392    ///     fn drop(&mut self) {
3393    ///         println!("Just dropped {}", self.0);
3394    ///     }
3395    /// }
3396    ///
3397    /// struct Point { x: FancyInteger, y: FancyInteger }
3398    ///
3399    /// fn main() {
3400    ///   let p = Point { x: FancyInteger(10), y: FancyInteger(20) };
3401    ///
3402    ///   let c = || {
3403    ///      let x = p.x;
3404    ///   };
3405    ///
3406    ///   c();
3407    ///
3408    ///   // ... More code ...
3409    /// }
3410    /// ```
3411    ///
3412    /// {{produces}}
3413    ///
3414    /// ### Explanation
3415    ///
3416    /// In the above example, `p.y` will be dropped at the end of `f` instead of
3417    /// with `c` in Rust 2021.
3418    ///
3419    /// ### Example of auto-trait
3420    ///
3421    /// ```rust,edition2018,compile_fail
3422    /// #![deny(rust_2021_incompatible_closure_captures)]
3423    /// use std::thread;
3424    ///
3425    /// struct Pointer(*mut i32);
3426    /// unsafe impl Send for Pointer {}
3427    ///
3428    /// fn main() {
3429    ///     let mut f = 10;
3430    ///     let fptr = Pointer(&mut f as *mut i32);
3431    ///     thread::spawn(move || unsafe {
3432    ///         *fptr.0 = 20;
3433    ///     });
3434    /// }
3435    /// ```
3436    ///
3437    /// {{produces}}
3438    ///
3439    /// ### Explanation
3440    ///
3441    /// In the above example, only `fptr.0` is captured in Rust 2021.
3442    /// The field is of type `*mut i32`, which doesn't implement `Send`,
3443    /// making the code invalid as the field cannot be sent between threads safely.
3444    pub RUST_2021_INCOMPATIBLE_CLOSURE_CAPTURES,
3445    Allow,
3446    "detects closures affected by Rust 2021 changes",
3447    @future_incompatible = FutureIncompatibleInfo {
3448        reason: FutureIncompatibilityReason::EditionSemanticsChange(Edition::Edition2021),
3449        explain_reason: false,
3450    };
3451}
3452
3453declare_lint_pass!(UnusedDocComment => [UNUSED_DOC_COMMENTS]);
3454
3455declare_lint! {
3456    /// The `missing_abi` lint detects cases where the ABI is omitted from
3457    /// `extern` declarations.
3458    ///
3459    /// ### Example
3460    ///
3461    /// ```rust,compile_fail
3462    /// #![deny(missing_abi)]
3463    ///
3464    /// extern fn foo() {}
3465    /// ```
3466    ///
3467    /// {{produces}}
3468    ///
3469    /// ### Explanation
3470    ///
3471    /// For historic reasons, Rust implicitly selects `C` as the default ABI for
3472    /// `extern` declarations. [Other ABIs] like `C-unwind` and `system` have
3473    /// been added since then, and especially with their addition seeing the ABI
3474    /// easily makes code review easier.
3475    ///
3476    /// [Other ABIs]: https://doc.rust-lang.org/reference/items/external-blocks.html#abi
3477    pub MISSING_ABI,
3478    Warn,
3479    "No declared ABI for extern declaration"
3480}
3481
3482declare_lint! {
3483    /// The `invalid_doc_attributes` lint detects when the `#[doc(...)]` is
3484    /// misused.
3485    ///
3486    /// ### Example
3487    ///
3488    /// ```rust,compile_fail
3489    /// #![deny(warnings)]
3490    ///
3491    /// pub mod submodule {
3492    ///     #![doc(test(no_crate_inject))]
3493    /// }
3494    /// ```
3495    ///
3496    /// {{produces}}
3497    ///
3498    /// ### Explanation
3499    ///
3500    /// Previously, incorrect usage of the `#[doc(..)]` attribute was not
3501    /// being validated. Usually these should be rejected as a hard error,
3502    /// but this lint was introduced to avoid breaking any existing
3503    /// crates which included them.
3504    pub INVALID_DOC_ATTRIBUTES,
3505    Deny,
3506    "detects invalid `#[doc(...)]` attributes",
3507}
3508
3509declare_lint! {
3510    /// The `rust_2021_incompatible_or_patterns` lint detects usage of old versions of or-patterns.
3511    ///
3512    /// ### Example
3513    ///
3514    /// ```rust,edition2018,compile_fail
3515    /// #![deny(rust_2021_incompatible_or_patterns)]
3516    ///
3517    /// macro_rules! match_any {
3518    ///     ( $expr:expr , $( $( $pat:pat )|+ => $expr_arm:expr ),+ ) => {
3519    ///         match $expr {
3520    ///             $(
3521    ///                 $( $pat => $expr_arm, )+
3522    ///             )+
3523    ///         }
3524    ///     };
3525    /// }
3526    ///
3527    /// fn main() {
3528    ///     let result: Result<i64, i32> = Err(42);
3529    ///     let int: i64 = match_any!(result, Ok(i) | Err(i) => i.into());
3530    ///     assert_eq!(int, 42);
3531    /// }
3532    /// ```
3533    ///
3534    /// {{produces}}
3535    ///
3536    /// ### Explanation
3537    ///
3538    /// In Rust 2021, the `pat` matcher will match additional patterns, which include the `|` character.
3539    pub RUST_2021_INCOMPATIBLE_OR_PATTERNS,
3540    Allow,
3541    "detects usage of old versions of or-patterns",
3542    @future_incompatible = FutureIncompatibleInfo {
3543        reason: FutureIncompatibilityReason::EditionError(Edition::Edition2021),
3544        reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2021/or-patterns-macro-rules.html>",
3545    };
3546}
3547
3548declare_lint! {
3549    /// The `rust_2021_prelude_collisions` lint detects the usage of trait methods which are ambiguous
3550    /// with traits added to the prelude in future editions.
3551    ///
3552    /// ### Example
3553    ///
3554    /// ```rust,edition2018,compile_fail
3555    /// #![deny(rust_2021_prelude_collisions)]
3556    ///
3557    /// trait Foo {
3558    ///     fn try_into(self) -> Result<String, !>;
3559    /// }
3560    ///
3561    /// impl Foo for &str {
3562    ///     fn try_into(self) -> Result<String, !> {
3563    ///         Ok(String::from(self))
3564    ///     }
3565    /// }
3566    ///
3567    /// fn main() {
3568    ///     let x: String = "3".try_into().unwrap();
3569    ///     //                  ^^^^^^^^
3570    ///     // This call to try_into matches both Foo::try_into and TryInto::try_into as
3571    ///     // `TryInto` has been added to the Rust prelude in 2021 edition.
3572    ///     println!("{x}");
3573    /// }
3574    /// ```
3575    ///
3576    /// {{produces}}
3577    ///
3578    /// ### Explanation
3579    ///
3580    /// In Rust 2021, one of the important introductions is the [prelude changes], which add
3581    /// `TryFrom`, `TryInto`, and `FromIterator` into the standard library's prelude. Since this
3582    /// results in an ambiguity as to which method/function to call when an existing `try_into`
3583    /// method is called via dot-call syntax or a `try_from`/`from_iter` associated function
3584    /// is called directly on a type.
3585    ///
3586    /// [prelude changes]: https://blog.rust-lang.org/inside-rust/2021/03/04/planning-rust-2021.html#prelude-changes
3587    pub RUST_2021_PRELUDE_COLLISIONS,
3588    Allow,
3589    "detects the usage of trait methods which are ambiguous with traits added to the \
3590        prelude in future editions",
3591    @future_incompatible = FutureIncompatibleInfo {
3592        reason: FutureIncompatibilityReason::EditionError(Edition::Edition2021),
3593        reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2021/prelude.html>",
3594    };
3595}
3596
3597declare_lint! {
3598    /// The `rust_2024_prelude_collisions` lint detects the usage of trait methods which are ambiguous
3599    /// with traits added to the prelude in future editions.
3600    ///
3601    /// ### Example
3602    ///
3603    /// ```rust,edition2021,compile_fail
3604    /// #![deny(rust_2024_prelude_collisions)]
3605    /// trait Meow {
3606    ///     fn poll(&self) {}
3607    /// }
3608    /// impl<T> Meow for T {}
3609    ///
3610    /// fn main() {
3611    ///     core::pin::pin!(async {}).poll();
3612    ///     //                        ^^^^^^
3613    ///     // This call to try_into matches both Future::poll and Meow::poll as
3614    ///     // `Future` has been added to the Rust prelude in 2024 edition.
3615    /// }
3616    /// ```
3617    ///
3618    /// {{produces}}
3619    ///
3620    /// ### Explanation
3621    ///
3622    /// Rust 2024, introduces two new additions to the standard library's prelude:
3623    /// `Future` and `IntoFuture`. This results in an ambiguity as to which method/function
3624    /// to call when an existing `poll`/`into_future` method is called via dot-call syntax or
3625    /// a `poll`/`into_future` associated function is called directly on a type.
3626    ///
3627    pub RUST_2024_PRELUDE_COLLISIONS,
3628    Allow,
3629    "detects the usage of trait methods which are ambiguous with traits added to the \
3630        prelude in future editions",
3631    @future_incompatible = FutureIncompatibleInfo {
3632        reason: FutureIncompatibilityReason::EditionError(Edition::Edition2024),
3633        reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2024/prelude.html>",
3634    };
3635}
3636
3637declare_lint! {
3638    /// The `rust_2021_prefixes_incompatible_syntax` lint detects identifiers that will be parsed as a
3639    /// prefix instead in Rust 2021.
3640    ///
3641    /// ### Example
3642    ///
3643    /// ```rust,edition2018,compile_fail
3644    /// #![deny(rust_2021_prefixes_incompatible_syntax)]
3645    ///
3646    /// macro_rules! m {
3647    ///     (z $x:expr) => ();
3648    /// }
3649    ///
3650    /// m!(z"hey");
3651    /// ```
3652    ///
3653    /// {{produces}}
3654    ///
3655    /// ### Explanation
3656    ///
3657    /// In Rust 2015 and 2018, `z"hey"` is two tokens: the identifier `z`
3658    /// followed by the string literal `"hey"`. In Rust 2021, the `z` is
3659    /// considered a prefix for `"hey"`.
3660    ///
3661    /// This lint suggests to add whitespace between the `z` and `"hey"` tokens
3662    /// to keep them separated in Rust 2021.
3663    // Allow this lint -- rustdoc doesn't yet support threading edition into this lint's parser.
3664    #[allow(rustdoc::invalid_rust_codeblocks)]
3665    pub RUST_2021_PREFIXES_INCOMPATIBLE_SYNTAX,
3666    Allow,
3667    "identifiers that will be parsed as a prefix in Rust 2021",
3668    @future_incompatible = FutureIncompatibleInfo {
3669        reason: FutureIncompatibilityReason::EditionError(Edition::Edition2021),
3670        reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2021/reserving-syntax.html>",
3671    };
3672    crate_level_only
3673}
3674
3675declare_lint! {
3676    /// The `unsupported_fn_ptr_calling_conventions` lint is output whenever there is a use of
3677    /// a target dependent calling convention on a target that does not support this calling
3678    /// convention on a function pointer.
3679    ///
3680    /// For example `stdcall` does not make much sense for a x86_64 or, more apparently, powerpc
3681    /// code, because this calling convention was never specified for those targets.
3682    ///
3683    /// ### Example
3684    ///
3685    /// ```rust,ignore (needs specific targets)
3686    /// fn stdcall_ptr(f: extern "stdcall" fn ()) {
3687    ///     f()
3688    /// }
3689    /// ```
3690    ///
3691    /// This will produce:
3692    ///
3693    /// ```text
3694    /// warning: the calling convention `"stdcall"` is not supported on this target
3695    ///   --> $DIR/unsupported.rs:34:15
3696    ///    |
3697    /// LL | fn stdcall_ptr(f: extern "stdcall" fn()) {
3698    ///    |               ^^^^^^^^^^^^^^^^^^^^^^^^
3699    ///    |
3700    ///    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
3701    ///    = note: for more information, see issue #130260 <https://github.com/rust-lang/rust/issues/130260>
3702    ///    = note: `#[warn(unsupported_fn_ptr_calling_conventions)]` on by default
3703    /// ```
3704    ///
3705    /// ### Explanation
3706    ///
3707    /// On most of the targets the behaviour of `stdcall` and similar calling conventions is not
3708    /// defined at all, but was previously accepted due to a bug in the implementation of the
3709    /// compiler.
3710    pub UNSUPPORTED_FN_PTR_CALLING_CONVENTIONS,
3711    Warn,
3712    "use of unsupported calling convention for function pointer",
3713    @future_incompatible = FutureIncompatibleInfo {
3714        reason: FutureIncompatibilityReason::FutureReleaseErrorReportInDeps,
3715        reference: "issue #130260 <https://github.com/rust-lang/rust/issues/130260>",
3716    };
3717}
3718
3719declare_lint! {
3720    /// The `break_with_label_and_loop` lint detects labeled `break` expressions with
3721    /// an unlabeled loop as their value expression.
3722    ///
3723    /// ### Example
3724    ///
3725    /// ```rust
3726    /// 'label: loop {
3727    ///     break 'label loop { break 42; };
3728    /// };
3729    /// ```
3730    ///
3731    /// {{produces}}
3732    ///
3733    /// ### Explanation
3734    ///
3735    /// In Rust, loops can have a label, and `break` expressions can refer to that label to
3736    /// break out of specific loops (and not necessarily the innermost one). `break` expressions
3737    /// can also carry a value expression, which can be another loop. A labeled `break` with an
3738    /// unlabeled loop as its value expression is easy to confuse with an unlabeled break with
3739    /// a labeled loop and is thus discouraged (but allowed for compatibility); use parentheses
3740    /// around the loop expression to silence this warning. Unlabeled `break` expressions with
3741    /// labeled loops yield a hard error, which can also be silenced by wrapping the expression
3742    /// in parentheses.
3743    pub BREAK_WITH_LABEL_AND_LOOP,
3744    Warn,
3745    "`break` expression with label and unlabeled loop as value expression"
3746}
3747
3748declare_lint! {
3749    /// The `non_exhaustive_omitted_patterns` lint aims to help consumers of a `#[non_exhaustive]`
3750    /// struct or enum who want to match all of its fields/variants explicitly.
3751    ///
3752    /// The `#[non_exhaustive]` annotation forces matches to use wildcards, so exhaustiveness
3753    /// checking cannot be used to ensure that all fields/variants are matched explicitly. To remedy
3754    /// this, this allow-by-default lint warns the user when a match mentions some but not all of
3755    /// the fields/variants of a `#[non_exhaustive]` struct or enum.
3756    ///
3757    /// ### Example
3758    ///
3759    /// ```rust,ignore (needs separate crate)
3760    /// // crate A
3761    /// #[non_exhaustive]
3762    /// pub enum Bar {
3763    ///     A,
3764    ///     B, // added variant in non breaking change
3765    /// }
3766    ///
3767    /// // in crate B
3768    /// #![feature(non_exhaustive_omitted_patterns_lint)]
3769    /// #[warn(non_exhaustive_omitted_patterns)]
3770    /// match Bar::A {
3771    ///     Bar::A => {},
3772    ///     _ => {},
3773    /// }
3774    /// ```
3775    ///
3776    /// This will produce:
3777    ///
3778    /// ```text
3779    /// warning: some variants are not matched explicitly
3780    ///    --> $DIR/reachable-patterns.rs:70:9
3781    ///    |
3782    /// LL |         match Bar::A {
3783    ///    |               ^ pattern `Bar::B` not covered
3784    ///    |
3785    ///  note: the lint level is defined here
3786    ///   --> $DIR/reachable-patterns.rs:69:16
3787    ///    |
3788    /// LL |         #[warn(non_exhaustive_omitted_patterns)]
3789    ///    |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3790    ///    = help: ensure that all variants are matched explicitly by adding the suggested match arms
3791    ///    = note: the matched value is of type `Bar` and the `non_exhaustive_omitted_patterns` attribute was found
3792    /// ```
3793    ///
3794    /// Warning: setting this to `deny` will make upstream non-breaking changes (adding fields or
3795    /// variants to a `#[non_exhaustive]` struct or enum) break your crate. This goes against
3796    /// expected semver behavior.
3797    ///
3798    /// ### Explanation
3799    ///
3800    /// Structs and enums tagged with `#[non_exhaustive]` force the user to add a (potentially
3801    /// redundant) wildcard when pattern-matching, to allow for future addition of fields or
3802    /// variants. The `non_exhaustive_omitted_patterns` lint detects when such a wildcard happens to
3803    /// actually catch some fields/variants. In other words, when the match without the wildcard
3804    /// would not be exhaustive. This lets the user be informed if new fields/variants were added.
3805    pub NON_EXHAUSTIVE_OMITTED_PATTERNS,
3806    Allow,
3807    "detect when patterns of types marked `non_exhaustive` are missed",
3808    @feature_gate = non_exhaustive_omitted_patterns_lint;
3809}
3810
3811declare_lint! {
3812    #[allow(text_direction_codepoint_in_literal)]
3813    /// The `text_direction_codepoint_in_comment` lint detects Unicode codepoints in comments that
3814    /// change the visual representation of text on screen in a way that does not correspond to
3815    /// their on memory representation.
3816    ///
3817    /// ### Example
3818    ///
3819    /// ```rust,compile_fail
3820    /// #![deny(text_direction_codepoint_in_comment)]
3821    /// fn main() {
3822    ///     println!("{:?}"); // '‮');
3823    /// }
3824    /// ```
3825    ///
3826    /// {{produces}}
3827    ///
3828    /// ### Explanation
3829    ///
3830    /// Unicode allows changing the visual flow of text on screen in order to support scripts that
3831    /// are written right-to-left, but a specially crafted comment can make code that will be
3832    /// compiled appear to be part of a comment, depending on the software used to read the code.
3833    /// To avoid potential problems or confusion, such as in CVE-2021-42574, by default we deny
3834    /// their use.
3835    pub TEXT_DIRECTION_CODEPOINT_IN_COMMENT,
3836    Deny,
3837    "invisible directionality-changing codepoints in comment"
3838}
3839
3840declare_lint! {
3841    /// The `duplicate_macro_attributes` lint detects when a `#[test]`-like built-in macro
3842    /// attribute is duplicated on an item. This lint may trigger on `bench`, `cfg_eval`, `test`
3843    /// and `test_case`.
3844    ///
3845    /// ### Example
3846    ///
3847    /// ```rust,ignore (needs --test)
3848    /// #[test]
3849    /// #[test]
3850    /// fn foo() {}
3851    /// ```
3852    ///
3853    /// This will produce:
3854    ///
3855    /// ```text
3856    /// warning: duplicated attribute
3857    ///  --> src/lib.rs:2:1
3858    ///   |
3859    /// 2 | #[test]
3860    ///   | ^^^^^^^
3861    ///   |
3862    ///   = note: `#[warn(duplicate_macro_attributes)]` on by default
3863    /// ```
3864    ///
3865    /// ### Explanation
3866    ///
3867    /// A duplicated attribute may erroneously originate from a copy-paste and the effect of it
3868    /// being duplicated may not be obvious or desirable.
3869    ///
3870    /// For instance, doubling the `#[test]` attributes registers the test to be run twice with no
3871    /// change to its environment.
3872    ///
3873    /// [issue #90979]: https://github.com/rust-lang/rust/issues/90979
3874    pub DUPLICATE_MACRO_ATTRIBUTES,
3875    Warn,
3876    "duplicated attribute"
3877}
3878
3879declare_lint! {
3880    /// The `deprecated_where_clause_location` lint detects when a where clause in front of the equals
3881    /// in an associated type.
3882    ///
3883    /// ### Example
3884    ///
3885    /// ```rust
3886    /// trait Trait {
3887    ///   type Assoc<'a> where Self: 'a;
3888    /// }
3889    ///
3890    /// impl Trait for () {
3891    ///   type Assoc<'a> where Self: 'a = ();
3892    /// }
3893    /// ```
3894    ///
3895    /// {{produces}}
3896    ///
3897    /// ### Explanation
3898    ///
3899    /// The preferred location for where clauses on associated types
3900    /// is after the type. However, for most of generic associated types development,
3901    /// it was only accepted before the equals. To provide a transition period and
3902    /// further evaluate this change, both are currently accepted. At some point in
3903    /// the future, this may be disallowed at an edition boundary; but, that is
3904    /// undecided currently.
3905    pub DEPRECATED_WHERE_CLAUSE_LOCATION,
3906    Warn,
3907    "deprecated where clause location"
3908}
3909
3910declare_lint! {
3911    /// The `test_unstable_lint` lint tests unstable lints and is perma-unstable.
3912    ///
3913    /// ### Example
3914    ///
3915    /// ```rust
3916    /// // This lint is intentionally used to test the compiler's behavior
3917    /// // when an unstable lint is enabled without the corresponding feature gate.
3918    /// #![allow(test_unstable_lint)]
3919    /// ```
3920    ///
3921    /// {{produces}}
3922    ///
3923    /// ### Explanation
3924    ///
3925    /// In order to test the behavior of unstable lints, a permanently-unstable
3926    /// lint is required. This lint can be used to trigger warnings and errors
3927    /// from the compiler related to unstable lints.
3928    pub TEST_UNSTABLE_LINT,
3929    Deny,
3930    "this unstable lint is only for testing",
3931    @feature_gate = test_unstable_lint;
3932}
3933
3934declare_lint! {
3935    /// The `ffi_unwind_calls` lint detects calls to foreign functions or function pointers with
3936    /// `C-unwind` or other FFI-unwind ABIs.
3937    ///
3938    /// ### Example
3939    ///
3940    /// ```rust
3941    /// #![warn(ffi_unwind_calls)]
3942    ///
3943    /// unsafe extern "C-unwind" {
3944    ///     fn foo();
3945    /// }
3946    ///
3947    /// fn bar() {
3948    ///     unsafe { foo(); }
3949    ///     let ptr: unsafe extern "C-unwind" fn() = foo;
3950    ///     unsafe { ptr(); }
3951    /// }
3952    /// ```
3953    ///
3954    /// {{produces}}
3955    ///
3956    /// ### Explanation
3957    ///
3958    /// For crates containing such calls, if they are compiled with `-C panic=unwind` then the
3959    /// produced library cannot be linked with crates compiled with `-C panic=abort`. For crates
3960    /// that desire this ability it is therefore necessary to avoid such calls.
3961    pub FFI_UNWIND_CALLS,
3962    Allow,
3963    "call to foreign functions or function pointers with FFI-unwind ABI"
3964}
3965
3966declare_lint! {
3967    /// The `linker_messages` lint forwards warnings from the linker.
3968    ///
3969    /// ### Example
3970    ///
3971    /// ```rust,ignore (needs CLI args, platform-specific)
3972    /// #[warn(linker_messages)]
3973    /// extern "C" {
3974    ///   fn foo();
3975    /// }
3976    /// fn main () { unsafe { foo(); } }
3977    /// ```
3978    ///
3979    /// On Linux, using `gcc -Wl,--warn-unresolved-symbols` as a linker, this will produce
3980    ///
3981    /// ```text
3982    /// warning: linker stderr: rust-lld: undefined symbol: foo
3983    ///          >>> referenced by rust_out.69edbd30df4ae57d-cgu.0
3984    ///          >>>               rust_out.rust_out.69edbd30df4ae57d-cgu.0.rcgu.o:(rust_out::main::h3a90094b06757803)
3985    ///   |
3986    /// note: the lint level is defined here
3987    ///  --> warn.rs:1:9
3988    ///   |
3989    /// 1 | #![warn(linker_messages)]
3990    ///   |         ^^^^^^^^^^^^^^^
3991    /// warning: 1 warning emitted
3992    /// ```
3993    ///
3994    /// ### Explanation
3995    ///
3996    /// Linkers emit platform-specific and program-specific warnings that cannot be predicted in
3997    /// advance by the Rust compiler. Such messages are ignored by default for now. While linker
3998    /// warnings could be very useful they have been ignored for many years by essentially all
3999    /// users, so we need to do a bit more work than just surfacing their text to produce a clear
4000    /// and actionable warning of similar quality to our other diagnostics. See this tracking
4001    /// issue for more details: <https://github.com/rust-lang/rust/issues/136096>.
4002    pub LINKER_MESSAGES,
4003    Allow,
4004    "warnings emitted at runtime by the target-specific linker program"
4005}
4006
4007declare_lint! {
4008    /// The `named_arguments_used_positionally` lint detects cases where named arguments are only
4009    /// used positionally in format strings. This usage is valid but potentially very confusing.
4010    ///
4011    /// ### Example
4012    ///
4013    /// ```rust,compile_fail
4014    /// #![deny(named_arguments_used_positionally)]
4015    /// fn main() {
4016    ///     let _x = 5;
4017    ///     println!("{}", _x = 1); // Prints 1, will trigger lint
4018    ///
4019    ///     println!("{}", _x); // Prints 5, no lint emitted
4020    ///     println!("{_x}", _x = _x); // Prints 5, no lint emitted
4021    /// }
4022    /// ```
4023    ///
4024    /// {{produces}}
4025    ///
4026    /// ### Explanation
4027    ///
4028    /// Rust formatting strings can refer to named arguments by their position, but this usage is
4029    /// potentially confusing. In particular, readers can incorrectly assume that the declaration
4030    /// of named arguments is an assignment (which would produce the unit type).
4031    /// For backwards compatibility, this is not a hard error.
4032    pub NAMED_ARGUMENTS_USED_POSITIONALLY,
4033    Warn,
4034    "named arguments in format used positionally"
4035}
4036
4037declare_lint! {
4038    /// The `never_type_fallback_flowing_into_unsafe` lint detects cases where never type fallback
4039    /// affects unsafe function calls.
4040    ///
4041    /// ### Never type fallback
4042    ///
4043    /// When the compiler sees a value of type [`!`] it implicitly inserts a coercion (if possible),
4044    /// to allow type check to infer any type:
4045    ///
4046    /// ```ignore (illustrative-and-has-placeholders)
4047    /// // this
4048    /// let x: u8 = panic!();
4049    ///
4050    /// // is (essentially) turned by the compiler into
4051    /// let x: u8 = absurd(panic!());
4052    ///
4053    /// // where absurd is a function with the following signature
4054    /// // (it's sound, because `!` always marks unreachable code):
4055    /// fn absurd<T>(never: !) -> T { ... }
4056    /// ```
4057    ///
4058    /// While it's convenient to be able to use non-diverging code in one of the branches (like
4059    /// `if a { b } else { return }`) this could lead to compilation errors:
4060    ///
4061    /// ```compile_fail
4062    /// // this
4063    /// { panic!() };
4064    ///
4065    /// // gets turned into this
4066    /// { absurd(panic!()) }; // error: can't infer the type of `absurd`
4067    /// ```
4068    ///
4069    /// To prevent such errors, compiler remembers where it inserted `absurd` calls, and if it
4070    /// can't infer their type, it sets the type to fallback. `{ absurd::<Fallback>(panic!()) };`.
4071    /// This is what is known as "never type fallback".
4072    ///
4073    /// ### Example
4074    ///
4075    /// ```rust,compile_fail
4076    /// #![deny(never_type_fallback_flowing_into_unsafe)]
4077    /// fn main() {
4078    ///     if true {
4079    ///         // return has type `!` which, is some cases, causes never type fallback
4080    ///         return
4081    ///     } else {
4082    ///         // `zeroed` is an unsafe function, which returns an unbounded type
4083    ///         unsafe { std::mem::zeroed() }
4084    ///     };
4085    ///     // depending on the fallback, `zeroed` may create `()` (which is completely sound),
4086    ///     // or `!` (which is instant undefined behavior)
4087    /// }
4088    /// ```
4089    ///
4090    /// {{produces}}
4091    ///
4092    /// ### Explanation
4093    ///
4094    /// Due to historic reasons never type fallback was `()`, meaning that `!` got spontaneously
4095    /// coerced to `()`. There are plans to change that, but they may make the code such as above
4096    /// unsound. Instead of depending on the fallback, you should specify the type explicitly:
4097    /// ```
4098    /// if true {
4099    ///     return
4100    /// } else {
4101    ///     // type is explicitly specified, fallback can't hurt us no more
4102    ///     unsafe { std::mem::zeroed::<()>() }
4103    /// };
4104    /// ```
4105    ///
4106    /// See [Tracking Issue for making `!` fall back to `!`](https://github.com/rust-lang/rust/issues/123748).
4107    ///
4108    /// [`!`]: https://doc.rust-lang.org/core/primitive.never.html
4109    /// [`()`]: https://doc.rust-lang.org/core/primitive.unit.html
4110    pub NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE,
4111    Warn,
4112    "never type fallback affecting unsafe function calls",
4113    @future_incompatible = FutureIncompatibleInfo {
4114        reason: FutureIncompatibilityReason::EditionAndFutureReleaseSemanticsChange(Edition::Edition2024),
4115        reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2024/never-type-fallback.html>",
4116    };
4117    @edition Edition2024 => Deny;
4118    report_in_external_macro
4119}
4120
4121declare_lint! {
4122    /// The `dependency_on_unit_never_type_fallback` lint detects cases where code compiles with
4123    /// [never type fallback] being [`()`], but will stop compiling with fallback being [`!`].
4124    ///
4125    /// [never type fallback]: https://doc.rust-lang.org/nightly/core/primitive.never.html#never-type-fallback
4126    /// [`!`]: https://doc.rust-lang.org/core/primitive.never.html
4127    /// [`()`]: https://doc.rust-lang.org/core/primitive.unit.html
4128    ///
4129    /// ### Example
4130    ///
4131    /// ```rust,compile_fail
4132    /// #![deny(dependency_on_unit_never_type_fallback)]
4133    /// fn main() {
4134    ///     if true {
4135    ///         // return has type `!` which, is some cases, causes never type fallback
4136    ///         return
4137    ///     } else {
4138    ///         // the type produced by this call is not specified explicitly,
4139    ///         // so it will be inferred from the previous branch
4140    ///         Default::default()
4141    ///     };
4142    ///     // depending on the fallback, this may compile (because `()` implements `Default`),
4143    ///     // or it may not (because `!` does not implement `Default`)
4144    /// }
4145    /// ```
4146    ///
4147    /// {{produces}}
4148    ///
4149    /// ### Explanation
4150    ///
4151    /// Due to historic reasons never type fallback was `()`, meaning that `!` got spontaneously
4152    /// coerced to `()`. There are plans to change that, but they may make the code such as above
4153    /// not compile. Instead of depending on the fallback, you should specify the type explicitly:
4154    /// ```
4155    /// if true {
4156    ///     return
4157    /// } else {
4158    ///     // type is explicitly specified, fallback can't hurt us no more
4159    ///     <() as Default>::default()
4160    /// };
4161    /// ```
4162    ///
4163    /// See [Tracking Issue for making `!` fall back to `!`](https://github.com/rust-lang/rust/issues/123748).
4164    pub DEPENDENCY_ON_UNIT_NEVER_TYPE_FALLBACK,
4165    Warn,
4166    "never type fallback affecting unsafe function calls",
4167    @future_incompatible = FutureIncompatibleInfo {
4168        reason: FutureIncompatibilityReason::EditionAndFutureReleaseError(Edition::Edition2024),
4169        reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2024/never-type-fallback.html>",
4170    };
4171    report_in_external_macro
4172}
4173
4174declare_lint! {
4175    /// The `invalid_macro_export_arguments` lint detects cases where `#[macro_export]` is being used with invalid arguments.
4176    ///
4177    /// ### Example
4178    ///
4179    /// ```rust,compile_fail
4180    /// #![deny(invalid_macro_export_arguments)]
4181    ///
4182    /// #[macro_export(invalid_parameter)]
4183    /// macro_rules! myMacro {
4184    ///    () => {
4185    ///         // [...]
4186    ///    }
4187    /// }
4188    ///
4189    /// #[macro_export(too, many, items)]
4190    /// ```
4191    ///
4192    /// {{produces}}
4193    ///
4194    /// ### Explanation
4195    ///
4196    /// The only valid argument is `#[macro_export(local_inner_macros)]` or no argument (`#[macro_export]`).
4197    /// You can't have multiple arguments in a `#[macro_export(..)]`, or mention arguments other than `local_inner_macros`.
4198    ///
4199    pub INVALID_MACRO_EXPORT_ARGUMENTS,
4200    Warn,
4201    "\"invalid_parameter\" isn't a valid argument for `#[macro_export]`",
4202}
4203
4204declare_lint! {
4205    /// The `private_interfaces` lint detects types in a primary interface of an item,
4206    /// that are more private than the item itself. Primary interface of an item is all
4207    /// its interface except for bounds on generic parameters and where clauses.
4208    ///
4209    /// ### Example
4210    ///
4211    /// ```rust,compile_fail
4212    /// # #![allow(unused)]
4213    /// #![deny(private_interfaces)]
4214    /// struct SemiPriv;
4215    ///
4216    /// mod m1 {
4217    ///     struct Priv;
4218    ///     impl crate::SemiPriv {
4219    ///         pub fn f(_: Priv) {}
4220    ///     }
4221    /// }
4222    ///
4223    /// # fn main() {}
4224    /// ```
4225    ///
4226    /// {{produces}}
4227    ///
4228    /// ### Explanation
4229    ///
4230    /// Having something private in primary interface guarantees that
4231    /// the item will be unusable from outer modules due to type privacy.
4232    pub PRIVATE_INTERFACES,
4233    Warn,
4234    "private type in primary interface of an item",
4235}
4236
4237declare_lint! {
4238    /// The `private_bounds` lint detects types in a secondary interface of an item,
4239    /// that are more private than the item itself. Secondary interface of an item consists of
4240    /// bounds on generic parameters and where clauses, including supertraits for trait items.
4241    ///
4242    /// ### Example
4243    ///
4244    /// ```rust,compile_fail
4245    /// # #![allow(unused)]
4246    /// #![deny(private_bounds)]
4247    ///
4248    /// struct PrivTy;
4249    /// pub struct S
4250    ///     where PrivTy:
4251    /// {}
4252    /// # fn main() {}
4253    /// ```
4254    ///
4255    /// {{produces}}
4256    ///
4257    /// ### Explanation
4258    ///
4259    /// Having private types or traits in item bounds makes it less clear what interface
4260    /// the item actually provides.
4261    pub PRIVATE_BOUNDS,
4262    Warn,
4263    "private type in secondary interface of an item",
4264}
4265
4266declare_lint! {
4267    /// The `unnameable_types` lint detects types for which you can get objects of that type,
4268    /// but cannot name the type itself.
4269    ///
4270    /// ### Example
4271    ///
4272    /// ```rust,compile_fail
4273    /// # #![allow(unused)]
4274    /// #![deny(unnameable_types)]
4275    /// mod m {
4276    ///     pub struct S;
4277    /// }
4278    ///
4279    /// pub fn get_unnameable() -> m::S { m::S }
4280    /// # fn main() {}
4281    /// ```
4282    ///
4283    /// {{produces}}
4284    ///
4285    /// ### Explanation
4286    ///
4287    /// It is often expected that if you can obtain an object of type `T`, then
4288    /// you can name the type `T` as well; this lint attempts to enforce this rule.
4289    /// The recommended action is to either reexport the type properly to make it nameable,
4290    /// or document that users are not supposed to be able to name it for one reason or another.
4291    ///
4292    /// Besides types, this lint applies to traits because traits can also leak through signatures,
4293    /// and you may obtain objects of their `dyn Trait` or `impl Trait` types.
4294    pub UNNAMEABLE_TYPES,
4295    Allow,
4296    "effective visibility of a type is larger than the area in which it can be named",
4297}
4298
4299declare_lint! {
4300    /// The `unknown_or_malformed_diagnostic_attributes` lint detects unrecognized or otherwise malformed
4301    /// diagnostic attributes.
4302    ///
4303    /// ### Example
4304    ///
4305    /// ```rust
4306    /// #![feature(diagnostic_namespace)]
4307    /// #[diagnostic::does_not_exist]
4308    /// struct Foo;
4309    /// ```
4310    ///
4311    /// {{produces}}
4312    ///
4313    ///
4314    /// ### Explanation
4315    ///
4316    /// It is usually a mistake to specify a diagnostic attribute that does not exist. Check
4317    /// the spelling, and check the diagnostic attribute listing for the correct name. Also
4318    /// consider if you are using an old version of the compiler, and the attribute
4319    /// is only available in a newer version.
4320    pub UNKNOWN_OR_MALFORMED_DIAGNOSTIC_ATTRIBUTES,
4321    Warn,
4322    "unrecognized or malformed diagnostic attribute",
4323}
4324
4325declare_lint! {
4326    /// The `ambiguous_glob_imports` lint detects glob imports that should report ambiguity
4327    /// errors, but previously didn't do that due to rustc bugs.
4328    ///
4329    /// ### Example
4330    ///
4331    /// ```rust,compile_fail
4332    /// #![deny(ambiguous_glob_imports)]
4333    /// pub fn foo() -> u32 {
4334    ///     use sub::*;
4335    ///     C
4336    /// }
4337    ///
4338    /// mod sub {
4339    ///     mod mod1 { pub const C: u32 = 1; }
4340    ///     mod mod2 { pub const C: u32 = 2; }
4341    ///
4342    ///     pub use mod1::*;
4343    ///     pub use mod2::*;
4344    /// }
4345    /// ```
4346    ///
4347    /// {{produces}}
4348    ///
4349    /// ### Explanation
4350    ///
4351    /// Previous versions of Rust compile it successfully because it
4352    /// had lost the ambiguity error when resolve `use sub::mod2::*`.
4353    ///
4354    /// This is a [future-incompatible] lint to transition this to a
4355    /// hard error in the future.
4356    ///
4357    /// [future-incompatible]: ../index.md#future-incompatible-lints
4358    pub AMBIGUOUS_GLOB_IMPORTS,
4359    Warn,
4360    "detects certain glob imports that require reporting an ambiguity error",
4361    @future_incompatible = FutureIncompatibleInfo {
4362        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
4363        reference: "issue #114095 <https://github.com/rust-lang/rust/issues/114095>",
4364    };
4365}
4366
4367declare_lint! {
4368    /// The `refining_impl_trait_reachable` lint detects `impl Trait` return
4369    /// types in method signatures that are refined by a publically reachable
4370    /// trait implementation, meaning the implementation adds information about
4371    /// the return type that is not present in the trait.
4372    ///
4373    /// ### Example
4374    ///
4375    /// ```rust,compile_fail
4376    /// #![deny(refining_impl_trait)]
4377    ///
4378    /// use std::fmt::Display;
4379    ///
4380    /// pub trait AsDisplay {
4381    ///     fn as_display(&self) -> impl Display;
4382    /// }
4383    ///
4384    /// impl<'s> AsDisplay for &'s str {
4385    ///     fn as_display(&self) -> Self {
4386    ///         *self
4387    ///     }
4388    /// }
4389    ///
4390    /// fn main() {
4391    ///     // users can observe that the return type of
4392    ///     // `<&str as AsDisplay>::as_display()` is `&str`.
4393    ///     let _x: &str = "".as_display();
4394    /// }
4395    /// ```
4396    ///
4397    /// {{produces}}
4398    ///
4399    /// ### Explanation
4400    ///
4401    /// Callers of methods for types where the implementation is known are
4402    /// able to observe the types written in the impl signature. This may be
4403    /// intended behavior, but may also lead to implementation details being
4404    /// revealed unintentionally. In particular, it may pose a semver hazard
4405    /// for authors of libraries who do not wish to make stronger guarantees
4406    /// about the types than what is written in the trait signature.
4407    ///
4408    /// `refining_impl_trait` is a lint group composed of two lints:
4409    ///
4410    /// * `refining_impl_trait_reachable`, for refinements that are publically
4411    ///   reachable outside a crate, and
4412    /// * `refining_impl_trait_internal`, for refinements that are only visible
4413    ///    within a crate.
4414    ///
4415    /// We are seeking feedback on each of these lints; see issue
4416    /// [#121718](https://github.com/rust-lang/rust/issues/121718) for more
4417    /// information.
4418    pub REFINING_IMPL_TRAIT_REACHABLE,
4419    Warn,
4420    "impl trait in impl method signature does not match trait method signature",
4421}
4422
4423declare_lint! {
4424    /// The `refining_impl_trait_internal` lint detects `impl Trait` return
4425    /// types in method signatures that are refined by a trait implementation,
4426    /// meaning the implementation adds information about the return type that
4427    /// is not present in the trait.
4428    ///
4429    /// ### Example
4430    ///
4431    /// ```rust,compile_fail
4432    /// #![deny(refining_impl_trait)]
4433    ///
4434    /// use std::fmt::Display;
4435    ///
4436    /// trait AsDisplay {
4437    ///     fn as_display(&self) -> impl Display;
4438    /// }
4439    ///
4440    /// impl<'s> AsDisplay for &'s str {
4441    ///     fn as_display(&self) -> Self {
4442    ///         *self
4443    ///     }
4444    /// }
4445    ///
4446    /// fn main() {
4447    ///     // users can observe that the return type of
4448    ///     // `<&str as AsDisplay>::as_display()` is `&str`.
4449    ///     let _x: &str = "".as_display();
4450    /// }
4451    /// ```
4452    ///
4453    /// {{produces}}
4454    ///
4455    /// ### Explanation
4456    ///
4457    /// Callers of methods for types where the implementation is known are
4458    /// able to observe the types written in the impl signature. This may be
4459    /// intended behavior, but may also lead to implementation details being
4460    /// revealed unintentionally. In particular, it may pose a semver hazard
4461    /// for authors of libraries who do not wish to make stronger guarantees
4462    /// about the types than what is written in the trait signature.
4463    ///
4464    /// `refining_impl_trait` is a lint group composed of two lints:
4465    ///
4466    /// * `refining_impl_trait_reachable`, for refinements that are publically
4467    ///   reachable outside a crate, and
4468    /// * `refining_impl_trait_internal`, for refinements that are only visible
4469    ///    within a crate.
4470    ///
4471    /// We are seeking feedback on each of these lints; see issue
4472    /// [#121718](https://github.com/rust-lang/rust/issues/121718) for more
4473    /// information.
4474    pub REFINING_IMPL_TRAIT_INTERNAL,
4475    Warn,
4476    "impl trait in impl method signature does not match trait method signature",
4477}
4478
4479declare_lint! {
4480    /// The `elided_lifetimes_in_associated_constant` lint detects elided lifetimes
4481    /// in associated constants when there are other lifetimes in scope. This was
4482    /// accidentally supported, and this lint was later relaxed to allow eliding
4483    /// lifetimes to `'static` when there are no lifetimes in scope.
4484    ///
4485    /// ### Example
4486    ///
4487    /// ```rust,compile_fail
4488    /// #![deny(elided_lifetimes_in_associated_constant)]
4489    ///
4490    /// struct Foo<'a>(&'a ());
4491    ///
4492    /// impl<'a> Foo<'a> {
4493    ///     const STR: &str = "hello, world";
4494    /// }
4495    /// ```
4496    ///
4497    /// {{produces}}
4498    ///
4499    /// ### Explanation
4500    ///
4501    /// Previous version of Rust
4502    ///
4503    /// Implicit static-in-const behavior was decided [against] for associated
4504    /// constants because of ambiguity. This, however, regressed and the compiler
4505    /// erroneously treats elided lifetimes in associated constants as lifetime
4506    /// parameters on the impl.
4507    ///
4508    /// This is a [future-incompatible] lint to transition this to a
4509    /// hard error in the future.
4510    ///
4511    /// [against]: https://github.com/rust-lang/rust/issues/38831
4512    /// [future-incompatible]: ../index.md#future-incompatible-lints
4513    pub ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT,
4514    Deny,
4515    "elided lifetimes cannot be used in associated constants in impls",
4516    @future_incompatible = FutureIncompatibleInfo {
4517        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
4518        reference: "issue #115010 <https://github.com/rust-lang/rust/issues/115010>",
4519    };
4520}
4521
4522declare_lint! {
4523    /// The `private_macro_use` lint detects private macros that are imported
4524    /// with `#[macro_use]`.
4525    ///
4526    /// ### Example
4527    ///
4528    /// ```rust,ignore (needs extern crate)
4529    /// // extern_macro.rs
4530    /// macro_rules! foo_ { () => {}; }
4531    /// use foo_ as foo;
4532    ///
4533    /// // code.rs
4534    ///
4535    /// #![deny(private_macro_use)]
4536    ///
4537    /// #[macro_use]
4538    /// extern crate extern_macro;
4539    ///
4540    /// fn main() {
4541    ///     foo!();
4542    /// }
4543    /// ```
4544    ///
4545    /// This will produce:
4546    ///
4547    /// ```text
4548    /// error: cannot find macro `foo` in this scope
4549    /// ```
4550    ///
4551    /// ### Explanation
4552    ///
4553    /// This lint arises from overlooking visibility checks for macros
4554    /// in an external crate.
4555    ///
4556    /// This is a [future-incompatible] lint to transition this to a
4557    /// hard error in the future.
4558    ///
4559    /// [future-incompatible]: ../index.md#future-incompatible-lints
4560    pub PRIVATE_MACRO_USE,
4561    Warn,
4562    "detects certain macro bindings that should not be re-exported",
4563    @future_incompatible = FutureIncompatibleInfo {
4564        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
4565        reference: "issue #120192 <https://github.com/rust-lang/rust/issues/120192>",
4566    };
4567}
4568
4569declare_lint! {
4570    /// The `uncovered_param_in_projection` lint detects a violation of one of Rust's orphan rules for
4571    /// foreign trait implementations that concerns the use of type parameters inside trait associated
4572    /// type paths ("projections") whose output may not be a local type that is mistakenly considered
4573    /// to "cover" said parameters which is **unsound** and which may be rejected by a future version
4574    /// of the compiler.
4575    ///
4576    /// Originally reported in [#99554].
4577    ///
4578    /// [#99554]: https://github.com/rust-lang/rust/issues/99554
4579    ///
4580    /// ### Example
4581    ///
4582    /// ```rust,ignore (dependent)
4583    /// // dependency.rs
4584    /// #![crate_type = "lib"]
4585    ///
4586    /// pub trait Trait<T, U> {}
4587    /// ```
4588    ///
4589    /// ```edition2021,ignore (needs dependency)
4590    /// // dependent.rs
4591    /// trait Identity {
4592    ///     type Output;
4593    /// }
4594    ///
4595    /// impl<T> Identity for T {
4596    ///     type Output = T;
4597    /// }
4598    ///
4599    /// struct Local;
4600    ///
4601    /// impl<T> dependency::Trait<Local, T> for <T as Identity>::Output {}
4602    ///
4603    /// fn main() {}
4604    /// ```
4605    ///
4606    /// This will produce:
4607    ///
4608    /// ```text
4609    /// warning[E0210]: type parameter `T` must be covered by another type when it appears before the first local type (`Local`)
4610    ///   --> dependent.rs:11:6
4611    ///    |
4612    /// 11 | impl<T> dependency::Trait<Local, T> for <T as Identity>::Output {}
4613    ///    |      ^ type parameter `T` must be covered by another type when it appears before the first local type (`Local`)
4614    ///    |
4615    ///    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
4616    ///    = note: for more information, see issue #124559 <https://github.com/rust-lang/rust/issues/124559>
4617    ///    = note: implementing a foreign trait is only possible if at least one of the types for which it is implemented is local, and no uncovered type parameters appear before that first local type
4618    ///    = note: in this case, 'before' refers to the following order: `impl<..> ForeignTrait<T1, ..., Tn> for T0`, where `T0` is the first and `Tn` is the last
4619    ///    = note: `#[warn(uncovered_param_in_projection)]` on by default
4620    /// ```
4621    ///
4622    /// ### Explanation
4623    ///
4624    /// FIXME(fmease): Write explainer.
4625    pub UNCOVERED_PARAM_IN_PROJECTION,
4626    Warn,
4627    "impl contains type parameters that are not covered",
4628    @future_incompatible = FutureIncompatibleInfo {
4629        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
4630        reference: "issue #124559 <https://github.com/rust-lang/rust/issues/124559>",
4631    };
4632}
4633
4634declare_lint! {
4635    /// The `deprecated_safe_2024` lint detects unsafe functions being used as
4636    /// safe functions.
4637    ///
4638    /// ### Example
4639    ///
4640    /// ```rust,edition2021,compile_fail
4641    /// #![deny(deprecated_safe)]
4642    /// // edition 2021
4643    /// use std::env;
4644    /// fn enable_backtrace() {
4645    ///     env::set_var("RUST_BACKTRACE", "1");
4646    /// }
4647    /// ```
4648    ///
4649    /// {{produces}}
4650    ///
4651    /// ### Explanation
4652    ///
4653    /// Rust [editions] allow the language to evolve without breaking backward
4654    /// compatibility. This lint catches code that uses `unsafe` functions that
4655    /// were declared as safe (non-`unsafe`) in editions prior to Rust 2024. If
4656    /// you switch the compiler to Rust 2024 without updating the code, then it
4657    /// will fail to compile if you are using a function previously marked as
4658    /// safe.
4659    ///
4660    /// You can audit the code to see if it suffices the preconditions of the
4661    /// `unsafe` code, and if it does, you can wrap it in an `unsafe` block. If
4662    /// you can't fulfill the preconditions, you probably need to switch to a
4663    /// different way of doing what you want to achieve.
4664    ///
4665    /// This lint can automatically wrap the calls in `unsafe` blocks, but this
4666    /// obviously cannot verify that the preconditions of the `unsafe`
4667    /// functions are fulfilled, so that is still up to the user.
4668    ///
4669    /// The lint is currently "allow" by default, but that might change in the
4670    /// future.
4671    ///
4672    /// [editions]: https://doc.rust-lang.org/edition-guide/
4673    pub DEPRECATED_SAFE_2024,
4674    Allow,
4675    "detects unsafe functions being used as safe functions",
4676    @future_incompatible = FutureIncompatibleInfo {
4677        reason: FutureIncompatibilityReason::EditionError(Edition::Edition2024),
4678        reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2024/newly-unsafe-functions.html>",
4679    };
4680}
4681
4682declare_lint! {
4683    /// The `missing_unsafe_on_extern` lint detects missing unsafe keyword on extern declarations.
4684    ///
4685    /// ### Example
4686    ///
4687    /// ```rust,edition2021
4688    /// #![warn(missing_unsafe_on_extern)]
4689    /// #![allow(dead_code)]
4690    ///
4691    /// extern "C" {
4692    ///     fn foo(_: i32);
4693    /// }
4694    ///
4695    /// fn main() {}
4696    /// ```
4697    ///
4698    /// {{produces}}
4699    ///
4700    /// ### Explanation
4701    ///
4702    /// Declaring extern items, even without ever using them, can cause Undefined Behavior. We
4703    /// should consider all sources of Undefined Behavior to be unsafe.
4704    ///
4705    /// This is a [future-incompatible] lint to transition this to a
4706    /// hard error in the future.
4707    ///
4708    /// [future-incompatible]: ../index.md#future-incompatible-lints
4709    pub MISSING_UNSAFE_ON_EXTERN,
4710    Allow,
4711    "detects missing unsafe keyword on extern declarations",
4712    @future_incompatible = FutureIncompatibleInfo {
4713        reason: FutureIncompatibilityReason::EditionError(Edition::Edition2024),
4714        reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2024/unsafe-extern.html>",
4715    };
4716}
4717
4718declare_lint! {
4719    /// The `unsafe_attr_outside_unsafe` lint detects a missing unsafe keyword
4720    /// on attributes considered unsafe.
4721    ///
4722    /// ### Example
4723    ///
4724    /// ```rust,edition2021
4725    /// #![warn(unsafe_attr_outside_unsafe)]
4726    ///
4727    /// #[no_mangle]
4728    /// extern "C" fn foo() {}
4729    ///
4730    /// fn main() {}
4731    /// ```
4732    ///
4733    /// {{produces}}
4734    ///
4735    /// ### Explanation
4736    ///
4737    /// Some attributes (e.g. `no_mangle`, `export_name`, `link_section` -- see
4738    /// [issue #82499] for a more complete list) are considered "unsafe" attributes.
4739    /// An unsafe attribute must only be used inside unsafe(...).
4740    ///
4741    /// This lint can automatically wrap the attributes in `unsafe(...)` , but this
4742    /// obviously cannot verify that the preconditions of the `unsafe`
4743    /// attributes are fulfilled, so that is still up to the user.
4744    ///
4745    /// The lint is currently "allow" by default, but that might change in the
4746    /// future.
4747    ///
4748    /// [editions]: https://doc.rust-lang.org/edition-guide/
4749    /// [issue #82499]: https://github.com/rust-lang/rust/issues/82499
4750    pub UNSAFE_ATTR_OUTSIDE_UNSAFE,
4751    Allow,
4752    "detects unsafe attributes outside of unsafe",
4753    @future_incompatible = FutureIncompatibleInfo {
4754        reason: FutureIncompatibilityReason::EditionError(Edition::Edition2024),
4755        reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2024/unsafe-attributes.html>",
4756    };
4757}
4758
4759declare_lint! {
4760    /// The `out_of_scope_macro_calls` lint detects `macro_rules` called when they are not in scope,
4761    /// above their definition, which may happen in key-value attributes.
4762    ///
4763    /// ### Example
4764    ///
4765    /// ```rust
4766    /// #![doc = in_root!()]
4767    ///
4768    /// macro_rules! in_root { () => { "" } }
4769    ///
4770    /// fn main() {}
4771    /// ```
4772    ///
4773    /// {{produces}}
4774    ///
4775    /// ### Explanation
4776    ///
4777    /// The scope in which a `macro_rules` item is visible starts at that item and continues
4778    /// below it. This is more similar to `let` than to other items, which are in scope both above
4779    /// and below their definition.
4780    /// Due to a bug `macro_rules` were accidentally in scope inside some key-value attributes
4781    /// above their definition. The lint catches such cases.
4782    /// To address the issue turn the `macro_rules` into a regularly scoped item by importing it
4783    /// with `use`.
4784    ///
4785    /// This is a [future-incompatible] lint to transition this to a
4786    /// hard error in the future.
4787    ///
4788    /// [future-incompatible]: ../index.md#future-incompatible-lints
4789    pub OUT_OF_SCOPE_MACRO_CALLS,
4790    Warn,
4791    "detects out of scope calls to `macro_rules` in key-value attributes",
4792    @future_incompatible = FutureIncompatibleInfo {
4793        reason: FutureIncompatibilityReason::FutureReleaseErrorDontReportInDeps,
4794        reference: "issue #124535 <https://github.com/rust-lang/rust/issues/124535>",
4795    };
4796}
4797
4798declare_lint! {
4799    /// The `supertrait_item_shadowing_usage` lint detects when the
4800    /// usage of an item that is provided by both a subtrait and supertrait
4801    /// is shadowed, preferring the subtrait.
4802    ///
4803    /// ### Example
4804    ///
4805    /// ```rust,compile_fail
4806    /// #![feature(supertrait_item_shadowing)]
4807    /// #![deny(supertrait_item_shadowing_usage)]
4808    ///
4809    /// trait Upstream {
4810    ///     fn hello(&self) {}
4811    /// }
4812    /// impl<T> Upstream for T {}
4813    ///
4814    /// trait Downstream: Upstream {
4815    ///     fn hello(&self) {}
4816    /// }
4817    /// impl<T> Downstream for T {}
4818    ///
4819    /// struct MyType;
4820    /// MyType.hello();
4821    /// ```
4822    ///
4823    /// {{produces}}
4824    ///
4825    /// ### Explanation
4826    ///
4827    /// RFC 3624 specified a heuristic in which a supertrait item would be
4828    /// shadowed by a subtrait item when ambiguity occurs during item
4829    /// selection. In order to mitigate side-effects of this happening
4830    /// silently, this lint detects these cases when users want to deny them
4831    /// or fix the call sites.
4832    pub SUPERTRAIT_ITEM_SHADOWING_USAGE,
4833    // FIXME(supertrait_item_shadowing): It is not decided if this should
4834    // warn by default at the call site.
4835    Allow,
4836    "detects when a supertrait item is shadowed by a subtrait item",
4837    @feature_gate = supertrait_item_shadowing;
4838}
4839
4840declare_lint! {
4841    /// The `supertrait_item_shadowing_definition` lint detects when the
4842    /// definition of an item that is provided by both a subtrait and
4843    /// supertrait is shadowed, preferring the subtrait.
4844    ///
4845    /// ### Example
4846    ///
4847    /// ```rust,compile_fail
4848    /// #![feature(supertrait_item_shadowing)]
4849    /// #![deny(supertrait_item_shadowing_definition)]
4850    ///
4851    /// trait Upstream {
4852    ///     fn hello(&self) {}
4853    /// }
4854    /// impl<T> Upstream for T {}
4855    ///
4856    /// trait Downstream: Upstream {
4857    ///     fn hello(&self) {}
4858    /// }
4859    /// impl<T> Downstream for T {}
4860    /// ```
4861    ///
4862    /// {{produces}}
4863    ///
4864    /// ### Explanation
4865    ///
4866    /// RFC 3624 specified a heuristic in which a supertrait item would be
4867    /// shadowed by a subtrait item when ambiguity occurs during item
4868    /// selection. In order to mitigate side-effects of this happening
4869    /// silently, this lint detects these cases when users want to deny them
4870    /// or fix their trait definitions.
4871    pub SUPERTRAIT_ITEM_SHADOWING_DEFINITION,
4872    // FIXME(supertrait_item_shadowing): It is not decided if this should
4873    // warn by default at the usage site.
4874    Allow,
4875    "detects when a supertrait item is shadowed by a subtrait item",
4876    @feature_gate = supertrait_item_shadowing;
4877}
4878
4879declare_lint! {
4880    /// The `ptr_to_integer_transmute_in_consts` lint detects pointer to integer
4881    /// transmute in const functions and associated constants.
4882    ///
4883    /// ### Example
4884    ///
4885    /// ```rust
4886    /// const fn foo(ptr: *const u8) -> usize {
4887    ///    unsafe {
4888    ///        std::mem::transmute::<*const u8, usize>(ptr)
4889    ///    }
4890    /// }
4891    /// ```
4892    ///
4893    /// {{produces}}
4894    ///
4895    /// ### Explanation
4896    ///
4897    /// Transmuting pointers to integers in a `const` context is undefined behavior.
4898    /// Any attempt to use the resulting integer will abort const-evaluation.
4899    ///
4900    /// But sometimes the compiler might not emit an error for pointer to integer transmutes
4901    /// inside const functions and associated consts because they are evaluated only when referenced.
4902    /// Therefore, this lint serves as an extra layer of defense to prevent any undefined behavior
4903    /// from compiling without any warnings or errors.
4904    ///
4905    /// See [std::mem::transmute] in the reference for more details.
4906    ///
4907    /// [std::mem::transmute]: https://doc.rust-lang.org/std/mem/fn.transmute.html
4908    pub PTR_TO_INTEGER_TRANSMUTE_IN_CONSTS,
4909    Warn,
4910    "detects pointer to integer transmutes in const functions and associated constants",
4911}
4912
4913declare_lint! {
4914    /// The `tail_expr_drop_order` lint looks for those values generated at the tail expression location,
4915    /// that runs a custom `Drop` destructor.
4916    /// Some of them may be dropped earlier in Edition 2024 that they used to in Edition 2021 and prior.
4917    /// This lint detects those cases and provides you information on those values and their custom destructor implementations.
4918    /// Your discretion on this information is required.
4919    ///
4920    /// ### Example
4921    /// ```rust,edition2021
4922    /// #![warn(tail_expr_drop_order)]
4923    /// struct Droppy(i32);
4924    /// impl Droppy {
4925    ///     fn get(&self) -> i32 {
4926    ///         self.0
4927    ///     }
4928    /// }
4929    /// impl Drop for Droppy {
4930    ///     fn drop(&mut self) {
4931    ///         // This is a custom destructor and it induces side-effects that is observable
4932    ///         // especially when the drop order at a tail expression changes.
4933    ///         println!("loud drop {}", self.0);
4934    ///     }
4935    /// }
4936    /// fn edition_2021() -> i32 {
4937    ///     let another_droppy = Droppy(0);
4938    ///     Droppy(1).get()
4939    /// }
4940    /// fn main() {
4941    ///     edition_2021();
4942    /// }
4943    /// ```
4944    ///
4945    /// {{produces}}
4946    ///
4947    /// ### Explanation
4948    ///
4949    /// In tail expression of blocks or function bodies,
4950    /// values of type with significant `Drop` implementation has an ill-specified drop order
4951    /// before Edition 2024 so that they are dropped only after dropping local variables.
4952    /// Edition 2024 introduces a new rule with drop orders for them,
4953    /// so that they are dropped first before dropping local variables.
4954    ///
4955    /// A significant `Drop::drop` destructor here refers to an explicit, arbitrary
4956    /// implementation of the `Drop` trait on the type, with exceptions including `Vec`,
4957    /// `Box`, `Rc`, `BTreeMap` and `HashMap` that are marked by the compiler otherwise
4958    /// so long that the generic types have no significant destructor recursively.
4959    /// In other words, a type has a significant drop destructor when it has a `Drop` implementation
4960    /// or its destructor invokes a significant destructor on a type.
4961    /// Since we cannot completely reason about the change by just inspecting the existence of
4962    /// a significant destructor, this lint remains only a suggestion and is set to `allow` by default.
4963    ///
4964    /// This lint only points out the issue with `Droppy`, which will be dropped before `another_droppy`
4965    /// does in Edition 2024.
4966    /// No fix will be proposed by this lint.
4967    /// However, the most probable fix is to hoist `Droppy` into its own local variable binding.
4968    /// ```rust
4969    /// struct Droppy(i32);
4970    /// impl Droppy {
4971    ///     fn get(&self) -> i32 {
4972    ///         self.0
4973    ///     }
4974    /// }
4975    /// fn edition_2024() -> i32 {
4976    ///     let value = Droppy(0);
4977    ///     let another_droppy = Droppy(1);
4978    ///     value.get()
4979    /// }
4980    /// ```
4981    pub TAIL_EXPR_DROP_ORDER,
4982    Allow,
4983    "Detect and warn on significant change in drop order in tail expression location",
4984    @future_incompatible = FutureIncompatibleInfo {
4985        reason: FutureIncompatibilityReason::EditionSemanticsChange(Edition::Edition2024),
4986        reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2024/temporary-tail-expr-scope.html>",
4987    };
4988}
4989
4990declare_lint! {
4991    /// The `rust_2024_guarded_string_incompatible_syntax` lint detects `#` tokens
4992    /// that will be parsed as part of a guarded string literal in Rust 2024.
4993    ///
4994    /// ### Example
4995    ///
4996    /// ```rust,edition2021,compile_fail
4997    /// #![deny(rust_2024_guarded_string_incompatible_syntax)]
4998    ///
4999    /// macro_rules! m {
5000    ///     (# $x:expr #) => ();
5001    ///     (# $x:expr) => ();
5002    /// }
5003    ///
5004    /// m!(#"hey"#);
5005    /// m!(#"hello");
5006    /// ```
5007    ///
5008    /// {{produces}}
5009    ///
5010    /// ### Explanation
5011    ///
5012    /// Prior to Rust 2024, `#"hey"#` is three tokens: the first `#`
5013    /// followed by the string literal `"hey"` then the final `#`.
5014    /// In Rust 2024, the whole sequence is considered a single token.
5015    ///
5016    /// This lint suggests to add whitespace between the leading `#`
5017    /// and the string to keep them separated in Rust 2024.
5018    // Allow this lint -- rustdoc doesn't yet support threading edition into this lint's parser.
5019    #[allow(rustdoc::invalid_rust_codeblocks)]
5020    pub RUST_2024_GUARDED_STRING_INCOMPATIBLE_SYNTAX,
5021    Allow,
5022    "will be parsed as a guarded string in Rust 2024",
5023    @future_incompatible = FutureIncompatibleInfo {
5024        reason: FutureIncompatibilityReason::EditionError(Edition::Edition2024),
5025        reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2024/reserved-syntax.html>",
5026    };
5027    crate_level_only
5028}
5029
5030declare_lint! {
5031    /// The `abi_unsupported_vector_types` lint detects function definitions and calls
5032    /// whose ABI depends on enabling certain target features, but those features are not enabled.
5033    ///
5034    /// ### Example
5035    ///
5036    /// ```rust,ignore (fails on non-x86_64)
5037    /// extern "C" fn missing_target_feature(_: std::arch::x86_64::__m256) {
5038    ///   todo!()
5039    /// }
5040    ///
5041    /// #[target_feature(enable = "avx")]
5042    /// unsafe extern "C" fn with_target_feature(_: std::arch::x86_64::__m256) {
5043    ///   todo!()
5044    /// }
5045    ///
5046    /// fn main() {
5047    ///   let v = unsafe { std::mem::zeroed() };
5048    ///   unsafe { with_target_feature(v); }
5049    /// }
5050    /// ```
5051    ///
5052    /// This will produce:
5053    ///
5054    /// ```text
5055    /// warning: ABI error: this function call uses a avx vector type, which is not enabled in the caller
5056    ///  --> lint_example.rs:18:12
5057    ///   |
5058    ///   |   unsafe { with_target_feature(v); }
5059    ///   |            ^^^^^^^^^^^^^^^^^^^^^^ function called here
5060    ///   |
5061    ///   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
5062    ///   = note: for more information, see issue #116558 <https://github.com/rust-lang/rust/issues/116558>
5063    ///   = help: consider enabling it globally (-C target-feature=+avx) or locally (#[target_feature(enable="avx")])
5064    ///   = note: `#[warn(abi_unsupported_vector_types)]` on by default
5065    ///
5066    ///
5067    /// warning: ABI error: this function definition uses a avx vector type, which is not enabled
5068    ///  --> lint_example.rs:3:1
5069    ///   |
5070    ///   | pub extern "C" fn with_target_feature(_: std::arch::x86_64::__m256) {
5071    ///   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ function defined here
5072    ///   |
5073    ///   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
5074    ///   = note: for more information, see issue #116558 <https://github.com/rust-lang/rust/issues/116558>
5075    ///   = help: consider enabling it globally (-C target-feature=+avx) or locally (#[target_feature(enable="avx")])
5076    /// ```
5077    ///
5078    ///
5079    ///
5080    /// ### Explanation
5081    ///
5082    /// The C ABI for `__m256` requires the value to be passed in an AVX register,
5083    /// which is only possible when the `avx` target feature is enabled.
5084    /// Therefore, `missing_target_feature` cannot be compiled without that target feature.
5085    /// A similar (but complementary) message is triggered when `with_target_feature` is called
5086    /// by a function that does not enable the `avx` target feature.
5087    ///
5088    /// Note that this lint is very similar to the `-Wpsabi` warning in `gcc`/`clang`.
5089    pub ABI_UNSUPPORTED_VECTOR_TYPES,
5090    Warn,
5091    "this function call or definition uses a vector type which is not enabled",
5092    @future_incompatible = FutureIncompatibleInfo {
5093        reason: FutureIncompatibilityReason::FutureReleaseErrorReportInDeps,
5094        reference: "issue #116558 <https://github.com/rust-lang/rust/issues/116558>",
5095    };
5096}
5097
5098declare_lint! {
5099    /// The `wasm_c_abi` lint detects usage of the `extern "C"` ABI of wasm that is affected
5100    /// by a planned ABI change that has the goal of aligning Rust with the standard C ABI
5101    /// of this target.
5102    ///
5103    /// ### Example
5104    ///
5105    /// ```rust,ignore (needs wasm32-unknown-unknown)
5106    /// #[repr(C)]
5107    /// struct MyType(i32, i32);
5108    ///
5109    /// extern "C" my_fun(x: MyType) {}
5110    /// ```
5111    ///
5112    /// This will produce:
5113    ///
5114    /// ```text
5115    /// error: this function function definition is affected by the wasm ABI transition: it passes an argument of non-scalar type `MyType`
5116    /// --> $DIR/wasm_c_abi_transition.rs:17:1
5117    ///  |
5118    ///  | pub extern "C" fn my_fun(_x: MyType) {}
5119    ///  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5120    ///  |
5121    ///  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
5122    ///  = note: for more information, see issue #138762 <https://github.com/rust-lang/rust/issues/138762>
5123    ///  = help: the "C" ABI Rust uses on wasm32-unknown-unknown will change to align with the standard "C" ABI for this target
5124    /// ```
5125    ///
5126    /// ### Explanation
5127    ///
5128    /// Rust has historically implemented a non-spec-compliant C ABI on wasm32-unknown-unknown. This
5129    /// has caused incompatibilities with other compilers and Wasm targets. In a future version
5130    /// of Rust, this will be fixed, and therefore code relying on the non-spec-compliant C ABI will
5131    /// stop functioning.
5132    pub WASM_C_ABI,
5133    Warn,
5134    "detects code relying on rustc's non-spec-compliant wasm C ABI",
5135    @future_incompatible = FutureIncompatibleInfo {
5136        reason: FutureIncompatibilityReason::FutureReleaseErrorReportInDeps,
5137        reference: "issue #138762 <https://github.com/rust-lang/rust/issues/138762>",
5138    };
5139}