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