]> git.lizzy.rs Git - rust.git/blob - compiler/rustc_lint_defs/src/builtin.rs
Move setup_callbacks call to create_compiler_and_run
[rust.git] / compiler / rustc_lint_defs / src / 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 use crate::{declare_lint, declare_lint_pass, FutureIncompatibilityReason};
8 use rustc_span::edition::Edition;
9 use rustc_span::symbol::sym;
10
11 declare_lint! {
12     /// The `forbidden_lint_groups` lint detects violations of
13     /// `forbid` applied to a lint group. Due to a bug in the compiler,
14     /// these used to be overlooked entirely. They now generate a warning.
15     ///
16     /// ### Example
17     ///
18     /// ```rust
19     /// #![forbid(warnings)]
20     /// #![deny(bad_style)]
21     ///
22     /// fn main() {}
23     /// ```
24     ///
25     /// {{produces}}
26     ///
27     /// ### Recommended fix
28     ///
29     /// If your crate is using `#![forbid(warnings)]`,
30     /// we recommend that you change to `#![deny(warnings)]`.
31     ///
32     /// ### Explanation
33     ///
34     /// Due to a compiler bug, applying `forbid` to lint groups
35     /// previously had no effect. The bug is now fixed but instead of
36     /// enforcing `forbid` we issue this future-compatibility warning
37     /// to avoid breaking existing crates.
38     pub FORBIDDEN_LINT_GROUPS,
39     Warn,
40     "applying forbid to lint-groups",
41     @future_incompatible = FutureIncompatibleInfo {
42         reference: "issue #81670 <https://github.com/rust-lang/rust/issues/81670>",
43     };
44 }
45
46 declare_lint! {
47     /// The `ill_formed_attribute_input` lint detects ill-formed attribute
48     /// inputs that were previously accepted and used in practice.
49     ///
50     /// ### Example
51     ///
52     /// ```rust,compile_fail
53     /// #[inline = "this is not valid"]
54     /// fn foo() {}
55     /// ```
56     ///
57     /// {{produces}}
58     ///
59     /// ### Explanation
60     ///
61     /// Previously, inputs for many built-in attributes weren't validated and
62     /// nonsensical attribute inputs were accepted. After validation was
63     /// added, it was determined that some existing projects made use of these
64     /// invalid forms. This is a [future-incompatible] lint to transition this
65     /// to a hard error in the future. See [issue #57571] for more details.
66     ///
67     /// Check the [attribute reference] for details on the valid inputs for
68     /// attributes.
69     ///
70     /// [issue #57571]: https://github.com/rust-lang/rust/issues/57571
71     /// [attribute reference]: https://doc.rust-lang.org/nightly/reference/attributes.html
72     /// [future-incompatible]: ../index.md#future-incompatible-lints
73     pub ILL_FORMED_ATTRIBUTE_INPUT,
74     Deny,
75     "ill-formed attribute inputs that were previously accepted and used in practice",
76     @future_incompatible = FutureIncompatibleInfo {
77         reference: "issue #57571 <https://github.com/rust-lang/rust/issues/57571>",
78     };
79     crate_level_only
80 }
81
82 declare_lint! {
83     /// The `conflicting_repr_hints` lint detects [`repr` attributes] with
84     /// conflicting hints.
85     ///
86     /// [`repr` attributes]: https://doc.rust-lang.org/reference/type-layout.html#representations
87     ///
88     /// ### Example
89     ///
90     /// ```rust,compile_fail
91     /// #[repr(u32, u64)]
92     /// enum Foo {
93     ///     Variant1,
94     /// }
95     /// ```
96     ///
97     /// {{produces}}
98     ///
99     /// ### Explanation
100     ///
101     /// The compiler incorrectly accepted these conflicting representations in
102     /// the past. This is a [future-incompatible] lint to transition this to a
103     /// hard error in the future. See [issue #68585] for more details.
104     ///
105     /// To correct the issue, remove one of the conflicting hints.
106     ///
107     /// [issue #68585]: https://github.com/rust-lang/rust/issues/68585
108     /// [future-incompatible]: ../index.md#future-incompatible-lints
109     pub CONFLICTING_REPR_HINTS,
110     Deny,
111     "conflicts between `#[repr(..)]` hints that were previously accepted and used in practice",
112     @future_incompatible = FutureIncompatibleInfo {
113         reference: "issue #68585 <https://github.com/rust-lang/rust/issues/68585>",
114     };
115 }
116
117 declare_lint! {
118     /// The `meta_variable_misuse` lint detects possible meta-variable misuse
119     /// in macro definitions.
120     ///
121     /// ### Example
122     ///
123     /// ```rust,compile_fail
124     /// #![deny(meta_variable_misuse)]
125     ///
126     /// macro_rules! foo {
127     ///     () => {};
128     ///     ($( $i:ident = $($j:ident),+ );*) => { $( $( $i = $k; )+ )* };
129     /// }
130     ///
131     /// fn main() {
132     ///     foo!();
133     /// }
134     /// ```
135     ///
136     /// {{produces}}
137     ///
138     /// ### Explanation
139     ///
140     /// There are quite a few different ways a [`macro_rules`] macro can be
141     /// improperly defined. Many of these errors were previously only detected
142     /// when the macro was expanded or not at all. This lint is an attempt to
143     /// catch some of these problems when the macro is *defined*.
144     ///
145     /// This lint is "allow" by default because it may have false positives
146     /// and other issues. See [issue #61053] for more details.
147     ///
148     /// [`macro_rules`]: https://doc.rust-lang.org/reference/macros-by-example.html
149     /// [issue #61053]: https://github.com/rust-lang/rust/issues/61053
150     pub META_VARIABLE_MISUSE,
151     Allow,
152     "possible meta-variable misuse at macro definition"
153 }
154
155 declare_lint! {
156     /// The `incomplete_include` lint detects the use of the [`include!`]
157     /// macro with a file that contains more than one expression.
158     ///
159     /// [`include!`]: https://doc.rust-lang.org/std/macro.include.html
160     ///
161     /// ### Example
162     ///
163     /// ```rust,ignore (needs separate file)
164     /// fn main() {
165     ///     include!("foo.txt");
166     /// }
167     /// ```
168     ///
169     /// where the file `foo.txt` contains:
170     ///
171     /// ```text
172     /// println!("hi!");
173     /// ```
174     ///
175     /// produces:
176     ///
177     /// ```text
178     /// error: include macro expected single expression in source
179     ///  --> foo.txt:1:14
180     ///   |
181     /// 1 | println!("1");
182     ///   |              ^
183     ///   |
184     ///   = note: `#[deny(incomplete_include)]` on by default
185     /// ```
186     ///
187     /// ### Explanation
188     ///
189     /// The [`include!`] macro is currently only intended to be used to
190     /// include a single [expression] or multiple [items]. Historically it
191     /// would ignore any contents after the first expression, but that can be
192     /// confusing. In the example above, the `println!` expression ends just
193     /// before the semicolon, making the semicolon "extra" information that is
194     /// ignored. Perhaps even more surprising, if the included file had
195     /// multiple print statements, the subsequent ones would be ignored!
196     ///
197     /// One workaround is to place the contents in braces to create a [block
198     /// expression]. Also consider alternatives, like using functions to
199     /// encapsulate the expressions, or use [proc-macros].
200     ///
201     /// This is a lint instead of a hard error because existing projects were
202     /// found to hit this error. To be cautious, it is a lint for now. The
203     /// future semantics of the `include!` macro are also uncertain, see
204     /// [issue #35560].
205     ///
206     /// [items]: https://doc.rust-lang.org/reference/items.html
207     /// [expression]: https://doc.rust-lang.org/reference/expressions.html
208     /// [block expression]: https://doc.rust-lang.org/reference/expressions/block-expr.html
209     /// [proc-macros]: https://doc.rust-lang.org/reference/procedural-macros.html
210     /// [issue #35560]: https://github.com/rust-lang/rust/issues/35560
211     pub INCOMPLETE_INCLUDE,
212     Deny,
213     "trailing content in included file"
214 }
215
216 declare_lint! {
217     /// The `arithmetic_overflow` lint detects that an arithmetic operation
218     /// will [overflow].
219     ///
220     /// [overflow]: https://doc.rust-lang.org/reference/expressions/operator-expr.html#overflow
221     ///
222     /// ### Example
223     ///
224     /// ```rust,compile_fail
225     /// 1_i32 << 32;
226     /// ```
227     ///
228     /// {{produces}}
229     ///
230     /// ### Explanation
231     ///
232     /// It is very likely a mistake to perform an arithmetic operation that
233     /// overflows its value. If the compiler is able to detect these kinds of
234     /// overflows at compile-time, it will trigger this lint. Consider
235     /// adjusting the expression to avoid overflow, or use a data type that
236     /// will not overflow.
237     pub ARITHMETIC_OVERFLOW,
238     Deny,
239     "arithmetic operation overflows"
240 }
241
242 declare_lint! {
243     /// The `unconditional_panic` lint detects an operation that will cause a
244     /// panic at runtime.
245     ///
246     /// ### Example
247     ///
248     /// ```rust,compile_fail
249     /// # #![allow(unused)]
250     /// let x = 1 / 0;
251     /// ```
252     ///
253     /// {{produces}}
254     ///
255     /// ### Explanation
256     ///
257     /// This lint detects code that is very likely incorrect because it will
258     /// always panic, such as division by zero and out-of-bounds array
259     /// accesses. Consider adjusting your code if this is a bug, or using the
260     /// `panic!` or `unreachable!` macro instead in case the panic is intended.
261     pub UNCONDITIONAL_PANIC,
262     Deny,
263     "operation will cause a panic at runtime"
264 }
265
266 declare_lint! {
267     /// The `const_err` lint detects an erroneous expression while doing
268     /// constant evaluation.
269     ///
270     /// ### Example
271     ///
272     /// ```rust,compile_fail
273     /// #![allow(unconditional_panic)]
274     /// const C: i32 = 1/0;
275     /// ```
276     ///
277     /// {{produces}}
278     ///
279     /// ### Explanation
280     ///
281     /// This lint detects constants that fail to evaluate. Allowing the lint will accept the
282     /// constant declaration, but any use of this constant will still lead to a hard error. This is
283     /// a future incompatibility lint; the plan is to eventually entirely forbid even declaring
284     /// constants that cannot be evaluated.  See [issue #71800] for more details.
285     ///
286     /// [issue #71800]: https://github.com/rust-lang/rust/issues/71800
287     pub CONST_ERR,
288     Deny,
289     "constant evaluation encountered erroneous expression",
290     @future_incompatible = FutureIncompatibleInfo {
291         reference: "issue #71800 <https://github.com/rust-lang/rust/issues/71800>",
292     };
293     report_in_external_macro
294 }
295
296 declare_lint! {
297     /// The `unused_imports` lint detects imports that are never used.
298     ///
299     /// ### Example
300     ///
301     /// ```rust
302     /// use std::collections::HashMap;
303     /// ```
304     ///
305     /// {{produces}}
306     ///
307     /// ### Explanation
308     ///
309     /// Unused imports may signal a mistake or unfinished code, and clutter
310     /// the code, and should be removed. If you intended to re-export the item
311     /// to make it available outside of the module, add a visibility modifier
312     /// like `pub`.
313     pub UNUSED_IMPORTS,
314     Warn,
315     "imports that are never used"
316 }
317
318 declare_lint! {
319     /// The `must_not_suspend` lint guards against values that shouldn't be held across suspend points
320     /// (`.await`)
321     ///
322     /// ### Example
323     ///
324     /// ```rust
325     /// #![feature(must_not_suspend)]
326     /// #![warn(must_not_suspend)]
327     ///
328     /// #[must_not_suspend]
329     /// struct SyncThing {}
330     ///
331     /// async fn yield_now() {}
332     ///
333     /// pub async fn uhoh() {
334     ///     let guard = SyncThing {};
335     ///     yield_now().await;
336     /// }
337     /// ```
338     ///
339     /// {{produces}}
340     ///
341     /// ### Explanation
342     ///
343     /// The `must_not_suspend` lint detects values that are marked with the `#[must_not_suspend]`
344     /// attribute being held across suspend points. A "suspend" point is usually a `.await` in an async
345     /// function.
346     ///
347     /// This attribute can be used to mark values that are semantically incorrect across suspends
348     /// (like certain types of timers), values that have async alternatives, and values that
349     /// regularly cause problems with the `Send`-ness of async fn's returned futures (like
350     /// `MutexGuard`'s)
351     ///
352     pub MUST_NOT_SUSPEND,
353     Allow,
354     "use of a `#[must_not_suspend]` value across a yield point",
355     @feature_gate = rustc_span::symbol::sym::must_not_suspend;
356 }
357
358 declare_lint! {
359     /// The `unused_extern_crates` lint guards against `extern crate` items
360     /// that are never used.
361     ///
362     /// ### Example
363     ///
364     /// ```rust,compile_fail
365     /// #![deny(unused_extern_crates)]
366     /// extern crate proc_macro;
367     /// ```
368     ///
369     /// {{produces}}
370     ///
371     /// ### Explanation
372     ///
373     /// `extern crate` items that are unused have no effect and should be
374     /// removed. Note that there are some cases where specifying an `extern
375     /// crate` is desired for the side effect of ensuring the given crate is
376     /// linked, even though it is not otherwise directly referenced. The lint
377     /// can be silenced by aliasing the crate to an underscore, such as
378     /// `extern crate foo as _`. Also note that it is no longer idiomatic to
379     /// use `extern crate` in the [2018 edition], as extern crates are now
380     /// automatically added in scope.
381     ///
382     /// This lint is "allow" by default because it can be noisy, and produce
383     /// false-positives. If a dependency is being removed from a project, it
384     /// is recommended to remove it from the build configuration (such as
385     /// `Cargo.toml`) to ensure stale build entries aren't left behind.
386     ///
387     /// [2018 edition]: https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html#no-more-extern-crate
388     pub UNUSED_EXTERN_CRATES,
389     Allow,
390     "extern crates that are never used"
391 }
392
393 declare_lint! {
394     /// The `unused_crate_dependencies` lint detects crate dependencies that
395     /// are never used.
396     ///
397     /// ### Example
398     ///
399     /// ```rust,ignore (needs extern crate)
400     /// #![deny(unused_crate_dependencies)]
401     /// ```
402     ///
403     /// This will produce:
404     ///
405     /// ```text
406     /// error: external crate `regex` unused in `lint_example`: remove the dependency or add `use regex as _;`
407     ///   |
408     /// note: the lint level is defined here
409     ///  --> src/lib.rs:1:9
410     ///   |
411     /// 1 | #![deny(unused_crate_dependencies)]
412     ///   |         ^^^^^^^^^^^^^^^^^^^^^^^^^
413     /// ```
414     ///
415     /// ### Explanation
416     ///
417     /// After removing the code that uses a dependency, this usually also
418     /// requires removing the dependency from the build configuration.
419     /// However, sometimes that step can be missed, which leads to time wasted
420     /// building dependencies that are no longer used. This lint can be
421     /// enabled to detect dependencies that are never used (more specifically,
422     /// any dependency passed with the `--extern` command-line flag that is
423     /// never referenced via [`use`], [`extern crate`], or in any [path]).
424     ///
425     /// This lint is "allow" by default because it can provide false positives
426     /// depending on how the build system is configured. For example, when
427     /// using Cargo, a "package" consists of multiple crates (such as a
428     /// library and a binary), but the dependencies are defined for the
429     /// package as a whole. If there is a dependency that is only used in the
430     /// binary, but not the library, then the lint will be incorrectly issued
431     /// in the library.
432     ///
433     /// [path]: https://doc.rust-lang.org/reference/paths.html
434     /// [`use`]: https://doc.rust-lang.org/reference/items/use-declarations.html
435     /// [`extern crate`]: https://doc.rust-lang.org/reference/items/extern-crates.html
436     pub UNUSED_CRATE_DEPENDENCIES,
437     Allow,
438     "crate dependencies that are never used",
439     crate_level_only
440 }
441
442 declare_lint! {
443     /// The `unused_qualifications` lint detects unnecessarily qualified
444     /// names.
445     ///
446     /// ### Example
447     ///
448     /// ```rust,compile_fail
449     /// #![deny(unused_qualifications)]
450     /// mod foo {
451     ///     pub fn bar() {}
452     /// }
453     ///
454     /// fn main() {
455     ///     use foo::bar;
456     ///     foo::bar();
457     /// }
458     /// ```
459     ///
460     /// {{produces}}
461     ///
462     /// ### Explanation
463     ///
464     /// If an item from another module is already brought into scope, then
465     /// there is no need to qualify it in this case. You can call `bar()`
466     /// directly, without the `foo::`.
467     ///
468     /// This lint is "allow" by default because it is somewhat pedantic, and
469     /// doesn't indicate an actual problem, but rather a stylistic choice, and
470     /// can be noisy when refactoring or moving around code.
471     pub UNUSED_QUALIFICATIONS,
472     Allow,
473     "detects unnecessarily qualified names"
474 }
475
476 declare_lint! {
477     /// The `unknown_lints` lint detects unrecognized lint attribute.
478     ///
479     /// ### Example
480     ///
481     /// ```rust
482     /// #![allow(not_a_real_lint)]
483     /// ```
484     ///
485     /// {{produces}}
486     ///
487     /// ### Explanation
488     ///
489     /// It is usually a mistake to specify a lint that does not exist. Check
490     /// the spelling, and check the lint listing for the correct name. Also
491     /// consider if you are using an old version of the compiler, and the lint
492     /// is only available in a newer version.
493     pub UNKNOWN_LINTS,
494     Warn,
495     "unrecognized lint attribute"
496 }
497
498 declare_lint! {
499     /// The `unused_variables` lint detects variables which are not used in
500     /// any way.
501     ///
502     /// ### Example
503     ///
504     /// ```rust
505     /// let x = 5;
506     /// ```
507     ///
508     /// {{produces}}
509     ///
510     /// ### Explanation
511     ///
512     /// Unused variables may signal a mistake or unfinished code. To silence
513     /// the warning for the individual variable, prefix it with an underscore
514     /// such as `_x`.
515     pub UNUSED_VARIABLES,
516     Warn,
517     "detect variables which are not used in any way"
518 }
519
520 declare_lint! {
521     /// The `unused_assignments` lint detects assignments that will never be read.
522     ///
523     /// ### Example
524     ///
525     /// ```rust
526     /// let mut x = 5;
527     /// x = 6;
528     /// ```
529     ///
530     /// {{produces}}
531     ///
532     /// ### Explanation
533     ///
534     /// Unused assignments may signal a mistake or unfinished code. If the
535     /// variable is never used after being assigned, then the assignment can
536     /// be removed. Variables with an underscore prefix such as `_x` will not
537     /// trigger this lint.
538     pub UNUSED_ASSIGNMENTS,
539     Warn,
540     "detect assignments that will never be read"
541 }
542
543 declare_lint! {
544     /// The `dead_code` lint detects unused, unexported items.
545     ///
546     /// ### Example
547     ///
548     /// ```rust
549     /// fn foo() {}
550     /// ```
551     ///
552     /// {{produces}}
553     ///
554     /// ### Explanation
555     ///
556     /// Dead code may signal a mistake or unfinished code. To silence the
557     /// warning for individual items, prefix the name with an underscore such
558     /// as `_foo`. If it was intended to expose the item outside of the crate,
559     /// consider adding a visibility modifier like `pub`. Otherwise consider
560     /// removing the unused code.
561     pub DEAD_CODE,
562     Warn,
563     "detect unused, unexported items"
564 }
565
566 declare_lint! {
567     /// The `unused_attributes` lint detects attributes that were not used by
568     /// the compiler.
569     ///
570     /// ### Example
571     ///
572     /// ```rust
573     /// #![ignore]
574     /// ```
575     ///
576     /// {{produces}}
577     ///
578     /// ### Explanation
579     ///
580     /// Unused [attributes] may indicate the attribute is placed in the wrong
581     /// position. Consider removing it, or placing it in the correct position.
582     /// Also consider if you intended to use an _inner attribute_ (with a `!`
583     /// such as `#![allow(unused)]`) which applies to the item the attribute
584     /// is within, or an _outer attribute_ (without a `!` such as
585     /// `#[allow(unused)]`) which applies to the item *following* the
586     /// attribute.
587     ///
588     /// [attributes]: https://doc.rust-lang.org/reference/attributes.html
589     pub UNUSED_ATTRIBUTES,
590     Warn,
591     "detects attributes that were not used by the compiler"
592 }
593
594 declare_lint! {
595     /// The `unreachable_code` lint detects unreachable code paths.
596     ///
597     /// ### Example
598     ///
599     /// ```rust,no_run
600     /// panic!("we never go past here!");
601     ///
602     /// let x = 5;
603     /// ```
604     ///
605     /// {{produces}}
606     ///
607     /// ### Explanation
608     ///
609     /// Unreachable code may signal a mistake or unfinished code. If the code
610     /// is no longer in use, consider removing it.
611     pub UNREACHABLE_CODE,
612     Warn,
613     "detects unreachable code paths",
614     report_in_external_macro
615 }
616
617 declare_lint! {
618     /// The `unreachable_patterns` lint detects unreachable patterns.
619     ///
620     /// ### Example
621     ///
622     /// ```rust
623     /// let x = 5;
624     /// match x {
625     ///     y => (),
626     ///     5 => (),
627     /// }
628     /// ```
629     ///
630     /// {{produces}}
631     ///
632     /// ### Explanation
633     ///
634     /// This usually indicates a mistake in how the patterns are specified or
635     /// ordered. In this example, the `y` pattern will always match, so the
636     /// five is impossible to reach. Remember, match arms match in order, you
637     /// probably wanted to put the `5` case above the `y` case.
638     pub UNREACHABLE_PATTERNS,
639     Warn,
640     "detects unreachable patterns"
641 }
642
643 declare_lint! {
644     /// The `overlapping_range_endpoints` lint detects `match` arms that have [range patterns] that
645     /// overlap on their endpoints.
646     ///
647     /// [range patterns]: https://doc.rust-lang.org/nightly/reference/patterns.html#range-patterns
648     ///
649     /// ### Example
650     ///
651     /// ```rust
652     /// let x = 123u8;
653     /// match x {
654     ///     0..=100 => { println!("small"); }
655     ///     100..=255 => { println!("large"); }
656     /// }
657     /// ```
658     ///
659     /// {{produces}}
660     ///
661     /// ### Explanation
662     ///
663     /// It is likely a mistake to have range patterns in a match expression that overlap in this
664     /// way. Check that the beginning and end values are what you expect, and keep in mind that
665     /// with `..=` the left and right bounds are inclusive.
666     pub OVERLAPPING_RANGE_ENDPOINTS,
667     Warn,
668     "detects range patterns with overlapping endpoints"
669 }
670
671 declare_lint! {
672     /// The `bindings_with_variant_name` lint detects pattern bindings with
673     /// the same name as one of the matched variants.
674     ///
675     /// ### Example
676     ///
677     /// ```rust
678     /// pub enum Enum {
679     ///     Foo,
680     ///     Bar,
681     /// }
682     ///
683     /// pub fn foo(x: Enum) {
684     ///     match x {
685     ///         Foo => {}
686     ///         Bar => {}
687     ///     }
688     /// }
689     /// ```
690     ///
691     /// {{produces}}
692     ///
693     /// ### Explanation
694     ///
695     /// It is usually a mistake to specify an enum variant name as an
696     /// [identifier pattern]. In the example above, the `match` arms are
697     /// specifying a variable name to bind the value of `x` to. The second arm
698     /// is ignored because the first one matches *all* values. The likely
699     /// intent is that the arm was intended to match on the enum variant.
700     ///
701     /// Two possible solutions are:
702     ///
703     /// * Specify the enum variant using a [path pattern], such as
704     ///   `Enum::Foo`.
705     /// * Bring the enum variants into local scope, such as adding `use
706     ///   Enum::*;` to the beginning of the `foo` function in the example
707     ///   above.
708     ///
709     /// [identifier pattern]: https://doc.rust-lang.org/reference/patterns.html#identifier-patterns
710     /// [path pattern]: https://doc.rust-lang.org/reference/patterns.html#path-patterns
711     pub BINDINGS_WITH_VARIANT_NAME,
712     Warn,
713     "detects pattern bindings with the same name as one of the matched variants"
714 }
715
716 declare_lint! {
717     /// The `unused_macros` lint detects macros that were not used.
718     ///
719     /// ### Example
720     ///
721     /// ```rust
722     /// macro_rules! unused {
723     ///     () => {};
724     /// }
725     ///
726     /// fn main() {
727     /// }
728     /// ```
729     ///
730     /// {{produces}}
731     ///
732     /// ### Explanation
733     ///
734     /// Unused macros may signal a mistake or unfinished code. To silence the
735     /// warning for the individual macro, prefix the name with an underscore
736     /// such as `_my_macro`. If you intended to export the macro to make it
737     /// available outside of the crate, use the [`macro_export` attribute].
738     ///
739     /// [`macro_export` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
740     pub UNUSED_MACROS,
741     Warn,
742     "detects macros that were not used"
743 }
744
745 declare_lint! {
746     /// The `warnings` lint allows you to change the level of other
747     /// lints which produce warnings.
748     ///
749     /// ### Example
750     ///
751     /// ```rust
752     /// #![deny(warnings)]
753     /// fn foo() {}
754     /// ```
755     ///
756     /// {{produces}}
757     ///
758     /// ### Explanation
759     ///
760     /// The `warnings` lint is a bit special; by changing its level, you
761     /// change every other warning that would produce a warning to whatever
762     /// value you'd like. As such, you won't ever trigger this lint in your
763     /// code directly.
764     pub WARNINGS,
765     Warn,
766     "mass-change the level for lints which produce warnings"
767 }
768
769 declare_lint! {
770     /// The `unused_features` lint detects unused or unknown features found in
771     /// crate-level [`feature` attributes].
772     ///
773     /// [`feature` attributes]: https://doc.rust-lang.org/nightly/unstable-book/
774     ///
775     /// Note: This lint is currently not functional, see [issue #44232] for
776     /// more details.
777     ///
778     /// [issue #44232]: https://github.com/rust-lang/rust/issues/44232
779     pub UNUSED_FEATURES,
780     Warn,
781     "unused features found in crate-level `#[feature]` directives"
782 }
783
784 declare_lint! {
785     /// The `stable_features` lint detects a [`feature` attribute] that
786     /// has since been made stable.
787     ///
788     /// [`feature` attribute]: https://doc.rust-lang.org/nightly/unstable-book/
789     ///
790     /// ### Example
791     ///
792     /// ```rust
793     /// #![feature(test_accepted_feature)]
794     /// fn main() {}
795     /// ```
796     ///
797     /// {{produces}}
798     ///
799     /// ### Explanation
800     ///
801     /// When a feature is stabilized, it is no longer necessary to include a
802     /// `#![feature]` attribute for it. To fix, simply remove the
803     /// `#![feature]` attribute.
804     pub STABLE_FEATURES,
805     Warn,
806     "stable features found in `#[feature]` directive"
807 }
808
809 declare_lint! {
810     /// The `unknown_crate_types` lint detects an unknown crate type found in
811     /// a [`crate_type` attribute].
812     ///
813     /// ### Example
814     ///
815     /// ```rust,compile_fail
816     /// #![crate_type="lol"]
817     /// fn main() {}
818     /// ```
819     ///
820     /// {{produces}}
821     ///
822     /// ### Explanation
823     ///
824     /// An unknown value give to the `crate_type` attribute is almost
825     /// certainly a mistake.
826     ///
827     /// [`crate_type` attribute]: https://doc.rust-lang.org/reference/linkage.html
828     pub UNKNOWN_CRATE_TYPES,
829     Deny,
830     "unknown crate type found in `#[crate_type]` directive",
831     crate_level_only
832 }
833
834 declare_lint! {
835     /// The `trivial_casts` lint detects trivial casts which could be replaced
836     /// with coercion, which may require [type ascription] or a temporary
837     /// variable.
838     ///
839     /// ### Example
840     ///
841     /// ```rust,compile_fail
842     /// #![deny(trivial_casts)]
843     /// let x: &u32 = &42;
844     /// let y = x as *const u32;
845     /// ```
846     ///
847     /// {{produces}}
848     ///
849     /// ### Explanation
850     ///
851     /// A trivial cast is a cast `e as T` where `e` has type `U` and `U` is a
852     /// subtype of `T`. This type of cast is usually unnecessary, as it can be
853     /// usually be inferred.
854     ///
855     /// This lint is "allow" by default because there are situations, such as
856     /// with FFI interfaces or complex type aliases, where it triggers
857     /// incorrectly, or in situations where it will be more difficult to
858     /// clearly express the intent. It may be possible that this will become a
859     /// warning in the future, possibly with [type ascription] providing a
860     /// convenient way to work around the current issues. See [RFC 401] for
861     /// historical context.
862     ///
863     /// [type ascription]: https://github.com/rust-lang/rust/issues/23416
864     /// [RFC 401]: https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md
865     pub TRIVIAL_CASTS,
866     Allow,
867     "detects trivial casts which could be removed"
868 }
869
870 declare_lint! {
871     /// The `trivial_numeric_casts` lint detects trivial numeric casts of types
872     /// which could be removed.
873     ///
874     /// ### Example
875     ///
876     /// ```rust,compile_fail
877     /// #![deny(trivial_numeric_casts)]
878     /// let x = 42_i32 as i32;
879     /// ```
880     ///
881     /// {{produces}}
882     ///
883     /// ### Explanation
884     ///
885     /// A trivial numeric cast is a cast of a numeric type to the same numeric
886     /// type. This type of cast is usually unnecessary.
887     ///
888     /// This lint is "allow" by default because there are situations, such as
889     /// with FFI interfaces or complex type aliases, where it triggers
890     /// incorrectly, or in situations where it will be more difficult to
891     /// clearly express the intent. It may be possible that this will become a
892     /// warning in the future, possibly with [type ascription] providing a
893     /// convenient way to work around the current issues. See [RFC 401] for
894     /// historical context.
895     ///
896     /// [type ascription]: https://github.com/rust-lang/rust/issues/23416
897     /// [RFC 401]: https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md
898     pub TRIVIAL_NUMERIC_CASTS,
899     Allow,
900     "detects trivial casts of numeric types which could be removed"
901 }
902
903 declare_lint! {
904     /// The `private_in_public` lint detects private items in public
905     /// interfaces not caught by the old implementation.
906     ///
907     /// ### Example
908     ///
909     /// ```rust
910     /// # #![allow(unused)]
911     /// struct SemiPriv;
912     ///
913     /// mod m1 {
914     ///     struct Priv;
915     ///     impl super::SemiPriv {
916     ///         pub fn f(_: Priv) {}
917     ///     }
918     /// }
919     /// # fn main() {}
920     /// ```
921     ///
922     /// {{produces}}
923     ///
924     /// ### Explanation
925     ///
926     /// The visibility rules are intended to prevent exposing private items in
927     /// public interfaces. This is a [future-incompatible] lint to transition
928     /// this to a hard error in the future. See [issue #34537] for more
929     /// details.
930     ///
931     /// [issue #34537]: https://github.com/rust-lang/rust/issues/34537
932     /// [future-incompatible]: ../index.md#future-incompatible-lints
933     pub PRIVATE_IN_PUBLIC,
934     Warn,
935     "detect private items in public interfaces not caught by the old implementation",
936     @future_incompatible = FutureIncompatibleInfo {
937         reference: "issue #34537 <https://github.com/rust-lang/rust/issues/34537>",
938     };
939 }
940
941 declare_lint! {
942     /// The `exported_private_dependencies` lint detects private dependencies
943     /// that are exposed in a public interface.
944     ///
945     /// ### Example
946     ///
947     /// ```rust,ignore (needs-dependency)
948     /// pub fn foo() -> Option<some_private_dependency::Thing> {
949     ///     None
950     /// }
951     /// ```
952     ///
953     /// This will produce:
954     ///
955     /// ```text
956     /// warning: type `bar::Thing` from private dependency 'bar' in public interface
957     ///  --> src/lib.rs:3:1
958     ///   |
959     /// 3 | pub fn foo() -> Option<bar::Thing> {
960     ///   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
961     ///   |
962     ///   = note: `#[warn(exported_private_dependencies)]` on by default
963     /// ```
964     ///
965     /// ### Explanation
966     ///
967     /// Dependencies can be marked as "private" to indicate that they are not
968     /// exposed in the public interface of a crate. This can be used by Cargo
969     /// to independently resolve those dependencies because it can assume it
970     /// does not need to unify them with other packages using that same
971     /// dependency. This lint is an indication of a violation of that
972     /// contract.
973     ///
974     /// To fix this, avoid exposing the dependency in your public interface.
975     /// Or, switch the dependency to a public dependency.
976     ///
977     /// Note that support for this is only available on the nightly channel.
978     /// See [RFC 1977] for more details, as well as the [Cargo documentation].
979     ///
980     /// [RFC 1977]: https://github.com/rust-lang/rfcs/blob/master/text/1977-public-private-dependencies.md
981     /// [Cargo documentation]: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#public-dependency
982     pub EXPORTED_PRIVATE_DEPENDENCIES,
983     Warn,
984     "public interface leaks type from a private dependency"
985 }
986
987 declare_lint! {
988     /// The `pub_use_of_private_extern_crate` lint detects a specific
989     /// situation of re-exporting a private `extern crate`.
990     ///
991     /// ### Example
992     ///
993     /// ```rust,compile_fail
994     /// extern crate core;
995     /// pub use core as reexported_core;
996     /// ```
997     ///
998     /// {{produces}}
999     ///
1000     /// ### Explanation
1001     ///
1002     /// A public `use` declaration should not be used to publicly re-export a
1003     /// private `extern crate`. `pub extern crate` should be used instead.
1004     ///
1005     /// This was historically allowed, but is not the intended behavior
1006     /// according to the visibility rules. This is a [future-incompatible]
1007     /// lint to transition this to a hard error in the future. See [issue
1008     /// #34537] for more details.
1009     ///
1010     /// [issue #34537]: https://github.com/rust-lang/rust/issues/34537
1011     /// [future-incompatible]: ../index.md#future-incompatible-lints
1012     pub PUB_USE_OF_PRIVATE_EXTERN_CRATE,
1013     Deny,
1014     "detect public re-exports of private extern crates",
1015     @future_incompatible = FutureIncompatibleInfo {
1016         reference: "issue #34537 <https://github.com/rust-lang/rust/issues/34537>",
1017     };
1018 }
1019
1020 declare_lint! {
1021     /// The `invalid_type_param_default` lint detects type parameter defaults
1022     /// erroneously allowed in an invalid location.
1023     ///
1024     /// ### Example
1025     ///
1026     /// ```rust,compile_fail
1027     /// fn foo<T=i32>(t: T) {}
1028     /// ```
1029     ///
1030     /// {{produces}}
1031     ///
1032     /// ### Explanation
1033     ///
1034     /// Default type parameters were only intended to be allowed in certain
1035     /// situations, but historically the compiler allowed them everywhere.
1036     /// This is a [future-incompatible] lint to transition this to a hard
1037     /// error in the future. See [issue #36887] for more details.
1038     ///
1039     /// [issue #36887]: https://github.com/rust-lang/rust/issues/36887
1040     /// [future-incompatible]: ../index.md#future-incompatible-lints
1041     pub INVALID_TYPE_PARAM_DEFAULT,
1042     Deny,
1043     "type parameter default erroneously allowed in invalid location",
1044     @future_incompatible = FutureIncompatibleInfo {
1045         reference: "issue #36887 <https://github.com/rust-lang/rust/issues/36887>",
1046     };
1047 }
1048
1049 declare_lint! {
1050     /// The `renamed_and_removed_lints` lint detects lints that have been
1051     /// renamed or removed.
1052     ///
1053     /// ### Example
1054     ///
1055     /// ```rust
1056     /// #![deny(raw_pointer_derive)]
1057     /// ```
1058     ///
1059     /// {{produces}}
1060     ///
1061     /// ### Explanation
1062     ///
1063     /// To fix this, either remove the lint or use the new name. This can help
1064     /// avoid confusion about lints that are no longer valid, and help
1065     /// maintain consistency for renamed lints.
1066     pub RENAMED_AND_REMOVED_LINTS,
1067     Warn,
1068     "lints that have been renamed or removed"
1069 }
1070
1071 declare_lint! {
1072     /// The `unaligned_references` lint detects unaligned references to fields
1073     /// of [packed] structs.
1074     ///
1075     /// [packed]: https://doc.rust-lang.org/reference/type-layout.html#the-alignment-modifiers
1076     ///
1077     /// ### Example
1078     ///
1079     /// ```rust,compile_fail
1080     /// #![deny(unaligned_references)]
1081     ///
1082     /// #[repr(packed)]
1083     /// pub struct Foo {
1084     ///     field1: u64,
1085     ///     field2: u8,
1086     /// }
1087     ///
1088     /// fn main() {
1089     ///     unsafe {
1090     ///         let foo = Foo { field1: 0, field2: 0 };
1091     ///         let _ = &foo.field1;
1092     ///         println!("{}", foo.field1); // An implicit `&` is added here, triggering the lint.
1093     ///     }
1094     /// }
1095     /// ```
1096     ///
1097     /// {{produces}}
1098     ///
1099     /// ### Explanation
1100     ///
1101     /// Creating a reference to an insufficiently aligned packed field is [undefined behavior] and
1102     /// should be disallowed. Using an `unsafe` block does not change anything about this. Instead,
1103     /// the code should do a copy of the data in the packed field or use raw pointers and unaligned
1104     /// accesses. See [issue #82523] for more information.
1105     ///
1106     /// [undefined behavior]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html
1107     /// [issue #82523]: https://github.com/rust-lang/rust/issues/82523
1108     pub UNALIGNED_REFERENCES,
1109     Warn,
1110     "detects unaligned references to fields of packed structs",
1111     @future_incompatible = FutureIncompatibleInfo {
1112         reference: "issue #82523 <https://github.com/rust-lang/rust/issues/82523>",
1113     };
1114     report_in_external_macro
1115 }
1116
1117 declare_lint! {
1118     /// The `const_item_mutation` lint detects attempts to mutate a `const`
1119     /// item.
1120     ///
1121     /// ### Example
1122     ///
1123     /// ```rust
1124     /// const FOO: [i32; 1] = [0];
1125     ///
1126     /// fn main() {
1127     ///     FOO[0] = 1;
1128     ///     // This will print "[0]".
1129     ///     println!("{:?}", FOO);
1130     /// }
1131     /// ```
1132     ///
1133     /// {{produces}}
1134     ///
1135     /// ### Explanation
1136     ///
1137     /// Trying to directly mutate a `const` item is almost always a mistake.
1138     /// What is happening in the example above is that a temporary copy of the
1139     /// `const` is mutated, but the original `const` is not. Each time you
1140     /// refer to the `const` by name (such as `FOO` in the example above), a
1141     /// separate copy of the value is inlined at that location.
1142     ///
1143     /// This lint checks for writing directly to a field (`FOO.field =
1144     /// some_value`) or array entry (`FOO[0] = val`), or taking a mutable
1145     /// reference to the const item (`&mut FOO`), including through an
1146     /// autoderef (`FOO.some_mut_self_method()`).
1147     ///
1148     /// There are various alternatives depending on what you are trying to
1149     /// accomplish:
1150     ///
1151     /// * First, always reconsider using mutable globals, as they can be
1152     ///   difficult to use correctly, and can make the code more difficult to
1153     ///   use or understand.
1154     /// * If you are trying to perform a one-time initialization of a global:
1155     ///     * If the value can be computed at compile-time, consider using
1156     ///       const-compatible values (see [Constant Evaluation]).
1157     ///     * For more complex single-initialization cases, consider using a
1158     ///       third-party crate, such as [`lazy_static`] or [`once_cell`].
1159     ///     * If you are using the [nightly channel], consider the new
1160     ///       [`lazy`] module in the standard library.
1161     /// * If you truly need a mutable global, consider using a [`static`],
1162     ///   which has a variety of options:
1163     ///   * Simple data types can be directly defined and mutated with an
1164     ///     [`atomic`] type.
1165     ///   * More complex types can be placed in a synchronization primitive
1166     ///     like a [`Mutex`], which can be initialized with one of the options
1167     ///     listed above.
1168     ///   * A [mutable `static`] is a low-level primitive, requiring unsafe.
1169     ///     Typically This should be avoided in preference of something
1170     ///     higher-level like one of the above.
1171     ///
1172     /// [Constant Evaluation]: https://doc.rust-lang.org/reference/const_eval.html
1173     /// [`static`]: https://doc.rust-lang.org/reference/items/static-items.html
1174     /// [mutable `static`]: https://doc.rust-lang.org/reference/items/static-items.html#mutable-statics
1175     /// [`lazy`]: https://doc.rust-lang.org/nightly/std/lazy/index.html
1176     /// [`lazy_static`]: https://crates.io/crates/lazy_static
1177     /// [`once_cell`]: https://crates.io/crates/once_cell
1178     /// [`atomic`]: https://doc.rust-lang.org/std/sync/atomic/index.html
1179     /// [`Mutex`]: https://doc.rust-lang.org/std/sync/struct.Mutex.html
1180     pub CONST_ITEM_MUTATION,
1181     Warn,
1182     "detects attempts to mutate a `const` item",
1183 }
1184
1185 declare_lint! {
1186     /// The `patterns_in_fns_without_body` lint detects `mut` identifier
1187     /// patterns as a parameter in functions without a body.
1188     ///
1189     /// ### Example
1190     ///
1191     /// ```rust,compile_fail
1192     /// trait Trait {
1193     ///     fn foo(mut arg: u8);
1194     /// }
1195     /// ```
1196     ///
1197     /// {{produces}}
1198     ///
1199     /// ### Explanation
1200     ///
1201     /// To fix this, remove `mut` from the parameter in the trait definition;
1202     /// it can be used in the implementation. That is, the following is OK:
1203     ///
1204     /// ```rust
1205     /// trait Trait {
1206     ///     fn foo(arg: u8); // Removed `mut` here
1207     /// }
1208     ///
1209     /// impl Trait for i32 {
1210     ///     fn foo(mut arg: u8) { // `mut` here is OK
1211     ///
1212     ///     }
1213     /// }
1214     /// ```
1215     ///
1216     /// Trait definitions can define functions without a body to specify a
1217     /// function that implementors must define. The parameter names in the
1218     /// body-less functions are only allowed to be `_` or an [identifier] for
1219     /// documentation purposes (only the type is relevant). Previous versions
1220     /// of the compiler erroneously allowed [identifier patterns] with the
1221     /// `mut` keyword, but this was not intended to be allowed. This is a
1222     /// [future-incompatible] lint to transition this to a hard error in the
1223     /// future. See [issue #35203] for more details.
1224     ///
1225     /// [identifier]: https://doc.rust-lang.org/reference/identifiers.html
1226     /// [identifier patterns]: https://doc.rust-lang.org/reference/patterns.html#identifier-patterns
1227     /// [issue #35203]: https://github.com/rust-lang/rust/issues/35203
1228     /// [future-incompatible]: ../index.md#future-incompatible-lints
1229     pub PATTERNS_IN_FNS_WITHOUT_BODY,
1230     Deny,
1231     "patterns in functions without body were erroneously allowed",
1232     @future_incompatible = FutureIncompatibleInfo {
1233         reference: "issue #35203 <https://github.com/rust-lang/rust/issues/35203>",
1234     };
1235 }
1236
1237 declare_lint! {
1238     /// The `missing_fragment_specifier` lint is issued when an unused pattern in a
1239     /// `macro_rules!` macro definition has a meta-variable (e.g. `$e`) that is not
1240     /// followed by a fragment specifier (e.g. `:expr`).
1241     ///
1242     /// This warning can always be fixed by removing the unused pattern in the
1243     /// `macro_rules!` macro definition.
1244     ///
1245     /// ### Example
1246     ///
1247     /// ```rust,compile_fail
1248     /// macro_rules! foo {
1249     ///    () => {};
1250     ///    ($name) => { };
1251     /// }
1252     ///
1253     /// fn main() {
1254     ///    foo!();
1255     /// }
1256     /// ```
1257     ///
1258     /// {{produces}}
1259     ///
1260     /// ### Explanation
1261     ///
1262     /// To fix this, remove the unused pattern from the `macro_rules!` macro definition:
1263     ///
1264     /// ```rust
1265     /// macro_rules! foo {
1266     ///     () => {};
1267     /// }
1268     /// fn main() {
1269     ///     foo!();
1270     /// }
1271     /// ```
1272     pub MISSING_FRAGMENT_SPECIFIER,
1273     Deny,
1274     "detects missing fragment specifiers in unused `macro_rules!` patterns",
1275     @future_incompatible = FutureIncompatibleInfo {
1276         reference: "issue #40107 <https://github.com/rust-lang/rust/issues/40107>",
1277     };
1278 }
1279
1280 declare_lint! {
1281     /// The `late_bound_lifetime_arguments` lint detects generic lifetime
1282     /// arguments in path segments with late bound lifetime parameters.
1283     ///
1284     /// ### Example
1285     ///
1286     /// ```rust
1287     /// struct S;
1288     ///
1289     /// impl S {
1290     ///     fn late<'a, 'b>(self, _: &'a u8, _: &'b u8) {}
1291     /// }
1292     ///
1293     /// fn main() {
1294     ///     S.late::<'static>(&0, &0);
1295     /// }
1296     /// ```
1297     ///
1298     /// {{produces}}
1299     ///
1300     /// ### Explanation
1301     ///
1302     /// It is not clear how to provide arguments for early-bound lifetime
1303     /// parameters if they are intermixed with late-bound parameters in the
1304     /// same list. For now, providing any explicit arguments will trigger this
1305     /// lint if late-bound parameters are present, so in the future a solution
1306     /// can be adopted without hitting backward compatibility issues. This is
1307     /// a [future-incompatible] lint to transition this to a hard error in the
1308     /// future. See [issue #42868] for more details, along with a description
1309     /// of the difference between early and late-bound parameters.
1310     ///
1311     /// [issue #42868]: https://github.com/rust-lang/rust/issues/42868
1312     /// [future-incompatible]: ../index.md#future-incompatible-lints
1313     pub LATE_BOUND_LIFETIME_ARGUMENTS,
1314     Warn,
1315     "detects generic lifetime arguments in path segments with late bound lifetime parameters",
1316     @future_incompatible = FutureIncompatibleInfo {
1317         reference: "issue #42868 <https://github.com/rust-lang/rust/issues/42868>",
1318     };
1319 }
1320
1321 declare_lint! {
1322     /// The `order_dependent_trait_objects` lint detects a trait coherency
1323     /// violation that would allow creating two trait impls for the same
1324     /// dynamic trait object involving marker traits.
1325     ///
1326     /// ### Example
1327     ///
1328     /// ```rust,compile_fail
1329     /// pub trait Trait {}
1330     ///
1331     /// impl Trait for dyn Send + Sync { }
1332     /// impl Trait for dyn Sync + Send { }
1333     /// ```
1334     ///
1335     /// {{produces}}
1336     ///
1337     /// ### Explanation
1338     ///
1339     /// A previous bug caused the compiler to interpret traits with different
1340     /// orders (such as `Send + Sync` and `Sync + Send`) as distinct types
1341     /// when they were intended to be treated the same. This allowed code to
1342     /// define separate trait implementations when there should be a coherence
1343     /// error. This is a [future-incompatible] lint to transition this to a
1344     /// hard error in the future. See [issue #56484] for more details.
1345     ///
1346     /// [issue #56484]: https://github.com/rust-lang/rust/issues/56484
1347     /// [future-incompatible]: ../index.md#future-incompatible-lints
1348     pub ORDER_DEPENDENT_TRAIT_OBJECTS,
1349     Deny,
1350     "trait-object types were treated as different depending on marker-trait order",
1351     @future_incompatible = FutureIncompatibleInfo {
1352         reference: "issue #56484 <https://github.com/rust-lang/rust/issues/56484>",
1353     };
1354 }
1355
1356 declare_lint! {
1357     /// The `coherence_leak_check` lint detects conflicting implementations of
1358     /// a trait that are only distinguished by the old leak-check code.
1359     ///
1360     /// ### Example
1361     ///
1362     /// ```rust
1363     /// trait SomeTrait { }
1364     /// impl SomeTrait for for<'a> fn(&'a u8) { }
1365     /// impl<'a> SomeTrait for fn(&'a u8) { }
1366     /// ```
1367     ///
1368     /// {{produces}}
1369     ///
1370     /// ### Explanation
1371     ///
1372     /// In the past, the compiler would accept trait implementations for
1373     /// identical functions that differed only in where the lifetime binder
1374     /// appeared. Due to a change in the borrow checker implementation to fix
1375     /// several bugs, this is no longer allowed. However, since this affects
1376     /// existing code, this is a [future-incompatible] lint to transition this
1377     /// to a hard error in the future.
1378     ///
1379     /// Code relying on this pattern should introduce "[newtypes]",
1380     /// like `struct Foo(for<'a> fn(&'a u8))`.
1381     ///
1382     /// See [issue #56105] for more details.
1383     ///
1384     /// [issue #56105]: https://github.com/rust-lang/rust/issues/56105
1385     /// [newtypes]: https://doc.rust-lang.org/book/ch19-04-advanced-types.html#using-the-newtype-pattern-for-type-safety-and-abstraction
1386     /// [future-incompatible]: ../index.md#future-incompatible-lints
1387     pub COHERENCE_LEAK_CHECK,
1388     Warn,
1389     "distinct impls distinguished only by the leak-check code",
1390     @future_incompatible = FutureIncompatibleInfo {
1391         reference: "issue #56105 <https://github.com/rust-lang/rust/issues/56105>",
1392     };
1393 }
1394
1395 declare_lint! {
1396     /// The `deprecated` lint detects use of deprecated items.
1397     ///
1398     /// ### Example
1399     ///
1400     /// ```rust
1401     /// #[deprecated]
1402     /// fn foo() {}
1403     ///
1404     /// fn bar() {
1405     ///     foo();
1406     /// }
1407     /// ```
1408     ///
1409     /// {{produces}}
1410     ///
1411     /// ### Explanation
1412     ///
1413     /// Items may be marked "deprecated" with the [`deprecated` attribute] to
1414     /// indicate that they should no longer be used. Usually the attribute
1415     /// should include a note on what to use instead, or check the
1416     /// documentation.
1417     ///
1418     /// [`deprecated` attribute]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute
1419     pub DEPRECATED,
1420     Warn,
1421     "detects use of deprecated items",
1422     report_in_external_macro
1423 }
1424
1425 declare_lint! {
1426     /// The `unused_unsafe` lint detects unnecessary use of an `unsafe` block.
1427     ///
1428     /// ### Example
1429     ///
1430     /// ```rust
1431     /// unsafe {}
1432     /// ```
1433     ///
1434     /// {{produces}}
1435     ///
1436     /// ### Explanation
1437     ///
1438     /// If nothing within the block requires `unsafe`, then remove the
1439     /// `unsafe` marker because it is not required and may cause confusion.
1440     pub UNUSED_UNSAFE,
1441     Warn,
1442     "unnecessary use of an `unsafe` block"
1443 }
1444
1445 declare_lint! {
1446     /// The `unused_mut` lint detects mut variables which don't need to be
1447     /// mutable.
1448     ///
1449     /// ### Example
1450     ///
1451     /// ```rust
1452     /// let mut x = 5;
1453     /// ```
1454     ///
1455     /// {{produces}}
1456     ///
1457     /// ### Explanation
1458     ///
1459     /// The preferred style is to only mark variables as `mut` if it is
1460     /// required.
1461     pub UNUSED_MUT,
1462     Warn,
1463     "detect mut variables which don't need to be mutable"
1464 }
1465
1466 declare_lint! {
1467     /// The `unconditional_recursion` lint detects functions that cannot
1468     /// return without calling themselves.
1469     ///
1470     /// ### Example
1471     ///
1472     /// ```rust
1473     /// fn foo() {
1474     ///     foo();
1475     /// }
1476     /// ```
1477     ///
1478     /// {{produces}}
1479     ///
1480     /// ### Explanation
1481     ///
1482     /// It is usually a mistake to have a recursive call that does not have
1483     /// some condition to cause it to terminate. If you really intend to have
1484     /// an infinite loop, using a `loop` expression is recommended.
1485     pub UNCONDITIONAL_RECURSION,
1486     Warn,
1487     "functions that cannot return without calling themselves"
1488 }
1489
1490 declare_lint! {
1491     /// The `single_use_lifetimes` lint detects lifetimes that are only used
1492     /// once.
1493     ///
1494     /// ### Example
1495     ///
1496     /// ```rust,compile_fail
1497     /// #![deny(single_use_lifetimes)]
1498     ///
1499     /// fn foo<'a>(x: &'a u32) {}
1500     /// ```
1501     ///
1502     /// {{produces}}
1503     ///
1504     /// ### Explanation
1505     ///
1506     /// Specifying an explicit lifetime like `'a` in a function or `impl`
1507     /// should only be used to link together two things. Otherwise, you should
1508     /// just use `'_` to indicate that the lifetime is not linked to anything,
1509     /// or elide the lifetime altogether if possible.
1510     ///
1511     /// This lint is "allow" by default because it was introduced at a time
1512     /// when `'_` and elided lifetimes were first being introduced, and this
1513     /// lint would be too noisy. Also, there are some known false positives
1514     /// that it produces. See [RFC 2115] for historical context, and [issue
1515     /// #44752] for more details.
1516     ///
1517     /// [RFC 2115]: https://github.com/rust-lang/rfcs/blob/master/text/2115-argument-lifetimes.md
1518     /// [issue #44752]: https://github.com/rust-lang/rust/issues/44752
1519     pub SINGLE_USE_LIFETIMES,
1520     Allow,
1521     "detects lifetime parameters that are only used once"
1522 }
1523
1524 declare_lint! {
1525     /// The `unused_lifetimes` lint detects lifetime parameters that are never
1526     /// used.
1527     ///
1528     /// ### Example
1529     ///
1530     /// ```rust,compile_fail
1531     /// #[deny(unused_lifetimes)]
1532     ///
1533     /// pub fn foo<'a>() {}
1534     /// ```
1535     ///
1536     /// {{produces}}
1537     ///
1538     /// ### Explanation
1539     ///
1540     /// Unused lifetime parameters may signal a mistake or unfinished code.
1541     /// Consider removing the parameter.
1542     pub UNUSED_LIFETIMES,
1543     Allow,
1544     "detects lifetime parameters that are never used"
1545 }
1546
1547 declare_lint! {
1548     /// The `tyvar_behind_raw_pointer` lint detects raw pointer to an
1549     /// inference variable.
1550     ///
1551     /// ### Example
1552     ///
1553     /// ```rust,edition2015
1554     /// // edition 2015
1555     /// let data = std::ptr::null();
1556     /// let _ = &data as *const *const ();
1557     ///
1558     /// if data.is_null() {}
1559     /// ```
1560     ///
1561     /// {{produces}}
1562     ///
1563     /// ### Explanation
1564     ///
1565     /// This kind of inference was previously allowed, but with the future
1566     /// arrival of [arbitrary self types], this can introduce ambiguity. To
1567     /// resolve this, use an explicit type instead of relying on type
1568     /// inference.
1569     ///
1570     /// This is a [future-incompatible] lint to transition this to a hard
1571     /// error in the 2018 edition. See [issue #46906] for more details. This
1572     /// is currently a hard-error on the 2018 edition, and is "warn" by
1573     /// default in the 2015 edition.
1574     ///
1575     /// [arbitrary self types]: https://github.com/rust-lang/rust/issues/44874
1576     /// [issue #46906]: https://github.com/rust-lang/rust/issues/46906
1577     /// [future-incompatible]: ../index.md#future-incompatible-lints
1578     pub TYVAR_BEHIND_RAW_POINTER,
1579     Warn,
1580     "raw pointer to an inference variable",
1581     @future_incompatible = FutureIncompatibleInfo {
1582         reference: "issue #46906 <https://github.com/rust-lang/rust/issues/46906>",
1583         reason: FutureIncompatibilityReason::EditionError(Edition::Edition2018),
1584     };
1585 }
1586
1587 declare_lint! {
1588     /// The `elided_lifetimes_in_paths` lint detects the use of hidden
1589     /// lifetime parameters.
1590     ///
1591     /// ### Example
1592     ///
1593     /// ```rust,compile_fail
1594     /// #![deny(elided_lifetimes_in_paths)]
1595     /// struct Foo<'a> {
1596     ///     x: &'a u32
1597     /// }
1598     ///
1599     /// fn foo(x: &Foo) {
1600     /// }
1601     /// ```
1602     ///
1603     /// {{produces}}
1604     ///
1605     /// ### Explanation
1606     ///
1607     /// Elided lifetime parameters can make it difficult to see at a glance
1608     /// that borrowing is occurring. This lint ensures that lifetime
1609     /// parameters are always explicitly stated, even if it is the `'_`
1610     /// [placeholder lifetime].
1611     ///
1612     /// This lint is "allow" by default because it has some known issues, and
1613     /// may require a significant transition for old code.
1614     ///
1615     /// [placeholder lifetime]: https://doc.rust-lang.org/reference/lifetime-elision.html#lifetime-elision-in-functions
1616     pub ELIDED_LIFETIMES_IN_PATHS,
1617     Allow,
1618     "hidden lifetime parameters in types are deprecated",
1619     crate_level_only
1620 }
1621
1622 declare_lint! {
1623     /// The `bare_trait_objects` lint suggests using `dyn Trait` for trait
1624     /// objects.
1625     ///
1626     /// ### Example
1627     ///
1628     /// ```rust,edition2018
1629     /// trait Trait { }
1630     ///
1631     /// fn takes_trait_object(_: Box<Trait>) {
1632     /// }
1633     /// ```
1634     ///
1635     /// {{produces}}
1636     ///
1637     /// ### Explanation
1638     ///
1639     /// Without the `dyn` indicator, it can be ambiguous or confusing when
1640     /// reading code as to whether or not you are looking at a trait object.
1641     /// The `dyn` keyword makes it explicit, and adds a symmetry to contrast
1642     /// with [`impl Trait`].
1643     ///
1644     /// [`impl Trait`]: https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
1645     pub BARE_TRAIT_OBJECTS,
1646     Warn,
1647     "suggest using `dyn Trait` for trait objects",
1648     @future_incompatible = FutureIncompatibleInfo {
1649         reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html>",
1650         reason: FutureIncompatibilityReason::EditionError(Edition::Edition2021),
1651     };
1652 }
1653
1654 declare_lint! {
1655     /// The `absolute_paths_not_starting_with_crate` lint detects fully
1656     /// qualified paths that start with a module name instead of `crate`,
1657     /// `self`, or an extern crate name
1658     ///
1659     /// ### Example
1660     ///
1661     /// ```rust,edition2015,compile_fail
1662     /// #![deny(absolute_paths_not_starting_with_crate)]
1663     ///
1664     /// mod foo {
1665     ///     pub fn bar() {}
1666     /// }
1667     ///
1668     /// fn main() {
1669     ///     ::foo::bar();
1670     /// }
1671     /// ```
1672     ///
1673     /// {{produces}}
1674     ///
1675     /// ### Explanation
1676     ///
1677     /// Rust [editions] allow the language to evolve without breaking
1678     /// backwards compatibility. This lint catches code that uses absolute
1679     /// paths in the style of the 2015 edition. In the 2015 edition, absolute
1680     /// paths (those starting with `::`) refer to either the crate root or an
1681     /// external crate. In the 2018 edition it was changed so that they only
1682     /// refer to external crates. The path prefix `crate::` should be used
1683     /// instead to reference items from the crate root.
1684     ///
1685     /// If you switch the compiler from the 2015 to 2018 edition without
1686     /// updating the code, then it will fail to compile if the old style paths
1687     /// are used. You can manually change the paths to use the `crate::`
1688     /// prefix to transition to the 2018 edition.
1689     ///
1690     /// This lint solves the problem automatically. It is "allow" by default
1691     /// because the code is perfectly valid in the 2015 edition. The [`cargo
1692     /// fix`] tool with the `--edition` flag will switch this lint to "warn"
1693     /// and automatically apply the suggested fix from the compiler. This
1694     /// provides a completely automated way to update old code to the 2018
1695     /// edition.
1696     ///
1697     /// [editions]: https://doc.rust-lang.org/edition-guide/
1698     /// [`cargo fix`]: https://doc.rust-lang.org/cargo/commands/cargo-fix.html
1699     pub ABSOLUTE_PATHS_NOT_STARTING_WITH_CRATE,
1700     Allow,
1701     "fully qualified paths that start with a module name \
1702      instead of `crate`, `self`, or an extern crate name",
1703      @future_incompatible = FutureIncompatibleInfo {
1704         reference: "issue #53130 <https://github.com/rust-lang/rust/issues/53130>",
1705         reason: FutureIncompatibilityReason::EditionError(Edition::Edition2018),
1706      };
1707 }
1708
1709 declare_lint! {
1710     /// The `illegal_floating_point_literal_pattern` lint detects
1711     /// floating-point literals used in patterns.
1712     ///
1713     /// ### Example
1714     ///
1715     /// ```rust
1716     /// let x = 42.0;
1717     ///
1718     /// match x {
1719     ///     5.0 => {}
1720     ///     _ => {}
1721     /// }
1722     /// ```
1723     ///
1724     /// {{produces}}
1725     ///
1726     /// ### Explanation
1727     ///
1728     /// Previous versions of the compiler accepted floating-point literals in
1729     /// patterns, but it was later determined this was a mistake. The
1730     /// semantics of comparing floating-point values may not be clear in a
1731     /// pattern when contrasted with "structural equality". Typically you can
1732     /// work around this by using a [match guard], such as:
1733     ///
1734     /// ```rust
1735     /// # let x = 42.0;
1736     ///
1737     /// match x {
1738     ///     y if y == 5.0 => {}
1739     ///     _ => {}
1740     /// }
1741     /// ```
1742     ///
1743     /// This is a [future-incompatible] lint to transition this to a hard
1744     /// error in the future. See [issue #41620] for more details.
1745     ///
1746     /// [issue #41620]: https://github.com/rust-lang/rust/issues/41620
1747     /// [match guard]: https://doc.rust-lang.org/reference/expressions/match-expr.html#match-guards
1748     /// [future-incompatible]: ../index.md#future-incompatible-lints
1749     pub ILLEGAL_FLOATING_POINT_LITERAL_PATTERN,
1750     Warn,
1751     "floating-point literals cannot be used in patterns",
1752     @future_incompatible = FutureIncompatibleInfo {
1753         reference: "issue #41620 <https://github.com/rust-lang/rust/issues/41620>",
1754     };
1755 }
1756
1757 declare_lint! {
1758     /// The `unstable_name_collisions` lint detects that you have used a name
1759     /// that the standard library plans to add in the future.
1760     ///
1761     /// ### Example
1762     ///
1763     /// ```rust
1764     /// trait MyIterator : Iterator {
1765     ///     // is_sorted is an unstable method that already exists on the Iterator trait
1766     ///     fn is_sorted(self) -> bool where Self: Sized {true}
1767     /// }
1768     ///
1769     /// impl<T: ?Sized> MyIterator for T where T: Iterator { }
1770     ///
1771     /// let x = vec![1, 2, 3];
1772     /// let _ = x.iter().is_sorted();
1773     /// ```
1774     ///
1775     /// {{produces}}
1776     ///
1777     /// ### Explanation
1778     ///
1779     /// When new methods are added to traits in the standard library, they are
1780     /// usually added in an "unstable" form which is only available on the
1781     /// [nightly channel] with a [`feature` attribute]. If there is any
1782     /// pre-existing code which extends a trait to have a method with the same
1783     /// name, then the names will collide. In the future, when the method is
1784     /// stabilized, this will cause an error due to the ambiguity. This lint
1785     /// is an early-warning to let you know that there may be a collision in
1786     /// the future. This can be avoided by adding type annotations to
1787     /// disambiguate which trait method you intend to call, such as
1788     /// `MyIterator::is_sorted(my_iter)` or renaming or removing the method.
1789     ///
1790     /// [nightly channel]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
1791     /// [`feature` attribute]: https://doc.rust-lang.org/nightly/unstable-book/
1792     pub UNSTABLE_NAME_COLLISIONS,
1793     Warn,
1794     "detects name collision with an existing but unstable method",
1795     @future_incompatible = FutureIncompatibleInfo {
1796         reason: FutureIncompatibilityReason::Custom(
1797             "once this associated item is added to the standard library, \
1798              the ambiguity may cause an error or change in behavior!"
1799         ),
1800         reference: "issue #48919 <https://github.com/rust-lang/rust/issues/48919>",
1801         // Note: this item represents future incompatibility of all unstable functions in the
1802         //       standard library, and thus should never be removed or changed to an error.
1803     };
1804 }
1805
1806 declare_lint! {
1807     /// The `irrefutable_let_patterns` lint detects [irrefutable patterns]
1808     /// in [`if let`]s, [`while let`]s, and `if let` guards.
1809     ///
1810     /// ### Example
1811     ///
1812     /// ```rust
1813     /// if let _ = 123 {
1814     ///     println!("always runs!");
1815     /// }
1816     /// ```
1817     ///
1818     /// {{produces}}
1819     ///
1820     /// ### Explanation
1821     ///
1822     /// There usually isn't a reason to have an irrefutable pattern in an
1823     /// `if let` or `while let` statement, because the pattern will always match
1824     /// successfully. A [`let`] or [`loop`] statement will suffice. However,
1825     /// when generating code with a macro, forbidding irrefutable patterns
1826     /// would require awkward workarounds in situations where the macro
1827     /// doesn't know if the pattern is refutable or not. This lint allows
1828     /// macros to accept this form, while alerting for a possibly incorrect
1829     /// use in normal code.
1830     ///
1831     /// See [RFC 2086] for more details.
1832     ///
1833     /// [irrefutable patterns]: https://doc.rust-lang.org/reference/patterns.html#refutability
1834     /// [`if let`]: https://doc.rust-lang.org/reference/expressions/if-expr.html#if-let-expressions
1835     /// [`while let`]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#predicate-pattern-loops
1836     /// [`let`]: https://doc.rust-lang.org/reference/statements.html#let-statements
1837     /// [`loop`]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#infinite-loops
1838     /// [RFC 2086]: https://github.com/rust-lang/rfcs/blob/master/text/2086-allow-if-let-irrefutables.md
1839     pub IRREFUTABLE_LET_PATTERNS,
1840     Warn,
1841     "detects irrefutable patterns in `if let` and `while let` statements"
1842 }
1843
1844 declare_lint! {
1845     /// The `unused_labels` lint detects [labels] that are never used.
1846     ///
1847     /// [labels]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#loop-labels
1848     ///
1849     /// ### Example
1850     ///
1851     /// ```rust,no_run
1852     /// 'unused_label: loop {}
1853     /// ```
1854     ///
1855     /// {{produces}}
1856     ///
1857     /// ### Explanation
1858     ///
1859     /// Unused labels may signal a mistake or unfinished code. To silence the
1860     /// warning for the individual label, prefix it with an underscore such as
1861     /// `'_my_label:`.
1862     pub UNUSED_LABELS,
1863     Warn,
1864     "detects labels that are never used"
1865 }
1866
1867 declare_lint! {
1868     /// The `where_clauses_object_safety` lint detects for [object safety] of
1869     /// [where clauses].
1870     ///
1871     /// [object safety]: https://doc.rust-lang.org/reference/items/traits.html#object-safety
1872     /// [where clauses]: https://doc.rust-lang.org/reference/items/generics.html#where-clauses
1873     ///
1874     /// ### Example
1875     ///
1876     /// ```rust,no_run
1877     /// trait Trait {}
1878     ///
1879     /// trait X { fn foo(&self) where Self: Trait; }
1880     ///
1881     /// impl X for () { fn foo(&self) {} }
1882     ///
1883     /// impl Trait for dyn X {}
1884     ///
1885     /// // Segfault at opt-level 0, SIGILL otherwise.
1886     /// pub fn main() { <dyn X as X>::foo(&()); }
1887     /// ```
1888     ///
1889     /// {{produces}}
1890     ///
1891     /// ### Explanation
1892     ///
1893     /// The compiler previously allowed these object-unsafe bounds, which was
1894     /// incorrect. This is a [future-incompatible] lint to transition this to
1895     /// a hard error in the future. See [issue #51443] for more details.
1896     ///
1897     /// [issue #51443]: https://github.com/rust-lang/rust/issues/51443
1898     /// [future-incompatible]: ../index.md#future-incompatible-lints
1899     pub WHERE_CLAUSES_OBJECT_SAFETY,
1900     Warn,
1901     "checks the object safety of where clauses",
1902     @future_incompatible = FutureIncompatibleInfo {
1903         reference: "issue #51443 <https://github.com/rust-lang/rust/issues/51443>",
1904     };
1905 }
1906
1907 declare_lint! {
1908     /// The `proc_macro_derive_resolution_fallback` lint detects proc macro
1909     /// derives using inaccessible names from parent modules.
1910     ///
1911     /// ### Example
1912     ///
1913     /// ```rust,ignore (proc-macro)
1914     /// // foo.rs
1915     /// #![crate_type = "proc-macro"]
1916     ///
1917     /// extern crate proc_macro;
1918     ///
1919     /// use proc_macro::*;
1920     ///
1921     /// #[proc_macro_derive(Foo)]
1922     /// pub fn foo1(a: TokenStream) -> TokenStream {
1923     ///     drop(a);
1924     ///     "mod __bar { static mut BAR: Option<Something> = None; }".parse().unwrap()
1925     /// }
1926     /// ```
1927     ///
1928     /// ```rust,ignore (needs-dependency)
1929     /// // bar.rs
1930     /// #[macro_use]
1931     /// extern crate foo;
1932     ///
1933     /// struct Something;
1934     ///
1935     /// #[derive(Foo)]
1936     /// struct Another;
1937     ///
1938     /// fn main() {}
1939     /// ```
1940     ///
1941     /// This will produce:
1942     ///
1943     /// ```text
1944     /// warning: cannot find type `Something` in this scope
1945     ///  --> src/main.rs:8:10
1946     ///   |
1947     /// 8 | #[derive(Foo)]
1948     ///   |          ^^^ names from parent modules are not accessible without an explicit import
1949     ///   |
1950     ///   = note: `#[warn(proc_macro_derive_resolution_fallback)]` on by default
1951     ///   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
1952     ///   = note: for more information, see issue #50504 <https://github.com/rust-lang/rust/issues/50504>
1953     /// ```
1954     ///
1955     /// ### Explanation
1956     ///
1957     /// If a proc-macro generates a module, the compiler unintentionally
1958     /// allowed items in that module to refer to items in the crate root
1959     /// without importing them. This is a [future-incompatible] lint to
1960     /// transition this to a hard error in the future. See [issue #50504] for
1961     /// more details.
1962     ///
1963     /// [issue #50504]: https://github.com/rust-lang/rust/issues/50504
1964     /// [future-incompatible]: ../index.md#future-incompatible-lints
1965     pub PROC_MACRO_DERIVE_RESOLUTION_FALLBACK,
1966     Deny,
1967     "detects proc macro derives using inaccessible names from parent modules",
1968     @future_incompatible = FutureIncompatibleInfo {
1969         reference: "issue #83583 <https://github.com/rust-lang/rust/issues/83583>",
1970         reason: FutureIncompatibilityReason::FutureReleaseErrorReportNow,
1971     };
1972 }
1973
1974 declare_lint! {
1975     /// The `macro_use_extern_crate` lint detects the use of the
1976     /// [`macro_use` attribute].
1977     ///
1978     /// ### Example
1979     ///
1980     /// ```rust,ignore (needs extern crate)
1981     /// #![deny(macro_use_extern_crate)]
1982     ///
1983     /// #[macro_use]
1984     /// extern crate serde_json;
1985     ///
1986     /// fn main() {
1987     ///     let _ = json!{{}};
1988     /// }
1989     /// ```
1990     ///
1991     /// This will produce:
1992     ///
1993     /// ```text
1994     /// error: deprecated `#[macro_use]` attribute used to import macros should be replaced at use sites with a `use` item to import the macro instead
1995     ///  --> src/main.rs:3:1
1996     ///   |
1997     /// 3 | #[macro_use]
1998     ///   | ^^^^^^^^^^^^
1999     ///   |
2000     /// note: the lint level is defined here
2001     ///  --> src/main.rs:1:9
2002     ///   |
2003     /// 1 | #![deny(macro_use_extern_crate)]
2004     ///   |         ^^^^^^^^^^^^^^^^^^^^^^
2005     /// ```
2006     ///
2007     /// ### Explanation
2008     ///
2009     /// The [`macro_use` attribute] on an [`extern crate`] item causes
2010     /// macros in that external crate to be brought into the prelude of the
2011     /// crate, making the macros in scope everywhere. As part of the efforts
2012     /// to simplify handling of dependencies in the [2018 edition], the use of
2013     /// `extern crate` is being phased out. To bring macros from extern crates
2014     /// into scope, it is recommended to use a [`use` import].
2015     ///
2016     /// This lint is "allow" by default because this is a stylistic choice
2017     /// that has not been settled, see [issue #52043] for more information.
2018     ///
2019     /// [`macro_use` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#the-macro_use-attribute
2020     /// [`use` import]: https://doc.rust-lang.org/reference/items/use-declarations.html
2021     /// [issue #52043]: https://github.com/rust-lang/rust/issues/52043
2022     pub MACRO_USE_EXTERN_CRATE,
2023     Allow,
2024     "the `#[macro_use]` attribute is now deprecated in favor of using macros \
2025      via the module system"
2026 }
2027
2028 declare_lint! {
2029     /// The `macro_expanded_macro_exports_accessed_by_absolute_paths` lint
2030     /// detects macro-expanded [`macro_export`] macros from the current crate
2031     /// that cannot be referred to by absolute paths.
2032     ///
2033     /// [`macro_export`]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
2034     ///
2035     /// ### Example
2036     ///
2037     /// ```rust,compile_fail
2038     /// macro_rules! define_exported {
2039     ///     () => {
2040     ///         #[macro_export]
2041     ///         macro_rules! exported {
2042     ///             () => {};
2043     ///         }
2044     ///     };
2045     /// }
2046     ///
2047     /// define_exported!();
2048     ///
2049     /// fn main() {
2050     ///     crate::exported!();
2051     /// }
2052     /// ```
2053     ///
2054     /// {{produces}}
2055     ///
2056     /// ### Explanation
2057     ///
2058     /// The intent is that all macros marked with the `#[macro_export]`
2059     /// attribute are made available in the root of the crate. However, when a
2060     /// `macro_rules!` definition is generated by another macro, the macro
2061     /// expansion is unable to uphold this rule. This is a
2062     /// [future-incompatible] lint to transition this to a hard error in the
2063     /// future. See [issue #53495] for more details.
2064     ///
2065     /// [issue #53495]: https://github.com/rust-lang/rust/issues/53495
2066     /// [future-incompatible]: ../index.md#future-incompatible-lints
2067     pub MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS,
2068     Deny,
2069     "macro-expanded `macro_export` macros from the current crate \
2070      cannot be referred to by absolute paths",
2071     @future_incompatible = FutureIncompatibleInfo {
2072         reference: "issue #52234 <https://github.com/rust-lang/rust/issues/52234>",
2073     };
2074     crate_level_only
2075 }
2076
2077 declare_lint! {
2078     /// The `explicit_outlives_requirements` lint detects unnecessary
2079     /// lifetime bounds that can be inferred.
2080     ///
2081     /// ### Example
2082     ///
2083     /// ```rust,compile_fail
2084     /// # #![allow(unused)]
2085     /// #![deny(explicit_outlives_requirements)]
2086     ///
2087     /// struct SharedRef<'a, T>
2088     /// where
2089     ///     T: 'a,
2090     /// {
2091     ///     data: &'a T,
2092     /// }
2093     /// ```
2094     ///
2095     /// {{produces}}
2096     ///
2097     /// ### Explanation
2098     ///
2099     /// If a `struct` contains a reference, such as `&'a T`, the compiler
2100     /// requires that `T` outlives the lifetime `'a`. This historically
2101     /// required writing an explicit lifetime bound to indicate this
2102     /// requirement. However, this can be overly explicit, causing clutter and
2103     /// unnecessary complexity. The language was changed to automatically
2104     /// infer the bound if it is not specified. Specifically, if the struct
2105     /// contains a reference, directly or indirectly, to `T` with lifetime
2106     /// `'x`, then it will infer that `T: 'x` is a requirement.
2107     ///
2108     /// This lint is "allow" by default because it can be noisy for existing
2109     /// code that already had these requirements. This is a stylistic choice,
2110     /// as it is still valid to explicitly state the bound. It also has some
2111     /// false positives that can cause confusion.
2112     ///
2113     /// See [RFC 2093] for more details.
2114     ///
2115     /// [RFC 2093]: https://github.com/rust-lang/rfcs/blob/master/text/2093-infer-outlives.md
2116     pub EXPLICIT_OUTLIVES_REQUIREMENTS,
2117     Allow,
2118     "outlives requirements can be inferred"
2119 }
2120
2121 declare_lint! {
2122     /// The `indirect_structural_match` lint detects a `const` in a pattern
2123     /// that manually implements [`PartialEq`] and [`Eq`].
2124     ///
2125     /// [`PartialEq`]: https://doc.rust-lang.org/std/cmp/trait.PartialEq.html
2126     /// [`Eq`]: https://doc.rust-lang.org/std/cmp/trait.Eq.html
2127     ///
2128     /// ### Example
2129     ///
2130     /// ```rust,compile_fail
2131     /// #![deny(indirect_structural_match)]
2132     ///
2133     /// struct NoDerive(i32);
2134     /// impl PartialEq for NoDerive { fn eq(&self, _: &Self) -> bool { false } }
2135     /// impl Eq for NoDerive { }
2136     /// #[derive(PartialEq, Eq)]
2137     /// struct WrapParam<T>(T);
2138     /// const WRAP_INDIRECT_PARAM: & &WrapParam<NoDerive> = & &WrapParam(NoDerive(0));
2139     /// fn main() {
2140     ///     match WRAP_INDIRECT_PARAM {
2141     ///         WRAP_INDIRECT_PARAM => { }
2142     ///         _ => { }
2143     ///     }
2144     /// }
2145     /// ```
2146     ///
2147     /// {{produces}}
2148     ///
2149     /// ### Explanation
2150     ///
2151     /// The compiler unintentionally accepted this form in the past. This is a
2152     /// [future-incompatible] lint to transition this to a hard error in the
2153     /// future. See [issue #62411] for a complete description of the problem,
2154     /// and some possible solutions.
2155     ///
2156     /// [issue #62411]: https://github.com/rust-lang/rust/issues/62411
2157     /// [future-incompatible]: ../index.md#future-incompatible-lints
2158     pub INDIRECT_STRUCTURAL_MATCH,
2159     Warn,
2160     "constant used in pattern contains value of non-structural-match type in a field or a variant",
2161     @future_incompatible = FutureIncompatibleInfo {
2162         reference: "issue #62411 <https://github.com/rust-lang/rust/issues/62411>",
2163     };
2164 }
2165
2166 declare_lint! {
2167     /// The `deprecated_in_future` lint is internal to rustc and should not be
2168     /// used by user code.
2169     ///
2170     /// This lint is only enabled in the standard library. It works with the
2171     /// use of `#[rustc_deprecated]` with a `since` field of a version in the
2172     /// future. This allows something to be marked as deprecated in a future
2173     /// version, and then this lint will ensure that the item is no longer
2174     /// used in the standard library. See the [stability documentation] for
2175     /// more details.
2176     ///
2177     /// [stability documentation]: https://rustc-dev-guide.rust-lang.org/stability.html#rustc_deprecated
2178     pub DEPRECATED_IN_FUTURE,
2179     Allow,
2180     "detects use of items that will be deprecated in a future version",
2181     report_in_external_macro
2182 }
2183
2184 declare_lint! {
2185     /// The `pointer_structural_match` lint detects pointers used in patterns whose behaviour
2186     /// cannot be relied upon across compiler versions and optimization levels.
2187     ///
2188     /// ### Example
2189     ///
2190     /// ```rust,compile_fail
2191     /// #![deny(pointer_structural_match)]
2192     /// fn foo(a: usize, b: usize) -> usize { a + b }
2193     /// const FOO: fn(usize, usize) -> usize = foo;
2194     /// fn main() {
2195     ///     match FOO {
2196     ///         FOO => {},
2197     ///         _ => {},
2198     ///     }
2199     /// }
2200     /// ```
2201     ///
2202     /// {{produces}}
2203     ///
2204     /// ### Explanation
2205     ///
2206     /// Previous versions of Rust allowed function pointers and wide raw pointers in patterns.
2207     /// While these work in many cases as expected by users, it is possible that due to
2208     /// optimizations pointers are "not equal to themselves" or pointers to different functions
2209     /// compare as equal during runtime. This is because LLVM optimizations can deduplicate
2210     /// functions if their bodies are the same, thus also making pointers to these functions point
2211     /// to the same location. Additionally functions may get duplicated if they are instantiated
2212     /// in different crates and not deduplicated again via LTO.
2213     pub POINTER_STRUCTURAL_MATCH,
2214     Allow,
2215     "pointers are not structural-match",
2216     @future_incompatible = FutureIncompatibleInfo {
2217         reference: "issue #62411 <https://github.com/rust-lang/rust/issues/70861>",
2218     };
2219 }
2220
2221 declare_lint! {
2222     /// The `nontrivial_structural_match` lint detects constants that are used in patterns,
2223     /// whose type is not structural-match and whose initializer body actually uses values
2224     /// that are not structural-match. So `Option<NotStruturalMatch>` is ok if the constant
2225     /// is just `None`.
2226     ///
2227     /// ### Example
2228     ///
2229     /// ```rust,compile_fail
2230     /// #![deny(nontrivial_structural_match)]
2231     ///
2232     /// #[derive(Copy, Clone, Debug)]
2233     /// struct NoDerive(u32);
2234     /// impl PartialEq for NoDerive { fn eq(&self, _: &Self) -> bool { false } }
2235     /// impl Eq for NoDerive { }
2236     /// fn main() {
2237     ///     const INDEX: Option<NoDerive> = [None, Some(NoDerive(10))][0];
2238     ///     match None { Some(_) => panic!("whoops"), INDEX => dbg!(INDEX), };
2239     /// }
2240     /// ```
2241     ///
2242     /// {{produces}}
2243     ///
2244     /// ### Explanation
2245     ///
2246     /// Previous versions of Rust accepted constants in patterns, even if those constants's types
2247     /// did not have `PartialEq` derived. Thus the compiler falls back to runtime execution of
2248     /// `PartialEq`, which can report that two constants are not equal even if they are
2249     /// bit-equivalent.
2250     pub NONTRIVIAL_STRUCTURAL_MATCH,
2251     Warn,
2252     "constant used in pattern of non-structural-match type and the constant's initializer \
2253     expression contains values of non-structural-match types",
2254     @future_incompatible = FutureIncompatibleInfo {
2255         reference: "issue #73448 <https://github.com/rust-lang/rust/issues/73448>",
2256     };
2257 }
2258
2259 declare_lint! {
2260     /// The `ambiguous_associated_items` lint detects ambiguity between
2261     /// [associated items] and [enum variants].
2262     ///
2263     /// [associated items]: https://doc.rust-lang.org/reference/items/associated-items.html
2264     /// [enum variants]: https://doc.rust-lang.org/reference/items/enumerations.html
2265     ///
2266     /// ### Example
2267     ///
2268     /// ```rust,compile_fail
2269     /// enum E {
2270     ///     V
2271     /// }
2272     ///
2273     /// trait Tr {
2274     ///     type V;
2275     ///     fn foo() -> Self::V;
2276     /// }
2277     ///
2278     /// impl Tr for E {
2279     ///     type V = u8;
2280     ///     // `Self::V` is ambiguous because it may refer to the associated type or
2281     ///     // the enum variant.
2282     ///     fn foo() -> Self::V { 0 }
2283     /// }
2284     /// ```
2285     ///
2286     /// {{produces}}
2287     ///
2288     /// ### Explanation
2289     ///
2290     /// Previous versions of Rust did not allow accessing enum variants
2291     /// through [type aliases]. When this ability was added (see [RFC 2338]), this
2292     /// introduced some situations where it can be ambiguous what a type
2293     /// was referring to.
2294     ///
2295     /// To fix this ambiguity, you should use a [qualified path] to explicitly
2296     /// state which type to use. For example, in the above example the
2297     /// function can be written as `fn f() -> <Self as Tr>::V { 0 }` to
2298     /// specifically refer to the associated type.
2299     ///
2300     /// This is a [future-incompatible] lint to transition this to a hard
2301     /// error in the future. See [issue #57644] for more details.
2302     ///
2303     /// [issue #57644]: https://github.com/rust-lang/rust/issues/57644
2304     /// [type aliases]: https://doc.rust-lang.org/reference/items/type-aliases.html#type-aliases
2305     /// [RFC 2338]: https://github.com/rust-lang/rfcs/blob/master/text/2338-type-alias-enum-variants.md
2306     /// [qualified path]: https://doc.rust-lang.org/reference/paths.html#qualified-paths
2307     /// [future-incompatible]: ../index.md#future-incompatible-lints
2308     pub AMBIGUOUS_ASSOCIATED_ITEMS,
2309     Deny,
2310     "ambiguous associated items",
2311     @future_incompatible = FutureIncompatibleInfo {
2312         reference: "issue #57644 <https://github.com/rust-lang/rust/issues/57644>",
2313     };
2314 }
2315
2316 declare_lint! {
2317     /// The `mutable_borrow_reservation_conflict` lint detects the reservation
2318     /// of a two-phased borrow that conflicts with other shared borrows.
2319     ///
2320     /// ### Example
2321     ///
2322     /// ```rust
2323     /// let mut v = vec![0, 1, 2];
2324     /// let shared = &v;
2325     /// v.push(shared.len());
2326     /// ```
2327     ///
2328     /// {{produces}}
2329     ///
2330     /// ### Explanation
2331     ///
2332     /// This is a [future-incompatible] lint to transition this to a hard error
2333     /// in the future. See [issue #59159] for a complete description of the
2334     /// problem, and some possible solutions.
2335     ///
2336     /// [issue #59159]: https://github.com/rust-lang/rust/issues/59159
2337     /// [future-incompatible]: ../index.md#future-incompatible-lints
2338     pub MUTABLE_BORROW_RESERVATION_CONFLICT,
2339     Warn,
2340     "reservation of a two-phased borrow conflicts with other shared borrows",
2341     @future_incompatible = FutureIncompatibleInfo {
2342         reason: FutureIncompatibilityReason::Custom(
2343             "this borrowing pattern was not meant to be accepted, \
2344             and may become a hard error in the future"
2345         ),
2346         reference: "issue #59159 <https://github.com/rust-lang/rust/issues/59159>",
2347     };
2348 }
2349
2350 declare_lint! {
2351     /// The `soft_unstable` lint detects unstable features that were
2352     /// unintentionally allowed on stable.
2353     ///
2354     /// ### Example
2355     ///
2356     /// ```rust,compile_fail
2357     /// #[cfg(test)]
2358     /// extern crate test;
2359     ///
2360     /// #[bench]
2361     /// fn name(b: &mut test::Bencher) {
2362     ///     b.iter(|| 123)
2363     /// }
2364     /// ```
2365     ///
2366     /// {{produces}}
2367     ///
2368     /// ### Explanation
2369     ///
2370     /// The [`bench` attribute] was accidentally allowed to be specified on
2371     /// the [stable release channel]. Turning this to a hard error would have
2372     /// broken some projects. This lint allows those projects to continue to
2373     /// build correctly when [`--cap-lints`] is used, but otherwise signal an
2374     /// error that `#[bench]` should not be used on the stable channel. This
2375     /// is a [future-incompatible] lint to transition this to a hard error in
2376     /// the future. See [issue #64266] for more details.
2377     ///
2378     /// [issue #64266]: https://github.com/rust-lang/rust/issues/64266
2379     /// [`bench` attribute]: https://doc.rust-lang.org/nightly/unstable-book/library-features/test.html
2380     /// [stable release channel]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
2381     /// [`--cap-lints`]: https://doc.rust-lang.org/rustc/lints/levels.html#capping-lints
2382     /// [future-incompatible]: ../index.md#future-incompatible-lints
2383     pub SOFT_UNSTABLE,
2384     Deny,
2385     "a feature gate that doesn't break dependent crates",
2386     @future_incompatible = FutureIncompatibleInfo {
2387         reference: "issue #64266 <https://github.com/rust-lang/rust/issues/64266>",
2388     };
2389 }
2390
2391 declare_lint! {
2392     /// The `inline_no_sanitize` lint detects incompatible use of
2393     /// [`#[inline(always)]`][inline] and [`#[no_sanitize(...)]`][no_sanitize].
2394     ///
2395     /// [inline]: https://doc.rust-lang.org/reference/attributes/codegen.html#the-inline-attribute
2396     /// [no_sanitize]: https://doc.rust-lang.org/nightly/unstable-book/language-features/no-sanitize.html
2397     ///
2398     /// ### Example
2399     ///
2400     /// ```rust
2401     /// #![feature(no_sanitize)]
2402     ///
2403     /// #[inline(always)]
2404     /// #[no_sanitize(address)]
2405     /// fn x() {}
2406     ///
2407     /// fn main() {
2408     ///     x()
2409     /// }
2410     /// ```
2411     ///
2412     /// {{produces}}
2413     ///
2414     /// ### Explanation
2415     ///
2416     /// The use of the [`#[inline(always)]`][inline] attribute prevents the
2417     /// the [`#[no_sanitize(...)]`][no_sanitize] attribute from working.
2418     /// Consider temporarily removing `inline` attribute.
2419     pub INLINE_NO_SANITIZE,
2420     Warn,
2421     "detects incompatible use of `#[inline(always)]` and `#[no_sanitize(...)]`",
2422 }
2423
2424 declare_lint! {
2425     /// The `asm_sub_register` lint detects using only a subset of a register
2426     /// for inline asm inputs.
2427     ///
2428     /// ### Example
2429     ///
2430     /// ```rust,ignore (fails on non-x86_64)
2431     /// #[cfg(target_arch="x86_64")]
2432     /// use std::arch::asm;
2433     ///
2434     /// fn main() {
2435     ///     #[cfg(target_arch="x86_64")]
2436     ///     unsafe {
2437     ///         asm!("mov {0}, {0}", in(reg) 0i16);
2438     ///     }
2439     /// }
2440     /// ```
2441     ///
2442     /// This will produce:
2443     ///
2444     /// ```text
2445     /// warning: formatting may not be suitable for sub-register argument
2446     ///  --> src/main.rs:7:19
2447     ///   |
2448     /// 7 |         asm!("mov {0}, {0}", in(reg) 0i16);
2449     ///   |                   ^^^  ^^^           ---- for this argument
2450     ///   |
2451     ///   = note: `#[warn(asm_sub_register)]` on by default
2452     ///   = help: use the `x` modifier to have the register formatted as `ax`
2453     ///   = help: or use the `r` modifier to keep the default formatting of `rax`
2454     /// ```
2455     ///
2456     /// ### Explanation
2457     ///
2458     /// Registers on some architectures can use different names to refer to a
2459     /// subset of the register. By default, the compiler will use the name for
2460     /// the full register size. To explicitly use a subset of the register,
2461     /// you can override the default by using a modifier on the template
2462     /// string operand to specify when subregister to use. This lint is issued
2463     /// if you pass in a value with a smaller data type than the default
2464     /// register size, to alert you of possibly using the incorrect width. To
2465     /// fix this, add the suggested modifier to the template, or cast the
2466     /// value to the correct size.
2467     ///
2468     /// See [register template modifiers] in the reference for more details.
2469     ///
2470     /// [register template modifiers]: https://doc.rust-lang.org/nightly/reference/inline-assembly.html#template-modifiers
2471     pub ASM_SUB_REGISTER,
2472     Warn,
2473     "using only a subset of a register for inline asm inputs",
2474 }
2475
2476 declare_lint! {
2477     /// The `bad_asm_style` lint detects the use of the `.intel_syntax` and
2478     /// `.att_syntax` directives.
2479     ///
2480     /// ### Example
2481     ///
2482     /// ```rust,ignore (fails on non-x86_64)
2483     /// #[cfg(target_arch="x86_64")]
2484     /// use std::arch::asm;
2485     ///
2486     /// fn main() {
2487     ///     #[cfg(target_arch="x86_64")]
2488     ///     unsafe {
2489     ///         asm!(
2490     ///             ".att_syntax",
2491     ///             "movq %{0}, %{0}", in(reg) 0usize
2492     ///         );
2493     ///     }
2494     /// }
2495     /// ```
2496     ///
2497     /// This will produce:
2498     ///
2499     /// ```text
2500     /// warning: avoid using `.att_syntax`, prefer using `options(att_syntax)` instead
2501     ///  --> src/main.rs:8:14
2502     ///   |
2503     /// 8 |             ".att_syntax",
2504     ///   |              ^^^^^^^^^^^
2505     ///   |
2506     ///   = note: `#[warn(bad_asm_style)]` on by default
2507     /// ```
2508     ///
2509     /// ### Explanation
2510     ///
2511     /// On x86, `asm!` uses the intel assembly syntax by default. While this
2512     /// can be switched using assembler directives like `.att_syntax`, using the
2513     /// `att_syntax` option is recommended instead because it will also properly
2514     /// prefix register placeholders with `%` as required by AT&T syntax.
2515     pub BAD_ASM_STYLE,
2516     Warn,
2517     "incorrect use of inline assembly",
2518 }
2519
2520 declare_lint! {
2521     /// The `unsafe_op_in_unsafe_fn` lint detects unsafe operations in unsafe
2522     /// functions without an explicit unsafe block.
2523     ///
2524     /// ### Example
2525     ///
2526     /// ```rust,compile_fail
2527     /// #![deny(unsafe_op_in_unsafe_fn)]
2528     ///
2529     /// unsafe fn foo() {}
2530     ///
2531     /// unsafe fn bar() {
2532     ///     foo();
2533     /// }
2534     ///
2535     /// fn main() {}
2536     /// ```
2537     ///
2538     /// {{produces}}
2539     ///
2540     /// ### Explanation
2541     ///
2542     /// Currently, an [`unsafe fn`] allows any [unsafe] operation within its
2543     /// body. However, this can increase the surface area of code that needs
2544     /// to be scrutinized for proper behavior. The [`unsafe` block] provides a
2545     /// convenient way to make it clear exactly which parts of the code are
2546     /// performing unsafe operations. In the future, it is desired to change
2547     /// it so that unsafe operations cannot be performed in an `unsafe fn`
2548     /// without an `unsafe` block.
2549     ///
2550     /// The fix to this is to wrap the unsafe code in an `unsafe` block.
2551     ///
2552     /// This lint is "allow" by default since this will affect a large amount
2553     /// of existing code, and the exact plan for increasing the severity is
2554     /// still being considered. See [RFC #2585] and [issue #71668] for more
2555     /// details.
2556     ///
2557     /// [`unsafe fn`]: https://doc.rust-lang.org/reference/unsafe-functions.html
2558     /// [`unsafe` block]: https://doc.rust-lang.org/reference/expressions/block-expr.html#unsafe-blocks
2559     /// [unsafe]: https://doc.rust-lang.org/reference/unsafety.html
2560     /// [RFC #2585]: https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md
2561     /// [issue #71668]: https://github.com/rust-lang/rust/issues/71668
2562     pub UNSAFE_OP_IN_UNSAFE_FN,
2563     Allow,
2564     "unsafe operations in unsafe functions without an explicit unsafe block are deprecated",
2565 }
2566
2567 declare_lint! {
2568     /// The `cenum_impl_drop_cast` lint detects an `as` cast of a field-less
2569     /// `enum` that implements [`Drop`].
2570     ///
2571     /// [`Drop`]: https://doc.rust-lang.org/std/ops/trait.Drop.html
2572     ///
2573     /// ### Example
2574     ///
2575     /// ```rust
2576     /// # #![allow(unused)]
2577     /// enum E {
2578     ///     A,
2579     /// }
2580     ///
2581     /// impl Drop for E {
2582     ///     fn drop(&mut self) {
2583     ///         println!("Drop");
2584     ///     }
2585     /// }
2586     ///
2587     /// fn main() {
2588     ///     let e = E::A;
2589     ///     let i = e as u32;
2590     /// }
2591     /// ```
2592     ///
2593     /// {{produces}}
2594     ///
2595     /// ### Explanation
2596     ///
2597     /// Casting a field-less `enum` that does not implement [`Copy`] to an
2598     /// integer moves the value without calling `drop`. This can result in
2599     /// surprising behavior if it was expected that `drop` should be called.
2600     /// Calling `drop` automatically would be inconsistent with other move
2601     /// operations. Since neither behavior is clear or consistent, it was
2602     /// decided that a cast of this nature will no longer be allowed.
2603     ///
2604     /// This is a [future-incompatible] lint to transition this to a hard error
2605     /// in the future. See [issue #73333] for more details.
2606     ///
2607     /// [future-incompatible]: ../index.md#future-incompatible-lints
2608     /// [issue #73333]: https://github.com/rust-lang/rust/issues/73333
2609     /// [`Copy`]: https://doc.rust-lang.org/std/marker/trait.Copy.html
2610     pub CENUM_IMPL_DROP_CAST,
2611     Warn,
2612     "a C-like enum implementing Drop is cast",
2613     @future_incompatible = FutureIncompatibleInfo {
2614         reference: "issue #73333 <https://github.com/rust-lang/rust/issues/73333>",
2615     };
2616 }
2617
2618 declare_lint! {
2619     /// The `const_evaluatable_unchecked` lint detects a generic constant used
2620     /// in a type.
2621     ///
2622     /// ### Example
2623     ///
2624     /// ```rust
2625     /// const fn foo<T>() -> usize {
2626     ///     if std::mem::size_of::<*mut T>() < 8 { // size of *mut T does not depend on T
2627     ///         4
2628     ///     } else {
2629     ///         8
2630     ///     }
2631     /// }
2632     ///
2633     /// fn test<T>() {
2634     ///     let _ = [0; foo::<T>()];
2635     /// }
2636     /// ```
2637     ///
2638     /// {{produces}}
2639     ///
2640     /// ### Explanation
2641     ///
2642     /// In the 1.43 release, some uses of generic parameters in array repeat
2643     /// expressions were accidentally allowed. This is a [future-incompatible]
2644     /// lint to transition this to a hard error in the future. See [issue
2645     /// #76200] for a more detailed description and possible fixes.
2646     ///
2647     /// [future-incompatible]: ../index.md#future-incompatible-lints
2648     /// [issue #76200]: https://github.com/rust-lang/rust/issues/76200
2649     pub CONST_EVALUATABLE_UNCHECKED,
2650     Warn,
2651     "detects a generic constant is used in a type without a emitting a warning",
2652     @future_incompatible = FutureIncompatibleInfo {
2653         reference: "issue #76200 <https://github.com/rust-lang/rust/issues/76200>",
2654     };
2655 }
2656
2657 declare_lint! {
2658     /// The `function_item_references` lint detects function references that are
2659     /// formatted with [`fmt::Pointer`] or transmuted.
2660     ///
2661     /// [`fmt::Pointer`]: https://doc.rust-lang.org/std/fmt/trait.Pointer.html
2662     ///
2663     /// ### Example
2664     ///
2665     /// ```rust
2666     /// fn foo() { }
2667     ///
2668     /// fn main() {
2669     ///     println!("{:p}", &foo);
2670     /// }
2671     /// ```
2672     ///
2673     /// {{produces}}
2674     ///
2675     /// ### Explanation
2676     ///
2677     /// Taking a reference to a function may be mistaken as a way to obtain a
2678     /// pointer to that function. This can give unexpected results when
2679     /// formatting the reference as a pointer or transmuting it. This lint is
2680     /// issued when function references are formatted as pointers, passed as
2681     /// arguments bound by [`fmt::Pointer`] or transmuted.
2682     pub FUNCTION_ITEM_REFERENCES,
2683     Warn,
2684     "suggest casting to a function pointer when attempting to take references to function items",
2685 }
2686
2687 declare_lint! {
2688     /// The `uninhabited_static` lint detects uninhabited statics.
2689     ///
2690     /// ### Example
2691     ///
2692     /// ```rust
2693     /// enum Void {}
2694     /// extern {
2695     ///     static EXTERN: Void;
2696     /// }
2697     /// ```
2698     ///
2699     /// {{produces}}
2700     ///
2701     /// ### Explanation
2702     ///
2703     /// Statics with an uninhabited type can never be initialized, so they are impossible to define.
2704     /// However, this can be side-stepped with an `extern static`, leading to problems later in the
2705     /// compiler which assumes that there are no initialized uninhabited places (such as locals or
2706     /// statics). This was accidentally allowed, but is being phased out.
2707     pub UNINHABITED_STATIC,
2708     Warn,
2709     "uninhabited static",
2710     @future_incompatible = FutureIncompatibleInfo {
2711         reference: "issue #74840 <https://github.com/rust-lang/rust/issues/74840>",
2712     };
2713 }
2714
2715 declare_lint! {
2716     /// The `useless_deprecated` lint detects deprecation attributes with no effect.
2717     ///
2718     /// ### Example
2719     ///
2720     /// ```rust,compile_fail
2721     /// struct X;
2722     ///
2723     /// #[deprecated = "message"]
2724     /// impl Default for X {
2725     ///     fn default() -> Self {
2726     ///         X
2727     ///     }
2728     /// }
2729     /// ```
2730     ///
2731     /// {{produces}}
2732     ///
2733     /// ### Explanation
2734     ///
2735     /// Deprecation attributes have no effect on trait implementations.
2736     pub USELESS_DEPRECATED,
2737     Deny,
2738     "detects deprecation attributes with no effect",
2739 }
2740
2741 declare_lint! {
2742     /// The `undefined_naked_function_abi` lint detects naked function definitions that
2743     /// either do not specify an ABI or specify the Rust ABI.
2744     ///
2745     /// ### Example
2746     ///
2747     /// ```rust
2748     /// #![feature(naked_functions)]
2749     ///
2750     /// use std::arch::asm;
2751     ///
2752     /// #[naked]
2753     /// pub fn default_abi() -> u32 {
2754     ///     unsafe { asm!("", options(noreturn)); }
2755     /// }
2756     ///
2757     /// #[naked]
2758     /// pub extern "Rust" fn rust_abi() -> u32 {
2759     ///     unsafe { asm!("", options(noreturn)); }
2760     /// }
2761     /// ```
2762     ///
2763     /// {{produces}}
2764     ///
2765     /// ### Explanation
2766     ///
2767     /// The Rust ABI is currently undefined. Therefore, naked functions should
2768     /// specify a non-Rust ABI.
2769     pub UNDEFINED_NAKED_FUNCTION_ABI,
2770     Warn,
2771     "undefined naked function ABI"
2772 }
2773
2774 declare_lint! {
2775     /// The `ineffective_unstable_trait_impl` lint detects `#[unstable]` attributes which are not used.
2776     ///
2777     /// ### Example
2778     ///
2779     /// ```rust,compile_fail
2780     /// #![feature(staged_api)]
2781     ///
2782     /// #[derive(Clone)]
2783     /// #[stable(feature = "x", since = "1")]
2784     /// struct S {}
2785     ///
2786     /// #[unstable(feature = "y", issue = "none")]
2787     /// impl Copy for S {}
2788     /// ```
2789     ///
2790     /// {{produces}}
2791     ///
2792     /// ### Explanation
2793     ///
2794     /// `staged_api` does not currently support using a stability attribute on `impl` blocks.
2795     /// `impl`s are always stable if both the type and trait are stable, and always unstable otherwise.
2796     pub INEFFECTIVE_UNSTABLE_TRAIT_IMPL,
2797     Deny,
2798     "detects `#[unstable]` on stable trait implementations for stable types"
2799 }
2800
2801 declare_lint! {
2802     /// The `semicolon_in_expressions_from_macros` lint detects trailing semicolons
2803     /// in macro bodies when the macro is invoked in expression position.
2804     /// This was previous accepted, but is being phased out.
2805     ///
2806     /// ### Example
2807     ///
2808     /// ```rust,compile_fail
2809     /// #![deny(semicolon_in_expressions_from_macros)]
2810     /// macro_rules! foo {
2811     ///     () => { true; }
2812     /// }
2813     ///
2814     /// fn main() {
2815     ///     let val = match true {
2816     ///         true => false,
2817     ///         _ => foo!()
2818     ///     };
2819     /// }
2820     /// ```
2821     ///
2822     /// {{produces}}
2823     ///
2824     /// ### Explanation
2825     ///
2826     /// Previous, Rust ignored trailing semicolon in a macro
2827     /// body when a macro was invoked in expression position.
2828     /// However, this makes the treatment of semicolons in the language
2829     /// inconsistent, and could lead to unexpected runtime behavior
2830     /// in some circumstances (e.g. if the macro author expects
2831     /// a value to be dropped).
2832     ///
2833     /// This is a [future-incompatible] lint to transition this
2834     /// to a hard error in the future. See [issue #79813] for more details.
2835     ///
2836     /// [issue #79813]: https://github.com/rust-lang/rust/issues/79813
2837     /// [future-incompatible]: ../index.md#future-incompatible-lints
2838     pub SEMICOLON_IN_EXPRESSIONS_FROM_MACROS,
2839     Warn,
2840     "trailing semicolon in macro body used as expression",
2841     @future_incompatible = FutureIncompatibleInfo {
2842         reference: "issue #79813 <https://github.com/rust-lang/rust/issues/79813>",
2843     };
2844 }
2845
2846 declare_lint! {
2847     /// The `legacy_derive_helpers` lint detects derive helper attributes
2848     /// that are used before they are introduced.
2849     ///
2850     /// ### Example
2851     ///
2852     /// ```rust,ignore (needs extern crate)
2853     /// #[serde(rename_all = "camelCase")]
2854     /// #[derive(Deserialize)]
2855     /// struct S { /* fields */ }
2856     /// ```
2857     ///
2858     /// produces:
2859     ///
2860     /// ```text
2861     /// warning: derive helper attribute is used before it is introduced
2862     ///   --> $DIR/legacy-derive-helpers.rs:1:3
2863     ///    |
2864     ///  1 | #[serde(rename_all = "camelCase")]
2865     ///    |   ^^^^^
2866     /// ...
2867     ///  2 | #[derive(Deserialize)]
2868     ///    |          ----------- the attribute is introduced here
2869     /// ```
2870     ///
2871     /// ### Explanation
2872     ///
2873     /// Attributes like this work for historical reasons, but attribute expansion works in
2874     /// left-to-right order in general, so, to resolve `#[serde]`, compiler has to try to "look
2875     /// into the future" at not yet expanded part of the item , but such attempts are not always
2876     /// reliable.
2877     ///
2878     /// To fix the warning place the helper attribute after its corresponding derive.
2879     /// ```rust,ignore (needs extern crate)
2880     /// #[derive(Deserialize)]
2881     /// #[serde(rename_all = "camelCase")]
2882     /// struct S { /* fields */ }
2883     /// ```
2884     pub LEGACY_DERIVE_HELPERS,
2885     Warn,
2886     "detects derive helper attributes that are used before they are introduced",
2887     @future_incompatible = FutureIncompatibleInfo {
2888         reference: "issue #79202 <https://github.com/rust-lang/rust/issues/79202>",
2889     };
2890 }
2891
2892 declare_lint! {
2893     /// The `large_assignments` lint detects when objects of large
2894     /// types are being moved around.
2895     ///
2896     /// ### Example
2897     ///
2898     /// ```rust,ignore (can crash on some platforms)
2899     /// let x = [0; 50000];
2900     /// let y = x;
2901     /// ```
2902     ///
2903     /// produces:
2904     ///
2905     /// ```text
2906     /// warning: moving a large value
2907     ///   --> $DIR/move-large.rs:1:3
2908     ///   let y = x;
2909     ///           - Copied large value here
2910     /// ```
2911     ///
2912     /// ### Explanation
2913     ///
2914     /// When using a large type in a plain assignment or in a function
2915     /// argument, idiomatic code can be inefficient.
2916     /// Ideally appropriate optimizations would resolve this, but such
2917     /// optimizations are only done in a best-effort manner.
2918     /// This lint will trigger on all sites of large moves and thus allow the
2919     /// user to resolve them in code.
2920     pub LARGE_ASSIGNMENTS,
2921     Warn,
2922     "detects large moves or copies",
2923 }
2924
2925 declare_lint! {
2926     /// The `deprecated_cfg_attr_crate_type_name` lint detects uses of the
2927     /// `#![cfg_attr(..., crate_type = "...")]` and
2928     /// `#![cfg_attr(..., crate_name = "...")]` attributes to conditionally
2929     /// specify the crate type and name in the source code.
2930     ///
2931     /// ### Example
2932     ///
2933     /// ```rust
2934     /// #![cfg_attr(debug_assertions, crate_type = "lib")]
2935     /// ```
2936     ///
2937     /// {{produces}}
2938     ///
2939     ///
2940     /// ### Explanation
2941     ///
2942     /// The `#![crate_type]` and `#![crate_name]` attributes require a hack in
2943     /// the compiler to be able to change the used crate type and crate name
2944     /// after macros have been expanded. Neither attribute works in combination
2945     /// with Cargo as it explicitly passes `--crate-type` and `--crate-name` on
2946     /// the commandline. These values must match the value used in the source
2947     /// code to prevent an error.
2948     ///
2949     /// To fix the warning use `--crate-type` on the commandline when running
2950     /// rustc instead of `#![cfg_attr(..., crate_type = "...")]` and
2951     /// `--crate-name` instead of `#![cfg_attr(..., crate_name = "...")]`.
2952     pub DEPRECATED_CFG_ATTR_CRATE_TYPE_NAME,
2953     Warn,
2954     "detects usage of `#![cfg_attr(..., crate_type/crate_name = \"...\")]`",
2955     @future_incompatible = FutureIncompatibleInfo {
2956         reference: "issue #91632 <https://github.com/rust-lang/rust/issues/91632>",
2957     };
2958 }
2959
2960 declare_lint_pass! {
2961     /// Does nothing as a lint pass, but registers some `Lint`s
2962     /// that are used by other parts of the compiler.
2963     HardwiredLints => [
2964         FORBIDDEN_LINT_GROUPS,
2965         ILLEGAL_FLOATING_POINT_LITERAL_PATTERN,
2966         ARITHMETIC_OVERFLOW,
2967         UNCONDITIONAL_PANIC,
2968         UNUSED_IMPORTS,
2969         UNUSED_EXTERN_CRATES,
2970         UNUSED_CRATE_DEPENDENCIES,
2971         UNUSED_QUALIFICATIONS,
2972         UNKNOWN_LINTS,
2973         UNUSED_VARIABLES,
2974         UNUSED_ASSIGNMENTS,
2975         DEAD_CODE,
2976         UNREACHABLE_CODE,
2977         UNREACHABLE_PATTERNS,
2978         OVERLAPPING_RANGE_ENDPOINTS,
2979         BINDINGS_WITH_VARIANT_NAME,
2980         UNUSED_MACROS,
2981         WARNINGS,
2982         UNUSED_FEATURES,
2983         STABLE_FEATURES,
2984         UNKNOWN_CRATE_TYPES,
2985         TRIVIAL_CASTS,
2986         TRIVIAL_NUMERIC_CASTS,
2987         PRIVATE_IN_PUBLIC,
2988         EXPORTED_PRIVATE_DEPENDENCIES,
2989         PUB_USE_OF_PRIVATE_EXTERN_CRATE,
2990         INVALID_TYPE_PARAM_DEFAULT,
2991         CONST_ERR,
2992         RENAMED_AND_REMOVED_LINTS,
2993         UNALIGNED_REFERENCES,
2994         CONST_ITEM_MUTATION,
2995         PATTERNS_IN_FNS_WITHOUT_BODY,
2996         MISSING_FRAGMENT_SPECIFIER,
2997         LATE_BOUND_LIFETIME_ARGUMENTS,
2998         ORDER_DEPENDENT_TRAIT_OBJECTS,
2999         COHERENCE_LEAK_CHECK,
3000         DEPRECATED,
3001         UNUSED_UNSAFE,
3002         UNUSED_MUT,
3003         UNCONDITIONAL_RECURSION,
3004         SINGLE_USE_LIFETIMES,
3005         UNUSED_LIFETIMES,
3006         UNUSED_LABELS,
3007         TYVAR_BEHIND_RAW_POINTER,
3008         ELIDED_LIFETIMES_IN_PATHS,
3009         BARE_TRAIT_OBJECTS,
3010         ABSOLUTE_PATHS_NOT_STARTING_WITH_CRATE,
3011         UNSTABLE_NAME_COLLISIONS,
3012         IRREFUTABLE_LET_PATTERNS,
3013         WHERE_CLAUSES_OBJECT_SAFETY,
3014         PROC_MACRO_DERIVE_RESOLUTION_FALLBACK,
3015         MACRO_USE_EXTERN_CRATE,
3016         MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS,
3017         ILL_FORMED_ATTRIBUTE_INPUT,
3018         CONFLICTING_REPR_HINTS,
3019         META_VARIABLE_MISUSE,
3020         DEPRECATED_IN_FUTURE,
3021         AMBIGUOUS_ASSOCIATED_ITEMS,
3022         MUTABLE_BORROW_RESERVATION_CONFLICT,
3023         INDIRECT_STRUCTURAL_MATCH,
3024         POINTER_STRUCTURAL_MATCH,
3025         NONTRIVIAL_STRUCTURAL_MATCH,
3026         SOFT_UNSTABLE,
3027         INLINE_NO_SANITIZE,
3028         BAD_ASM_STYLE,
3029         ASM_SUB_REGISTER,
3030         UNSAFE_OP_IN_UNSAFE_FN,
3031         INCOMPLETE_INCLUDE,
3032         CENUM_IMPL_DROP_CAST,
3033         CONST_EVALUATABLE_UNCHECKED,
3034         INEFFECTIVE_UNSTABLE_TRAIT_IMPL,
3035         MUST_NOT_SUSPEND,
3036         UNINHABITED_STATIC,
3037         FUNCTION_ITEM_REFERENCES,
3038         USELESS_DEPRECATED,
3039         MISSING_ABI,
3040         INVALID_DOC_ATTRIBUTES,
3041         SEMICOLON_IN_EXPRESSIONS_FROM_MACROS,
3042         RUST_2021_INCOMPATIBLE_CLOSURE_CAPTURES,
3043         LEGACY_DERIVE_HELPERS,
3044         PROC_MACRO_BACK_COMPAT,
3045         RUST_2021_INCOMPATIBLE_OR_PATTERNS,
3046         LARGE_ASSIGNMENTS,
3047         RUST_2021_PRELUDE_COLLISIONS,
3048         RUST_2021_PREFIXES_INCOMPATIBLE_SYNTAX,
3049         UNSUPPORTED_CALLING_CONVENTIONS,
3050         BREAK_WITH_LABEL_AND_LOOP,
3051         UNUSED_ATTRIBUTES,
3052         NON_EXHAUSTIVE_OMITTED_PATTERNS,
3053         TEXT_DIRECTION_CODEPOINT_IN_COMMENT,
3054         DEREF_INTO_DYN_SUPERTRAIT,
3055         DEPRECATED_CFG_ATTR_CRATE_TYPE_NAME,
3056         DUPLICATE_MACRO_ATTRIBUTES,
3057         SUSPICIOUS_AUTO_TRAIT_IMPLS,
3058     ]
3059 }
3060
3061 declare_lint! {
3062     /// The `unused_doc_comments` lint detects doc comments that aren't used
3063     /// by `rustdoc`.
3064     ///
3065     /// ### Example
3066     ///
3067     /// ```rust
3068     /// /// docs for x
3069     /// let x = 12;
3070     /// ```
3071     ///
3072     /// {{produces}}
3073     ///
3074     /// ### Explanation
3075     ///
3076     /// `rustdoc` does not use doc comments in all positions, and so the doc
3077     /// comment will be ignored. Try changing it to a normal comment with `//`
3078     /// to avoid the warning.
3079     pub UNUSED_DOC_COMMENTS,
3080     Warn,
3081     "detects doc comments that aren't used by rustdoc"
3082 }
3083
3084 declare_lint! {
3085     /// The `rust_2021_incompatible_closure_captures` lint detects variables that aren't completely
3086     /// captured in Rust 2021, such that the `Drop` order of their fields may differ between
3087     /// Rust 2018 and 2021.
3088     ///
3089     /// It can also detect when a variable implements a trait like `Send`, but one of its fields does not,
3090     /// and the field is captured by a closure and used with the assumption that said field implements
3091     /// the same trait as the root variable.
3092     ///
3093     /// ### Example of drop reorder
3094     ///
3095     /// ```rust,compile_fail
3096     /// #![deny(rust_2021_incompatible_closure_captures)]
3097     /// # #![allow(unused)]
3098     ///
3099     /// struct FancyInteger(i32);
3100     ///
3101     /// impl Drop for FancyInteger {
3102     ///     fn drop(&mut self) {
3103     ///         println!("Just dropped {}", self.0);
3104     ///     }
3105     /// }
3106     ///
3107     /// struct Point { x: FancyInteger, y: FancyInteger }
3108     ///
3109     /// fn main() {
3110     ///   let p = Point { x: FancyInteger(10), y: FancyInteger(20) };
3111     ///
3112     ///   let c = || {
3113     ///      let x = p.x;
3114     ///   };
3115     ///
3116     ///   c();
3117     ///
3118     ///   // ... More code ...
3119     /// }
3120     /// ```
3121     ///
3122     /// {{produces}}
3123     ///
3124     /// ### Explanation
3125     ///
3126     /// In the above example, `p.y` will be dropped at the end of `f` instead of
3127     /// with `c` in Rust 2021.
3128     ///
3129     /// ### Example of auto-trait
3130     ///
3131     /// ```rust,compile_fail
3132     /// #![deny(rust_2021_incompatible_closure_captures)]
3133     /// use std::thread;
3134     ///
3135     /// struct Pointer(*mut i32);
3136     /// unsafe impl Send for Pointer {}
3137     ///
3138     /// fn main() {
3139     ///     let mut f = 10;
3140     ///     let fptr = Pointer(&mut f as *mut i32);
3141     ///     thread::spawn(move || unsafe {
3142     ///         *fptr.0 = 20;
3143     ///     });
3144     /// }
3145     /// ```
3146     ///
3147     /// {{produces}}
3148     ///
3149     /// ### Explanation
3150     ///
3151     /// In the above example, only `fptr.0` is captured in Rust 2021.
3152     /// The field is of type `*mut i32`, which doesn't implement `Send`,
3153     /// making the code invalid as the field cannot be sent between threads safely.
3154     pub RUST_2021_INCOMPATIBLE_CLOSURE_CAPTURES,
3155     Allow,
3156     "detects closures affected by Rust 2021 changes",
3157     @future_incompatible = FutureIncompatibleInfo {
3158         reason: FutureIncompatibilityReason::EditionSemanticsChange(Edition::Edition2021),
3159         explain_reason: false,
3160     };
3161 }
3162
3163 declare_lint_pass!(UnusedDocComment => [UNUSED_DOC_COMMENTS]);
3164
3165 declare_lint! {
3166     /// The `missing_abi` lint detects cases where the ABI is omitted from
3167     /// extern declarations.
3168     ///
3169     /// ### Example
3170     ///
3171     /// ```rust,compile_fail
3172     /// #![deny(missing_abi)]
3173     ///
3174     /// extern fn foo() {}
3175     /// ```
3176     ///
3177     /// {{produces}}
3178     ///
3179     /// ### Explanation
3180     ///
3181     /// Historically, Rust implicitly selected C as the ABI for extern
3182     /// declarations. We expect to add new ABIs, like `C-unwind`, in the future,
3183     /// though this has not yet happened, and especially with their addition
3184     /// seeing the ABI easily will make code review easier.
3185     pub MISSING_ABI,
3186     Allow,
3187     "No declared ABI for extern declaration"
3188 }
3189
3190 declare_lint! {
3191     /// The `invalid_doc_attributes` lint detects when the `#[doc(...)]` is
3192     /// misused.
3193     ///
3194     /// ### Example
3195     ///
3196     /// ```rust,compile_fail
3197     /// #![deny(warnings)]
3198     ///
3199     /// pub mod submodule {
3200     ///     #![doc(test(no_crate_inject))]
3201     /// }
3202     /// ```
3203     ///
3204     /// {{produces}}
3205     ///
3206     /// ### Explanation
3207     ///
3208     /// Previously, there were very like checks being performed on `#[doc(..)]`
3209     /// unlike the other attributes. It'll now catch all the issues that it
3210     /// silently ignored previously.
3211     pub INVALID_DOC_ATTRIBUTES,
3212     Warn,
3213     "detects invalid `#[doc(...)]` attributes",
3214     @future_incompatible = FutureIncompatibleInfo {
3215         reference: "issue #82730 <https://github.com/rust-lang/rust/issues/82730>",
3216     };
3217 }
3218
3219 declare_lint! {
3220     /// The `proc_macro_back_compat` lint detects uses of old versions of certain
3221     /// proc-macro crates, which have hardcoded workarounds in the compiler.
3222     ///
3223     /// ### Example
3224     ///
3225     /// ```rust,ignore (needs-dependency)
3226     ///
3227     /// use time_macros_impl::impl_macros;
3228     /// struct Foo;
3229     /// impl_macros!(Foo);
3230     /// ```
3231     ///
3232     /// This will produce:
3233     ///
3234     /// ```text
3235     /// warning: using an old version of `time-macros-impl`
3236     ///   ::: $DIR/group-compat-hack.rs:27:5
3237     ///    |
3238     /// LL |     impl_macros!(Foo);
3239     ///    |     ------------------ in this macro invocation
3240     ///    |
3241     ///    = note: `#[warn(proc_macro_back_compat)]` on by default
3242     ///    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
3243     ///    = note: for more information, see issue #83125 <https://github.com/rust-lang/rust/issues/83125>
3244     ///    = note: the `time-macros-impl` crate will stop compiling in futures version of Rust. Please update to the latest version of the `time` crate to avoid breakage
3245     ///    = note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
3246     /// ```
3247     ///
3248     /// ### Explanation
3249     ///
3250     /// Eventually, the backwards-compatibility hacks present in the compiler will be removed,
3251     /// causing older versions of certain crates to stop compiling.
3252     /// This is a [future-incompatible] lint to ease the transition to an error.
3253     /// See [issue #83125] for more details.
3254     ///
3255     /// [issue #83125]: https://github.com/rust-lang/rust/issues/83125
3256     /// [future-incompatible]: ../index.md#future-incompatible-lints
3257     pub PROC_MACRO_BACK_COMPAT,
3258     Deny,
3259     "detects usage of old versions of certain proc-macro crates",
3260     @future_incompatible = FutureIncompatibleInfo {
3261         reference: "issue #83125 <https://github.com/rust-lang/rust/issues/83125>",
3262         reason: FutureIncompatibilityReason::FutureReleaseErrorReportNow,
3263     };
3264 }
3265
3266 declare_lint! {
3267     /// The `rust_2021_incompatible_or_patterns` lint detects usage of old versions of or-patterns.
3268     ///
3269     /// ### Example
3270     ///
3271     /// ```rust,compile_fail
3272     /// #![deny(rust_2021_incompatible_or_patterns)]
3273     ///
3274     /// macro_rules! match_any {
3275     ///     ( $expr:expr , $( $( $pat:pat )|+ => $expr_arm:expr ),+ ) => {
3276     ///         match $expr {
3277     ///             $(
3278     ///                 $( $pat => $expr_arm, )+
3279     ///             )+
3280     ///         }
3281     ///     };
3282     /// }
3283     ///
3284     /// fn main() {
3285     ///     let result: Result<i64, i32> = Err(42);
3286     ///     let int: i64 = match_any!(result, Ok(i) | Err(i) => i.into());
3287     ///     assert_eq!(int, 42);
3288     /// }
3289     /// ```
3290     ///
3291     /// {{produces}}
3292     ///
3293     /// ### Explanation
3294     ///
3295     /// In Rust 2021, the `pat` matcher will match additional patterns, which include the `|` character.
3296     pub RUST_2021_INCOMPATIBLE_OR_PATTERNS,
3297     Allow,
3298     "detects usage of old versions of or-patterns",
3299     @future_incompatible = FutureIncompatibleInfo {
3300         reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2021/or-patterns-macro-rules.html>",
3301         reason: FutureIncompatibilityReason::EditionError(Edition::Edition2021),
3302     };
3303 }
3304
3305 declare_lint! {
3306     /// The `rust_2021_prelude_collisions` lint detects the usage of trait methods which are ambiguous
3307     /// with traits added to the prelude in future editions.
3308     ///
3309     /// ### Example
3310     ///
3311     /// ```rust,compile_fail
3312     /// #![deny(rust_2021_prelude_collisions)]
3313     ///
3314     /// trait Foo {
3315     ///     fn try_into(self) -> Result<String, !>;
3316     /// }
3317     ///
3318     /// impl Foo for &str {
3319     ///     fn try_into(self) -> Result<String, !> {
3320     ///         Ok(String::from(self))
3321     ///     }
3322     /// }
3323     ///
3324     /// fn main() {
3325     ///     let x: String = "3".try_into().unwrap();
3326     ///     //                  ^^^^^^^^
3327     ///     // This call to try_into matches both Foo:try_into and TryInto::try_into as
3328     ///     // `TryInto` has been added to the Rust prelude in 2021 edition.
3329     ///     println!("{}", x);
3330     /// }
3331     /// ```
3332     ///
3333     /// {{produces}}
3334     ///
3335     /// ### Explanation
3336     ///
3337     /// In Rust 2021, one of the important introductions is the [prelude changes], which add
3338     /// `TryFrom`, `TryInto`, and `FromIterator` into the standard library's prelude. Since this
3339     /// results in an ambiguity as to which method/function to call when an existing `try_into`
3340     /// method is called via dot-call syntax or a `try_from`/`from_iter` associated function
3341     /// is called directly on a type.
3342     ///
3343     /// [prelude changes]: https://blog.rust-lang.org/inside-rust/2021/03/04/planning-rust-2021.html#prelude-changes
3344     pub RUST_2021_PRELUDE_COLLISIONS,
3345     Allow,
3346     "detects the usage of trait methods which are ambiguous with traits added to the \
3347         prelude in future editions",
3348     @future_incompatible = FutureIncompatibleInfo {
3349         reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2021/prelude.html>",
3350         reason: FutureIncompatibilityReason::EditionError(Edition::Edition2021),
3351     };
3352 }
3353
3354 declare_lint! {
3355     /// The `rust_2021_prefixes_incompatible_syntax` lint detects identifiers that will be parsed as a
3356     /// prefix instead in Rust 2021.
3357     ///
3358     /// ### Example
3359     ///
3360     /// ```rust,edition2018,compile_fail
3361     /// #![deny(rust_2021_prefixes_incompatible_syntax)]
3362     ///
3363     /// macro_rules! m {
3364     ///     (z $x:expr) => ();
3365     /// }
3366     ///
3367     /// m!(z"hey");
3368     /// ```
3369     ///
3370     /// {{produces}}
3371     ///
3372     /// ### Explanation
3373     ///
3374     /// In Rust 2015 and 2018, `z"hey"` is two tokens: the identifier `z`
3375     /// followed by the string literal `"hey"`. In Rust 2021, the `z` is
3376     /// considered a prefix for `"hey"`.
3377     ///
3378     /// This lint suggests to add whitespace between the `z` and `"hey"` tokens
3379     /// to keep them separated in Rust 2021.
3380     // Allow this lint -- rustdoc doesn't yet support threading edition into this lint's parser.
3381     #[allow(rustdoc::invalid_rust_codeblocks)]
3382     pub RUST_2021_PREFIXES_INCOMPATIBLE_SYNTAX,
3383     Allow,
3384     "identifiers that will be parsed as a prefix in Rust 2021",
3385     @future_incompatible = FutureIncompatibleInfo {
3386         reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2021/reserving-syntax.html>",
3387         reason: FutureIncompatibilityReason::EditionError(Edition::Edition2021),
3388     };
3389     crate_level_only
3390 }
3391
3392 declare_lint! {
3393     /// The `unsupported_calling_conventions` lint is output whenever there is a use of the
3394     /// `stdcall`, `fastcall`, `thiscall`, `vectorcall` calling conventions (or their unwind
3395     /// variants) on targets that cannot meaningfully be supported for the requested target.
3396     ///
3397     /// For example `stdcall` does not make much sense for a x86_64 or, more apparently, powerpc
3398     /// code, because this calling convention was never specified for those targets.
3399     ///
3400     /// Historically MSVC toolchains have fallen back to the regular C calling convention for
3401     /// targets other than x86, but Rust doesn't really see a similar need to introduce a similar
3402     /// hack across many more targets.
3403     ///
3404     /// ### Example
3405     ///
3406     /// ```rust,ignore (needs specific targets)
3407     /// extern "stdcall" fn stdcall() {}
3408     /// ```
3409     ///
3410     /// This will produce:
3411     ///
3412     /// ```text
3413     /// warning: use of calling convention not supported on this target
3414     ///   --> $DIR/unsupported.rs:39:1
3415     ///    |
3416     /// LL | extern "stdcall" fn stdcall() {}
3417     ///    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3418     ///    |
3419     ///    = note: `#[warn(unsupported_calling_conventions)]` on by default
3420     ///    = warning: this was previously accepted by the compiler but is being phased out;
3421     ///               it will become a hard error in a future release!
3422     ///    = note: for more information, see issue ...
3423     /// ```
3424     ///
3425     /// ### Explanation
3426     ///
3427     /// On most of the targets the behaviour of `stdcall` and similar calling conventions is not
3428     /// defined at all, but was previously accepted due to a bug in the implementation of the
3429     /// compiler.
3430     pub UNSUPPORTED_CALLING_CONVENTIONS,
3431     Warn,
3432     "use of unsupported calling convention",
3433     @future_incompatible = FutureIncompatibleInfo {
3434         reference: "issue #87678 <https://github.com/rust-lang/rust/issues/87678>",
3435     };
3436 }
3437
3438 declare_lint! {
3439     /// The `break_with_label_and_loop` lint detects labeled `break` expressions with
3440     /// an unlabeled loop as their value expression.
3441     ///
3442     /// ### Example
3443     ///
3444     /// ```rust
3445     /// 'label: loop {
3446     ///     break 'label loop { break 42; };
3447     /// };
3448     /// ```
3449     ///
3450     /// {{produces}}
3451     ///
3452     /// ### Explanation
3453     ///
3454     /// In Rust, loops can have a label, and `break` expressions can refer to that label to
3455     /// break out of specific loops (and not necessarily the innermost one). `break` expressions
3456     /// can also carry a value expression, which can be another loop. A labeled `break` with an
3457     /// unlabeled loop as its value expression is easy to confuse with an unlabeled break with
3458     /// a labeled loop and is thus discouraged (but allowed for compatibility); use parentheses
3459     /// around the loop expression to silence this warning. Unlabeled `break` expressions with
3460     /// labeled loops yield a hard error, which can also be silenced by wrapping the expression
3461     /// in parentheses.
3462     pub BREAK_WITH_LABEL_AND_LOOP,
3463     Warn,
3464     "`break` expression with label and unlabeled loop as value expression"
3465 }
3466
3467 declare_lint! {
3468     /// The `non_exhaustive_omitted_patterns` lint detects when a wildcard (`_` or `..`) in a
3469     /// pattern for a `#[non_exhaustive]` struct or enum is reachable.
3470     ///
3471     /// ### Example
3472     ///
3473     /// ```rust,ignore (needs separate crate)
3474     /// // crate A
3475     /// #[non_exhaustive]
3476     /// pub enum Bar {
3477     ///     A,
3478     ///     B, // added variant in non breaking change
3479     /// }
3480     ///
3481     /// // in crate B
3482     /// #![feature(non_exhaustive_omitted_patterns_lint)]
3483     ///
3484     /// match Bar::A {
3485     ///     Bar::A => {},
3486     ///     #[warn(non_exhaustive_omitted_patterns)]
3487     ///     _ => {},
3488     /// }
3489     /// ```
3490     ///
3491     /// This will produce:
3492     ///
3493     /// ```text
3494     /// warning: reachable patterns not covered of non exhaustive enum
3495     ///    --> $DIR/reachable-patterns.rs:70:9
3496     ///    |
3497     /// LL |         _ => {}
3498     ///    |         ^ pattern `B` not covered
3499     ///    |
3500     ///  note: the lint level is defined here
3501     ///   --> $DIR/reachable-patterns.rs:69:16
3502     ///    |
3503     /// LL |         #[warn(non_exhaustive_omitted_patterns)]
3504     ///    |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3505     ///    = help: ensure that all possible cases are being handled by adding the suggested match arms
3506     ///    = note: the matched value is of type `Bar` and the `non_exhaustive_omitted_patterns` attribute was found
3507     /// ```
3508     ///
3509     /// ### Explanation
3510     ///
3511     /// Structs and enums tagged with `#[non_exhaustive]` force the user to add a
3512     /// (potentially redundant) wildcard when pattern-matching, to allow for future
3513     /// addition of fields or variants. The `non_exhaustive_omitted_patterns` lint
3514     /// detects when such a wildcard happens to actually catch some fields/variants.
3515     /// In other words, when the match without the wildcard would not be exhaustive.
3516     /// This lets the user be informed if new fields/variants were added.
3517     pub NON_EXHAUSTIVE_OMITTED_PATTERNS,
3518     Allow,
3519     "detect when patterns of types marked `non_exhaustive` are missed",
3520     @feature_gate = sym::non_exhaustive_omitted_patterns_lint;
3521 }
3522
3523 declare_lint! {
3524     /// The `text_direction_codepoint_in_comment` lint detects Unicode codepoints in comments that
3525     /// change the visual representation of text on screen in a way that does not correspond to
3526     /// their on memory representation.
3527     ///
3528     /// ### Example
3529     ///
3530     /// ```rust,compile_fail
3531     /// #![deny(text_direction_codepoint_in_comment)]
3532     /// fn main() {
3533     ///     println!("{:?}"); // '‮');
3534     /// }
3535     /// ```
3536     ///
3537     /// {{produces}}
3538     ///
3539     /// ### Explanation
3540     ///
3541     /// Unicode allows changing the visual flow of text on screen in order to support scripts that
3542     /// are written right-to-left, but a specially crafted comment can make code that will be
3543     /// compiled appear to be part of a comment, depending on the software used to read the code.
3544     /// To avoid potential problems or confusion, such as in CVE-2021-42574, by default we deny
3545     /// their use.
3546     pub TEXT_DIRECTION_CODEPOINT_IN_COMMENT,
3547     Deny,
3548     "invisible directionality-changing codepoints in comment"
3549 }
3550
3551 declare_lint! {
3552     /// The `deref_into_dyn_supertrait` lint is output whenever there is a use of the
3553     /// `Deref` implementation with a `dyn SuperTrait` type as `Output`.
3554     ///
3555     /// These implementations will become shadowed when the `trait_upcasting` feature is stablized.
3556     /// The `deref` functions will no longer be called implicitly, so there might be behavior change.
3557     ///
3558     /// ### Example
3559     ///
3560     /// ```rust,compile_fail
3561     /// #![deny(deref_into_dyn_supertrait)]
3562     /// #![allow(dead_code)]
3563     ///
3564     /// use core::ops::Deref;
3565     ///
3566     /// trait A {}
3567     /// trait B: A {}
3568     /// impl<'a> Deref for dyn 'a + B {
3569     ///     type Target = dyn A;
3570     ///     fn deref(&self) -> &Self::Target {
3571     ///         todo!()
3572     ///     }
3573     /// }
3574     ///
3575     /// fn take_a(_: &dyn A) { }
3576     ///
3577     /// fn take_b(b: &dyn B) {
3578     ///     take_a(b);
3579     /// }
3580     /// ```
3581     ///
3582     /// {{produces}}
3583     ///
3584     /// ### Explanation
3585     ///
3586     /// The dyn upcasting coercion feature adds new coercion rules, taking priority
3587     /// over certain other coercion rules, which will cause some behavior change.
3588     pub DEREF_INTO_DYN_SUPERTRAIT,
3589     Warn,
3590     "`Deref` implementation usage with a supertrait trait object for output might be shadowed in the future",
3591     @future_incompatible = FutureIncompatibleInfo {
3592         reference: "issue #89460 <https://github.com/rust-lang/rust/issues/89460>",
3593     };
3594 }
3595
3596 declare_lint! {
3597     /// The `duplicate_macro_attributes` lint detects when a `#[test]`-like built-in macro
3598     /// attribute is duplicated on an item. This lint may trigger on `bench`, `cfg_eval`, `test`
3599     /// and `test_case`.
3600     ///
3601     /// ### Example
3602     ///
3603     /// ```rust,ignore (needs --test)
3604     /// #[test]
3605     /// #[test]
3606     /// fn foo() {}
3607     /// ```
3608     ///
3609     /// This will produce:
3610     ///
3611     /// ```text
3612     /// warning: duplicated attribute
3613     ///  --> src/lib.rs:2:1
3614     ///   |
3615     /// 2 | #[test]
3616     ///   | ^^^^^^^
3617     ///   |
3618     ///   = note: `#[warn(duplicate_macro_attributes)]` on by default
3619     /// ```
3620     ///
3621     /// ### Explanation
3622     ///
3623     /// A duplicated attribute may erroneously originate from a copy-paste and the effect of it
3624     /// being duplicated may not be obvious or desireable.
3625     ///
3626     /// For instance, doubling the `#[test]` attributes registers the test to be run twice with no
3627     /// change to its environment.
3628     ///
3629     /// [issue #90979]: https://github.com/rust-lang/rust/issues/90979
3630     pub DUPLICATE_MACRO_ATTRIBUTES,
3631     Warn,
3632     "duplicated attribute"
3633 }
3634
3635 declare_lint! {
3636     /// The `suspicious_auto_trait_impls` lint checks for potentially incorrect
3637     /// implementations of auto traits.
3638     ///
3639     /// ### Example
3640     ///
3641     /// ```rust
3642     /// struct Foo<T>(T);
3643     ///
3644     /// unsafe impl<T> Send for Foo<*const T> {}
3645     /// ```
3646     ///
3647     /// {{produces}}
3648     ///
3649     /// ### Explanation
3650     ///
3651     /// A type can implement auto traits, e.g. `Send`, `Sync` and `Unpin`,
3652     /// in two different ways: either by writing an explicit impl or if
3653     /// all fields of the type implement that auto trait.
3654     ///
3655     /// The compiler disables the automatic implementation if an explicit one
3656     /// exists for given type constructor. The exact rules governing this
3657     /// are currently unsound and quite subtle and and will be modified in the future.
3658     /// This change will cause the automatic implementation to be disabled in more
3659     /// cases, potentially breaking some code.
3660     pub SUSPICIOUS_AUTO_TRAIT_IMPLS,
3661     Warn,
3662     "the rules governing auto traits will change in the future",
3663     @future_incompatible = FutureIncompatibleInfo {
3664         reason: FutureIncompatibilityReason::FutureReleaseSemanticsChange,
3665         reference: "issue #93367 <https://github.com/rust-lang/rust/issues/93367>",
3666     };
3667 }