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     /// #![deny(warnings)]
 337     /// extern crate proc_macro;
 338     /// ```
 339     ///
 340     /// {{produces}}
 341     ///
 342     /// ### Explanation
 343     ///
 344     /// `extern crate` items that are unused have no effect and should be
 345     /// removed. Note that there are some cases where specifying an `extern
 346     /// crate` is desired for the side effect of ensuring the given crate is
 347     /// linked, even though it is not otherwise directly referenced. The lint
 348     /// can be silenced by aliasing the crate to an underscore, such as
 349     /// `extern crate foo as _`. Also note that it is no longer idiomatic to
 350     /// use `extern crate` in the [2018 edition], as extern crates are now
 351     /// automatically added in scope.
 352     ///
 353     /// This lint is "allow" by default because it can be noisy, and produce
 354     /// false-positives. If a dependency is being removed from a project, it
 355     /// is recommended to remove it from the build configuration (such as
 356     /// `Cargo.toml`) to ensure stale build entries aren't left behind.
 357     ///
 358     /// [2018 edition]: https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html#no-more-extern-crate
 359     pub UNUSED_EXTERN_CRATES,
 360     Allow,
 361     "extern crates that are never used"
 362 }
 363
 364 declare_lint! {
 365     /// The `unused_crate_dependencies` lint detects crate dependencies that
 366     /// are never used.
 367     ///
 368     /// ### Example
 369     ///
 370     /// ```rust,ignore (needs extern crate)
 371     /// #![deny(unused_crate_dependencies)]
 372     /// ```
 373     ///
 374     /// This will produce:
 375     ///
 376     /// ```text
 377     /// error: external crate `regex` unused in `lint_example`: remove the dependency or add `use regex as _;`
 378     ///   |
 379     /// note: the lint level is defined here
 380     ///  --> src/lib.rs:1:9
 381     ///   |
 382     /// 1 | #![deny(unused_crate_dependencies)]
 383     ///   |         ^^^^^^^^^^^^^^^^^^^^^^^^^
 384     /// ```
 385     ///
 386     /// ### Explanation
 387     ///
 388     /// After removing the code that uses a dependency, this usually also
 389     /// requires removing the dependency from the build configuration.
 390     /// However, sometimes that step can be missed, which leads to time wasted
 391     /// building dependencies that are no longer used. This lint can be
 392     /// enabled to detect dependencies that are never used (more specifically,
 393     /// any dependency passed with the `--extern` command-line flag that is
 394     /// never referenced via [`use`], [`extern crate`], or in any [path]).
 395     ///
 396     /// This lint is "allow" by default because it can provide false positives
 397     /// depending on how the build system is configured. For example, when
 398     /// using Cargo, a "package" consists of multiple crates (such as a
 399     /// library and a binary), but the dependencies are defined for the
 400     /// package as a whole. If there is a dependency that is only used in the
 401     /// binary, but not the library, then the lint will be incorrectly issued
 402     /// in the library.
 403     ///
 404     /// [path]: https://doc.rust-lang.org/reference/paths.html
 405     /// [`use`]: https://doc.rust-lang.org/reference/items/use-declarations.html
 406     /// [`extern crate`]: https://doc.rust-lang.org/reference/items/extern-crates.html
 407     pub UNUSED_CRATE_DEPENDENCIES,
 408     Allow,
 409     "crate dependencies that are never used",
 410     crate_level_only
 411 }
 412
 413 declare_lint! {
 414     /// The `unused_qualifications` lint detects unnecessarily qualified
 415     /// names.
 416     ///
 417     /// ### Example
 418     ///
 419     /// ```rust,compile_fail
 420     /// #![deny(unused_qualifications)]
 421     /// mod foo {
 422     ///     pub fn bar() {}
 423     /// }
 424     ///
 425     /// fn main() {
 426     ///     use foo::bar;
 427     ///     foo::bar();
 428     /// }
 429     /// ```
 430     ///
 431     /// {{produces}}
 432     ///
 433     /// ### Explanation
 434     ///
 435     /// If an item from another module is already brought into scope, then
 436     /// there is no need to qualify it in this case. You can call `bar()`
 437     /// directly, without the `foo::`.
 438     ///
 439     /// This lint is "allow" by default because it is somewhat pedantic, and
 440     /// doesn't indicate an actual problem, but rather a stylistic choice, and
 441     /// can be noisy when refactoring or moving around code.
 442     pub UNUSED_QUALIFICATIONS,
 443     Allow,
 444     "detects unnecessarily qualified names"
 445 }
 446
 447 declare_lint! {
 448     /// The `unknown_lints` lint detects unrecognized lint attributes.
 449     ///
 450     /// ### Example
 451     ///
 452     /// ```rust
 453     /// #![allow(not_a_real_lint)]
 454     /// ```
 455     ///
 456     /// {{produces}}
 457     ///
 458     /// ### Explanation
 459     ///
 460     /// It is usually a mistake to specify a lint that does not exist. Check
 461     /// the spelling, and check the lint listing for the correct name. Also
 462     /// consider if you are using an old version of the compiler, and the lint
 463     /// is only available in a newer version.
 464     pub UNKNOWN_LINTS,
 465     Warn,
 466     "unrecognized lint attribute"
 467 }
 468
 469 declare_lint! {
 470     /// The `unfulfilled_lint_expectations` lint detects lint trigger expectations
 471     /// that have not been fulfilled.
 472     ///
 473     /// ### Example
 474     ///
 475     /// ```rust
 476     /// #![feature(lint_reasons)]
 477     ///
 478     /// #[expect(unused_variables)]
 479     /// let x = 10;
 480     /// println!("{}", x);
 481     /// ```
 482     ///
 483     /// {{produces}}
 484     ///
 485     /// ### Explanation
 486     ///
 487     /// It was expected that the marked code would emit a lint. This expectation
 488     /// has not been fulfilled.
 489     ///
 490     /// The `expect` attribute can be removed if this is intended behavior otherwise
 491     /// it should be investigated why the expected lint is no longer issued.
 492     ///
 493     /// In rare cases, the expectation might be emitted at a different location than
 494     /// shown in the shown code snippet. In most cases, the `#[expect]` attribute
 495     /// works when added to the outer scope. A few lints can only be expected
 496     /// on a crate level.
 497     ///
 498     /// Part of RFC 2383. The progress is being tracked in [#54503]
 499     ///
 500     /// [#54503]: https://github.com/rust-lang/rust/issues/54503
 501     pub UNFULFILLED_LINT_EXPECTATIONS,
 502     Warn,
 503     "unfulfilled lint expectation",
 504     @feature_gate = rustc_span::sym::lint_reasons;
 505 }
 506
 507 declare_lint! {
 508     /// The `unused_variables` lint detects variables which are not used in
 509     /// any way.
 510     ///
 511     /// ### Example
 512     ///
 513     /// ```rust
 514     /// let x = 5;
 515     /// ```
 516     ///
 517     /// {{produces}}
 518     ///
 519     /// ### Explanation
 520     ///
 521     /// Unused variables may signal a mistake or unfinished code. To silence
 522     /// the warning for the individual variable, prefix it with an underscore
 523     /// such as `_x`.
 524     pub UNUSED_VARIABLES,
 525     Warn,
 526     "detect variables which are not used in any way"
 527 }
 528
 529 declare_lint! {
 530     /// The `unused_assignments` lint detects assignments that will never be read.
 531     ///
 532     /// ### Example
 533     ///
 534     /// ```rust
 535     /// let mut x = 5;
 536     /// x = 6;
 537     /// ```
 538     ///
 539     /// {{produces}}
 540     ///
 541     /// ### Explanation
 542     ///
 543     /// Unused assignments may signal a mistake or unfinished code. If the
 544     /// variable is never used after being assigned, then the assignment can
 545     /// be removed. Variables with an underscore prefix such as `_x` will not
 546     /// trigger this lint.
 547     pub UNUSED_ASSIGNMENTS,
 548     Warn,
 549     "detect assignments that will never be read"
 550 }
 551
 552 declare_lint! {
 553     /// The `dead_code` lint detects unused, unexported items.
 554     ///
 555     /// ### Example
 556     ///
 557     /// ```rust
 558     /// fn foo() {}
 559     /// ```
 560     ///
 561     /// {{produces}}
 562     ///
 563     /// ### Explanation
 564     ///
 565     /// Dead code may signal a mistake or unfinished code. To silence the
 566     /// warning for individual items, prefix the name with an underscore such
 567     /// as `_foo`. If it was intended to expose the item outside of the crate,
 568     /// consider adding a visibility modifier like `pub`. Otherwise consider
 569     /// removing the unused code.
 570     pub DEAD_CODE,
 571     Warn,
 572     "detect unused, unexported items"
 573 }
 574
 575 declare_lint! {
 576     /// The `unused_attributes` lint detects attributes that were not used by
 577     /// the compiler.
 578     ///
 579     /// ### Example
 580     ///
 581     /// ```rust
 582     /// #![ignore]
 583     /// ```
 584     ///
 585     /// {{produces}}
 586     ///
 587     /// ### Explanation
 588     ///
 589     /// Unused [attributes] may indicate the attribute is placed in the wrong
 590     /// position. Consider removing it, or placing it in the correct position.
 591     /// Also consider if you intended to use an _inner attribute_ (with a `!`
 592     /// such as `#![allow(unused)]`) which applies to the item the attribute
 593     /// is within, or an _outer attribute_ (without a `!` such as
 594     /// `#[allow(unused)]`) which applies to the item *following* the
 595     /// attribute.
 596     ///
 597     /// [attributes]: https://doc.rust-lang.org/reference/attributes.html
 598     pub UNUSED_ATTRIBUTES,
 599     Warn,
 600     "detects attributes that were not used by the compiler"
 601 }
 602
 603 declare_lint! {
 604     /// The `unused_tuple_struct_fields` lint detects fields of tuple structs
 605     /// that are never read.
 606     ///
 607     /// ### Example
 608     ///
 609     /// ```rust
 610     /// #[warn(unused_tuple_struct_fields)]
 611     /// struct S(i32, i32, i32);
 612     /// let s = S(1, 2, 3);
 613     /// let _ = (s.0, s.2);
 614     /// ```
 615     ///
 616     /// {{produces}}
 617     ///
 618     /// ### Explanation
 619     ///
 620     /// Tuple struct fields that are never read anywhere may indicate a
 621     /// mistake or unfinished code. To silence this warning, consider
 622     /// removing the unused field(s) or, to preserve the numbering of the
 623     /// remaining fields, change the unused field(s) to have unit type.
 624     pub UNUSED_TUPLE_STRUCT_FIELDS,
 625     Allow,
 626     "detects tuple struct fields that are never read"
 627 }
 628
 629 declare_lint! {
 630     /// The `unreachable_code` lint detects unreachable code paths.
 631     ///
 632     /// ### Example
 633     ///
 634     /// ```rust,no_run
 635     /// panic!("we never go past here!");
 636     ///
 637     /// let x = 5;
 638     /// ```
 639     ///
 640     /// {{produces}}
 641     ///
 642     /// ### Explanation
 643     ///
 644     /// Unreachable code may signal a mistake or unfinished code. If the code
 645     /// is no longer in use, consider removing it.
 646     pub UNREACHABLE_CODE,
 647     Warn,
 648     "detects unreachable code paths",
 649     report_in_external_macro
 650 }
 651
 652 declare_lint! {
 653     /// The `unreachable_patterns` lint detects unreachable patterns.
 654     ///
 655     /// ### Example
 656     ///
 657     /// ```rust
 658     /// let x = 5;
 659     /// match x {
 660     ///     y => (),
 661     ///     5 => (),
 662     /// }
 663     /// ```
 664     ///
 665     /// {{produces}}
 666     ///
 667     /// ### Explanation
 668     ///
 669     /// This usually indicates a mistake in how the patterns are specified or
 670     /// ordered. In this example, the `y` pattern will always match, so the
 671     /// five is impossible to reach. Remember, match arms match in order, you
 672     /// probably wanted to put the `5` case above the `y` case.
 673     pub UNREACHABLE_PATTERNS,
 674     Warn,
 675     "detects unreachable patterns"
 676 }
 677
 678 declare_lint! {
 679     /// The `overlapping_range_endpoints` lint detects `match` arms that have [range patterns] that
 680     /// overlap on their endpoints.
 681     ///
 682     /// [range patterns]: https://doc.rust-lang.org/nightly/reference/patterns.html#range-patterns
 683     ///
 684     /// ### Example
 685     ///
 686     /// ```rust
 687     /// let x = 123u8;
 688     /// match x {
 689     ///     0..=100 => { println!("small"); }
 690     ///     100..=255 => { println!("large"); }
 691     /// }
 692     /// ```
 693     ///
 694     /// {{produces}}
 695     ///
 696     /// ### Explanation
 697     ///
 698     /// It is likely a mistake to have range patterns in a match expression that overlap in this
 699     /// way. Check that the beginning and end values are what you expect, and keep in mind that
 700     /// with `..=` the left and right bounds are inclusive.
 701     pub OVERLAPPING_RANGE_ENDPOINTS,
 702     Warn,
 703     "detects range patterns with overlapping endpoints"
 704 }
 705
 706 declare_lint! {
 707     /// The `bindings_with_variant_name` lint detects pattern bindings with
 708     /// the same name as one of the matched variants.
 709     ///
 710     /// ### Example
 711     ///
 712     /// ```rust,compile_fail
 713     /// pub enum Enum {
 714     ///     Foo,
 715     ///     Bar,
 716     /// }
 717     ///
 718     /// pub fn foo(x: Enum) {
 719     ///     match x {
 720     ///         Foo => {}
 721     ///         Bar => {}
 722     ///     }
 723     /// }
 724     /// ```
 725     ///
 726     /// {{produces}}
 727     ///
 728     /// ### Explanation
 729     ///
 730     /// It is usually a mistake to specify an enum variant name as an
 731     /// [identifier pattern]. In the example above, the `match` arms are
 732     /// specifying a variable name to bind the value of `x` to. The second arm
 733     /// is ignored because the first one matches *all* values. The likely
 734     /// intent is that the arm was intended to match on the enum variant.
 735     ///
 736     /// Two possible solutions are:
 737     ///
 738     /// * Specify the enum variant using a [path pattern], such as
 739     ///   `Enum::Foo`.
 740     /// * Bring the enum variants into local scope, such as adding `use
 741     ///   Enum::*;` to the beginning of the `foo` function in the example
 742     ///   above.
 743     ///
 744     /// [identifier pattern]: https://doc.rust-lang.org/reference/patterns.html#identifier-patterns
 745     /// [path pattern]: https://doc.rust-lang.org/reference/patterns.html#path-patterns
 746     pub BINDINGS_WITH_VARIANT_NAME,
 747     Deny,
 748     "detects pattern bindings with the same name as one of the matched variants"
 749 }
 750
 751 declare_lint! {
 752     /// The `unused_macros` lint detects macros that were not used.
 753     ///
 754     /// Note that this lint is distinct from the `unused_macro_rules` lint,
 755     /// which checks for single rules that never match of an otherwise used
 756     /// macro, and thus never expand.
 757     ///
 758     /// ### Example
 759     ///
 760     /// ```rust
 761     /// macro_rules! unused {
 762     ///     () => {};
 763     /// }
 764     ///
 765     /// fn main() {
 766     /// }
 767     /// ```
 768     ///
 769     /// {{produces}}
 770     ///
 771     /// ### Explanation
 772     ///
 773     /// Unused macros may signal a mistake or unfinished code. To silence the
 774     /// warning for the individual macro, prefix the name with an underscore
 775     /// such as `_my_macro`. If you intended to export the macro to make it
 776     /// available outside of the crate, use the [`macro_export` attribute].
 777     ///
 778     /// [`macro_export` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
 779     pub UNUSED_MACROS,
 780     Warn,
 781     "detects macros that were not used"
 782 }
 783
 784 declare_lint! {
 785     /// The `unused_macro_rules` lint detects macro rules that were not used.
 786     ///
 787     /// Note that the lint is distinct from the `unused_macros` lint, which
 788     /// fires if the entire macro is never called, while this lint fires for
 789     /// single unused rules of the macro that is otherwise used.
 790     /// `unused_macro_rules` fires only if `unused_macros` wouldn't fire.
 791     ///
 792     /// ### Example
 793     ///
 794     /// ```rust
 795     /// #[warn(unused_macro_rules)]
 796     /// macro_rules! unused_empty {
 797     ///     (hello) => { println!("Hello, world!") }; // This rule is unused
 798     ///     () => { println!("empty") }; // This rule is used
 799     /// }
 800     ///
 801     /// fn main() {
 802     ///     unused_empty!(hello);
 803     /// }
 804     /// ```
 805     ///
 806     /// {{produces}}
 807     ///
 808     /// ### Explanation
 809     ///
 810     /// Unused macro rules may signal a mistake or unfinished code. Furthermore,
 811     /// they slow down compilation. Right now, silencing the warning is not
 812     /// supported on a single rule level, so you have to add an allow to the
 813     /// entire macro definition.
 814     ///
 815     /// If you intended to export the macro to make it
 816     /// available outside of the crate, use the [`macro_export` attribute].
 817     ///
 818     /// [`macro_export` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
 819     pub UNUSED_MACRO_RULES,
 820     Allow,
 821     "detects macro rules that were not used"
 822 }
 823
 824 declare_lint! {
 825     /// The `warnings` lint allows you to change the level of other
 826     /// lints which produce warnings.
 827     ///
 828     /// ### Example
 829     ///
 830     /// ```rust
 831     /// #![deny(warnings)]
 832     /// fn foo() {}
 833     /// ```
 834     ///
 835     /// {{produces}}
 836     ///
 837     /// ### Explanation
 838     ///
 839     /// The `warnings` lint is a bit special; by changing its level, you
 840     /// change every other warning that would produce a warning to whatever
 841     /// value you'd like. As such, you won't ever trigger this lint in your
 842     /// code directly.
 843     pub WARNINGS,
 844     Warn,
 845     "mass-change the level for lints which produce warnings"
 846 }
 847
 848 declare_lint! {
 849     /// The `unused_features` lint detects unused or unknown features found in
 850     /// crate-level [`feature` attributes].
 851     ///
 852     /// [`feature` attributes]: https://doc.rust-lang.org/nightly/unstable-book/
 853     ///
 854     /// Note: This lint is currently not functional, see [issue #44232] for
 855     /// more details.
 856     ///
 857     /// [issue #44232]: https://github.com/rust-lang/rust/issues/44232
 858     pub UNUSED_FEATURES,
 859     Warn,
 860     "unused features found in crate-level `#[feature]` directives"
 861 }
 862
 863 declare_lint! {
 864     /// The `stable_features` lint detects a [`feature` attribute] that
 865     /// has since been made stable.
 866     ///
 867     /// [`feature` attribute]: https://doc.rust-lang.org/nightly/unstable-book/
 868     ///
 869     /// ### Example
 870     ///
 871     /// ```rust
 872     /// #![feature(test_accepted_feature)]
 873     /// fn main() {}
 874     /// ```
 875     ///
 876     /// {{produces}}
 877     ///
 878     /// ### Explanation
 879     ///
 880     /// When a feature is stabilized, it is no longer necessary to include a
 881     /// `#![feature]` attribute for it. To fix, simply remove the
 882     /// `#![feature]` attribute.
 883     pub STABLE_FEATURES,
 884     Warn,
 885     "stable features found in `#[feature]` directive"
 886 }
 887
 888 declare_lint! {
 889     /// The `unknown_crate_types` lint detects an unknown crate type found in
 890     /// a [`crate_type` attribute].
 891     ///
 892     /// ### Example
 893     ///
 894     /// ```rust,compile_fail
 895     /// #![crate_type="lol"]
 896     /// fn main() {}
 897     /// ```
 898     ///
 899     /// {{produces}}
 900     ///
 901     /// ### Explanation
 902     ///
 903     /// An unknown value give to the `crate_type` attribute is almost
 904     /// certainly a mistake.
 905     ///
 906     /// [`crate_type` attribute]: https://doc.rust-lang.org/reference/linkage.html
 907     pub UNKNOWN_CRATE_TYPES,
 908     Deny,
 909     "unknown crate type found in `#[crate_type]` directive",
 910     crate_level_only
 911 }
 912
 913 declare_lint! {
 914     /// The `trivial_casts` lint detects trivial casts which could be replaced
 915     /// with coercion, which may require a temporary 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 an explicit syntax for coercions
 938     /// providing a convenient way to work around the current issues.
 939     /// See [RFC 401 (coercions)][rfc-401], [RFC 803 (type ascription)][rfc-803] and
 940     /// [RFC 3307 (remove type ascription)][rfc-3307] for historical context.
 941     ///
 942     /// [rfc-401]: https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md
 943     /// [rfc-803]: https://github.com/rust-lang/rfcs/blob/master/text/0803-type-ascription.md
 944     /// [rfc-3307]: https://github.com/rust-lang/rfcs/blob/master/text/3307-de-rfc-type-ascription.md
 945     pub TRIVIAL_CASTS,
 946     Allow,
 947     "detects trivial casts which could be removed"
 948 }
 949
 950 declare_lint! {
 951     /// The `trivial_numeric_casts` lint detects trivial numeric casts of types
 952     /// which could be removed.
 953     ///
 954     /// ### Example
 955     ///
 956     /// ```rust,compile_fail
 957     /// #![deny(trivial_numeric_casts)]
 958     /// let x = 42_i32 as i32;
 959     /// ```
 960     ///
 961     /// {{produces}}
 962     ///
 963     /// ### Explanation
 964     ///
 965     /// A trivial numeric cast is a cast of a numeric type to the same numeric
 966     /// type. This type of cast is usually unnecessary.
 967     ///
 968     /// This lint is "allow" by default because there are situations, such as
 969     /// with FFI interfaces or complex type aliases, where it triggers
 970     /// incorrectly, or in situations where it will be more difficult to
 971     /// clearly express the intent. It may be possible that this will become a
 972     /// warning in the future, possibly with an explicit syntax for coercions
 973     /// providing a convenient way to work around the current issues.
 974     /// See [RFC 401 (coercions)][rfc-401], [RFC 803 (type ascription)][rfc-803] and
 975     /// [RFC 3307 (remove type ascription)][rfc-3307] for historical context.
 976     ///
 977     /// [rfc-401]: https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md
 978     /// [rfc-803]: https://github.com/rust-lang/rfcs/blob/master/text/0803-type-ascription.md
 979     /// [rfc-3307]: https://github.com/rust-lang/rfcs/blob/master/text/3307-de-rfc-type-ascription.md
 980     pub TRIVIAL_NUMERIC_CASTS,
 981     Allow,
 982     "detects trivial casts of numeric types which could be removed"
 983 }
 984
 985 declare_lint! {
 986     /// The `private_in_public` lint detects private items in public
 987     /// interfaces not caught by the old implementation.
 988     ///
 989     /// ### Example
 990     ///
 991     /// ```rust
 992     /// # #![allow(unused)]
 993     /// struct SemiPriv;
 994     ///
 995     /// mod m1 {
 996     ///     struct Priv;
 997     ///     impl super::SemiPriv {
 998     ///         pub fn f(_: Priv) {}
 999     ///     }
1000     /// }
1001     /// # fn main() {}
1002     /// ```
1003     ///
1004     /// {{produces}}
1005     ///
1006     /// ### Explanation
1007     ///
1008     /// The visibility rules are intended to prevent exposing private items in
1009     /// public interfaces. This is a [future-incompatible] lint to transition
1010     /// this to a hard error in the future. See [issue #34537] for more
1011     /// details.
1012     ///
1013     /// [issue #34537]: https://github.com/rust-lang/rust/issues/34537
1014     /// [future-incompatible]: ../index.md#future-incompatible-lints
1015     pub PRIVATE_IN_PUBLIC,
1016     Warn,
1017     "detect private items in public interfaces not caught by the old implementation",
1018     @future_incompatible = FutureIncompatibleInfo {
1019         reference: "issue #34537 <https://github.com/rust-lang/rust/issues/34537>",
1020     };
1021 }
1022
1023 declare_lint! {
1024     /// The `invalid_alignment` lint detects dereferences of misaligned pointers during
1025     /// constant evaluation.
1026     ///
1027     /// ### Example
1028     ///
1029     /// ```rust,compile_fail
1030     /// #![feature(const_mut_refs)]
1031     /// const FOO: () = unsafe {
1032     ///     let x = &[0_u8; 4];
1033     ///     let y = x.as_ptr().cast::<u32>();
1034     ///     let mut z = 123;
1035     ///     y.copy_to_nonoverlapping(&mut z, 1); // the address of a `u8` array is unknown
1036     ///     // and thus we don't know if it is aligned enough for copying a `u32`.
1037     /// };
1038     /// ```
1039     ///
1040     /// {{produces}}
1041     ///
1042     /// ### Explanation
1043     ///
1044     /// The compiler allowed dereferencing raw pointers irrespective of alignment
1045     /// during const eval due to the const evaluator at the time not making it easy
1046     /// or cheap to check. Now that it is both, this is not accepted anymore.
1047     ///
1048     /// Since it was undefined behaviour to begin with, this breakage does not violate
1049     /// Rust's stability guarantees. Using undefined behaviour can cause arbitrary
1050     /// behaviour, including failure to build.
1051     ///
1052     /// [future-incompatible]: ../index.md#future-incompatible-lints
1053     pub INVALID_ALIGNMENT,
1054     Deny,
1055     "raw pointers must be aligned before dereferencing",
1056     @future_incompatible = FutureIncompatibleInfo {
1057         reference: "issue #68585 <https://github.com/rust-lang/rust/issues/104616>",
1058         reason: FutureIncompatibilityReason::FutureReleaseErrorReportNow,
1059     };
1060 }
1061
1062 declare_lint! {
1063     /// The `exported_private_dependencies` lint detects private dependencies
1064     /// that are exposed in a public interface.
1065     ///
1066     /// ### Example
1067     ///
1068     /// ```rust,ignore (needs-dependency)
1069     /// pub fn foo() -> Option<some_private_dependency::Thing> {
1070     ///     None
1071     /// }
1072     /// ```
1073     ///
1074     /// This will produce:
1075     ///
1076     /// ```text
1077     /// warning: type `bar::Thing` from private dependency 'bar' in public interface
1078     ///  --> src/lib.rs:3:1
1079     ///   |
1080     /// 3 | pub fn foo() -> Option<bar::Thing> {
1081     ///   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1082     ///   |
1083     ///   = note: `#[warn(exported_private_dependencies)]` on by default
1084     /// ```
1085     ///
1086     /// ### Explanation
1087     ///
1088     /// Dependencies can be marked as "private" to indicate that they are not
1089     /// exposed in the public interface of a crate. This can be used by Cargo
1090     /// to independently resolve those dependencies because it can assume it
1091     /// does not need to unify them with other packages using that same
1092     /// dependency. This lint is an indication of a violation of that
1093     /// contract.
1094     ///
1095     /// To fix this, avoid exposing the dependency in your public interface.
1096     /// Or, switch the dependency to a public dependency.
1097     ///
1098     /// Note that support for this is only available on the nightly channel.
1099     /// See [RFC 1977] for more details, as well as the [Cargo documentation].
1100     ///
1101     /// [RFC 1977]: https://github.com/rust-lang/rfcs/blob/master/text/1977-public-private-dependencies.md
1102     /// [Cargo documentation]: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#public-dependency
1103     pub EXPORTED_PRIVATE_DEPENDENCIES,
1104     Warn,
1105     "public interface leaks type from a private dependency"
1106 }
1107
1108 declare_lint! {
1109     /// The `pub_use_of_private_extern_crate` lint detects a specific
1110     /// situation of re-exporting a private `extern crate`.
1111     ///
1112     /// ### Example
1113     ///
1114     /// ```rust,compile_fail
1115     /// extern crate core;
1116     /// pub use core as reexported_core;
1117     /// ```
1118     ///
1119     /// {{produces}}
1120     ///
1121     /// ### Explanation
1122     ///
1123     /// A public `use` declaration should not be used to publicly re-export a
1124     /// private `extern crate`. `pub extern crate` should be used instead.
1125     ///
1126     /// This was historically allowed, but is not the intended behavior
1127     /// according to the visibility rules. This is a [future-incompatible]
1128     /// lint to transition this to a hard error in the future. See [issue
1129     /// #34537] for more details.
1130     ///
1131     /// [issue #34537]: https://github.com/rust-lang/rust/issues/34537
1132     /// [future-incompatible]: ../index.md#future-incompatible-lints
1133     pub PUB_USE_OF_PRIVATE_EXTERN_CRATE,
1134     Deny,
1135     "detect public re-exports of private extern crates",
1136     @future_incompatible = FutureIncompatibleInfo {
1137         reference: "issue #34537 <https://github.com/rust-lang/rust/issues/34537>",
1138     };
1139 }
1140
1141 declare_lint! {
1142     /// The `invalid_type_param_default` lint detects type parameter defaults
1143     /// erroneously allowed in an invalid location.
1144     ///
1145     /// ### Example
1146     ///
1147     /// ```rust,compile_fail
1148     /// fn foo<T=i32>(t: T) {}
1149     /// ```
1150     ///
1151     /// {{produces}}
1152     ///
1153     /// ### Explanation
1154     ///
1155     /// Default type parameters were only intended to be allowed in certain
1156     /// situations, but historically the compiler allowed them everywhere.
1157     /// This is a [future-incompatible] lint to transition this to a hard
1158     /// error in the future. See [issue #36887] for more details.
1159     ///
1160     /// [issue #36887]: https://github.com/rust-lang/rust/issues/36887
1161     /// [future-incompatible]: ../index.md#future-incompatible-lints
1162     pub INVALID_TYPE_PARAM_DEFAULT,
1163     Deny,
1164     "type parameter default erroneously allowed in invalid location",
1165     @future_incompatible = FutureIncompatibleInfo {
1166         reference: "issue #36887 <https://github.com/rust-lang/rust/issues/36887>",
1167     };
1168 }
1169
1170 declare_lint! {
1171     /// The `renamed_and_removed_lints` lint detects lints that have been
1172     /// renamed or removed.
1173     ///
1174     /// ### Example
1175     ///
1176     /// ```rust
1177     /// #![deny(raw_pointer_derive)]
1178     /// ```
1179     ///
1180     /// {{produces}}
1181     ///
1182     /// ### Explanation
1183     ///
1184     /// To fix this, either remove the lint or use the new name. This can help
1185     /// avoid confusion about lints that are no longer valid, and help
1186     /// maintain consistency for renamed lints.
1187     pub RENAMED_AND_REMOVED_LINTS,
1188     Warn,
1189     "lints that have been renamed or removed"
1190 }
1191
1192 declare_lint! {
1193     /// The `const_item_mutation` lint detects attempts to mutate a `const`
1194     /// item.
1195     ///
1196     /// ### Example
1197     ///
1198     /// ```rust
1199     /// const FOO: [i32; 1] = [0];
1200     ///
1201     /// fn main() {
1202     ///     FOO[0] = 1;
1203     ///     // This will print "[0]".
1204     ///     println!("{:?}", FOO);
1205     /// }
1206     /// ```
1207     ///
1208     /// {{produces}}
1209     ///
1210     /// ### Explanation
1211     ///
1212     /// Trying to directly mutate a `const` item is almost always a mistake.
1213     /// What is happening in the example above is that a temporary copy of the
1214     /// `const` is mutated, but the original `const` is not. Each time you
1215     /// refer to the `const` by name (such as `FOO` in the example above), a
1216     /// separate copy of the value is inlined at that location.
1217     ///
1218     /// This lint checks for writing directly to a field (`FOO.field =
1219     /// some_value`) or array entry (`FOO[0] = val`), or taking a mutable
1220     /// reference to the const item (`&mut FOO`), including through an
1221     /// autoderef (`FOO.some_mut_self_method()`).
1222     ///
1223     /// There are various alternatives depending on what you are trying to
1224     /// accomplish:
1225     ///
1226     /// * First, always reconsider using mutable globals, as they can be
1227     ///   difficult to use correctly, and can make the code more difficult to
1228     ///   use or understand.
1229     /// * If you are trying to perform a one-time initialization of a global:
1230     ///     * If the value can be computed at compile-time, consider using
1231     ///       const-compatible values (see [Constant Evaluation]).
1232     ///     * For more complex single-initialization cases, consider using a
1233     ///       third-party crate, such as [`lazy_static`] or [`once_cell`].
1234     ///     * If you are using the [nightly channel], consider the new
1235     ///       [`lazy`] module in the standard library.
1236     /// * If you truly need a mutable global, consider using a [`static`],
1237     ///   which has a variety of options:
1238     ///   * Simple data types can be directly defined and mutated with an
1239     ///     [`atomic`] type.
1240     ///   * More complex types can be placed in a synchronization primitive
1241     ///     like a [`Mutex`], which can be initialized with one of the options
1242     ///     listed above.
1243     ///   * A [mutable `static`] is a low-level primitive, requiring unsafe.
1244     ///     Typically This should be avoided in preference of something
1245     ///     higher-level like one of the above.
1246     ///
1247     /// [Constant Evaluation]: https://doc.rust-lang.org/reference/const_eval.html
1248     /// [`static`]: https://doc.rust-lang.org/reference/items/static-items.html
1249     /// [mutable `static`]: https://doc.rust-lang.org/reference/items/static-items.html#mutable-statics
1250     /// [`lazy`]: https://doc.rust-lang.org/nightly/std/lazy/index.html
1251     /// [`lazy_static`]: https://crates.io/crates/lazy_static
1252     /// [`once_cell`]: https://crates.io/crates/once_cell
1253     /// [`atomic`]: https://doc.rust-lang.org/std/sync/atomic/index.html
1254     /// [`Mutex`]: https://doc.rust-lang.org/std/sync/struct.Mutex.html
1255     pub CONST_ITEM_MUTATION,
1256     Warn,
1257     "detects attempts to mutate a `const` item",
1258 }
1259
1260 declare_lint! {
1261     /// The `patterns_in_fns_without_body` lint detects `mut` identifier
1262     /// patterns as a parameter in functions without a body.
1263     ///
1264     /// ### Example
1265     ///
1266     /// ```rust,compile_fail
1267     /// trait Trait {
1268     ///     fn foo(mut arg: u8);
1269     /// }
1270     /// ```
1271     ///
1272     /// {{produces}}
1273     ///
1274     /// ### Explanation
1275     ///
1276     /// To fix this, remove `mut` from the parameter in the trait definition;
1277     /// it can be used in the implementation. That is, the following is OK:
1278     ///
1279     /// ```rust
1280     /// trait Trait {
1281     ///     fn foo(arg: u8); // Removed `mut` here
1282     /// }
1283     ///
1284     /// impl Trait for i32 {
1285     ///     fn foo(mut arg: u8) { // `mut` here is OK
1286     ///
1287     ///     }
1288     /// }
1289     /// ```
1290     ///
1291     /// Trait definitions can define functions without a body to specify a
1292     /// function that implementors must define. The parameter names in the
1293     /// body-less functions are only allowed to be `_` or an [identifier] for
1294     /// documentation purposes (only the type is relevant). Previous versions
1295     /// of the compiler erroneously allowed [identifier patterns] with the
1296     /// `mut` keyword, but this was not intended to be allowed. This is a
1297     /// [future-incompatible] lint to transition this to a hard error in the
1298     /// future. See [issue #35203] for more details.
1299     ///
1300     /// [identifier]: https://doc.rust-lang.org/reference/identifiers.html
1301     /// [identifier patterns]: https://doc.rust-lang.org/reference/patterns.html#identifier-patterns
1302     /// [issue #35203]: https://github.com/rust-lang/rust/issues/35203
1303     /// [future-incompatible]: ../index.md#future-incompatible-lints
1304     pub PATTERNS_IN_FNS_WITHOUT_BODY,
1305     Deny,
1306     "patterns in functions without body were erroneously allowed",
1307     @future_incompatible = FutureIncompatibleInfo {
1308         reference: "issue #35203 <https://github.com/rust-lang/rust/issues/35203>",
1309     };
1310 }
1311
1312 declare_lint! {
1313     /// The `missing_fragment_specifier` lint is issued when an unused pattern in a
1314     /// `macro_rules!` macro definition has a meta-variable (e.g. `$e`) that is not
1315     /// followed by a fragment specifier (e.g. `:expr`).
1316     ///
1317     /// This warning can always be fixed by removing the unused pattern in the
1318     /// `macro_rules!` macro definition.
1319     ///
1320     /// ### Example
1321     ///
1322     /// ```rust,compile_fail
1323     /// macro_rules! foo {
1324     ///    () => {};
1325     ///    ($name) => { };
1326     /// }
1327     ///
1328     /// fn main() {
1329     ///    foo!();
1330     /// }
1331     /// ```
1332     ///
1333     /// {{produces}}
1334     ///
1335     /// ### Explanation
1336     ///
1337     /// To fix this, remove the unused pattern from the `macro_rules!` macro definition:
1338     ///
1339     /// ```rust
1340     /// macro_rules! foo {
1341     ///     () => {};
1342     /// }
1343     /// fn main() {
1344     ///     foo!();
1345     /// }
1346     /// ```
1347     pub MISSING_FRAGMENT_SPECIFIER,
1348     Deny,
1349     "detects missing fragment specifiers in unused `macro_rules!` patterns",
1350     @future_incompatible = FutureIncompatibleInfo {
1351         reference: "issue #40107 <https://github.com/rust-lang/rust/issues/40107>",
1352     };
1353 }
1354
1355 declare_lint! {
1356     /// The `late_bound_lifetime_arguments` lint detects generic lifetime
1357     /// arguments in path segments with late bound lifetime parameters.
1358     ///
1359     /// ### Example
1360     ///
1361     /// ```rust
1362     /// struct S;
1363     ///
1364     /// impl S {
1365     ///     fn late(self, _: &u8, _: &u8) {}
1366     /// }
1367     ///
1368     /// fn main() {
1369     ///     S.late::<'static>(&0, &0);
1370     /// }
1371     /// ```
1372     ///
1373     /// {{produces}}
1374     ///
1375     /// ### Explanation
1376     ///
1377     /// It is not clear how to provide arguments for early-bound lifetime
1378     /// parameters if they are intermixed with late-bound parameters in the
1379     /// same list. For now, providing any explicit arguments will trigger this
1380     /// lint if late-bound parameters are present, so in the future a solution
1381     /// can be adopted without hitting backward compatibility issues. This is
1382     /// a [future-incompatible] lint to transition this to a hard error in the
1383     /// future. See [issue #42868] for more details, along with a description
1384     /// of the difference between early and late-bound parameters.
1385     ///
1386     /// [issue #42868]: https://github.com/rust-lang/rust/issues/42868
1387     /// [future-incompatible]: ../index.md#future-incompatible-lints
1388     pub LATE_BOUND_LIFETIME_ARGUMENTS,
1389     Warn,
1390     "detects generic lifetime arguments in path segments with late bound lifetime parameters",
1391     @future_incompatible = FutureIncompatibleInfo {
1392         reference: "issue #42868 <https://github.com/rust-lang/rust/issues/42868>",
1393     };
1394 }
1395
1396 declare_lint! {
1397     /// The `order_dependent_trait_objects` lint detects a trait coherency
1398     /// violation that would allow creating two trait impls for the same
1399     /// dynamic trait object involving marker traits.
1400     ///
1401     /// ### Example
1402     ///
1403     /// ```rust,compile_fail
1404     /// pub trait Trait {}
1405     ///
1406     /// impl Trait for dyn Send + Sync { }
1407     /// impl Trait for dyn Sync + Send { }
1408     /// ```
1409     ///
1410     /// {{produces}}
1411     ///
1412     /// ### Explanation
1413     ///
1414     /// A previous bug caused the compiler to interpret traits with different
1415     /// orders (such as `Send + Sync` and `Sync + Send`) as distinct types
1416     /// when they were intended to be treated the same. This allowed code to
1417     /// define separate trait implementations when there should be a coherence
1418     /// error. This is a [future-incompatible] lint to transition this to a
1419     /// hard error in the future. See [issue #56484] for more details.
1420     ///
1421     /// [issue #56484]: https://github.com/rust-lang/rust/issues/56484
1422     /// [future-incompatible]: ../index.md#future-incompatible-lints
1423     pub ORDER_DEPENDENT_TRAIT_OBJECTS,
1424     Deny,
1425     "trait-object types were treated as different depending on marker-trait order",
1426     @future_incompatible = FutureIncompatibleInfo {
1427         reference: "issue #56484 <https://github.com/rust-lang/rust/issues/56484>",
1428         reason: FutureIncompatibilityReason::FutureReleaseErrorReportNow,
1429     };
1430 }
1431
1432 declare_lint! {
1433     /// The `coherence_leak_check` lint detects conflicting implementations of
1434     /// a trait that are only distinguished by the old leak-check code.
1435     ///
1436     /// ### Example
1437     ///
1438     /// ```rust
1439     /// trait SomeTrait { }
1440     /// impl SomeTrait for for<'a> fn(&'a u8) { }
1441     /// impl<'a> SomeTrait for fn(&'a u8) { }
1442     /// ```
1443     ///
1444     /// {{produces}}
1445     ///
1446     /// ### Explanation
1447     ///
1448     /// In the past, the compiler would accept trait implementations for
1449     /// identical functions that differed only in where the lifetime binder
1450     /// appeared. Due to a change in the borrow checker implementation to fix
1451     /// several bugs, this is no longer allowed. However, since this affects
1452     /// existing code, this is a [future-incompatible] lint to transition this
1453     /// to a hard error in the future.
1454     ///
1455     /// Code relying on this pattern should introduce "[newtypes]",
1456     /// like `struct Foo(for<'a> fn(&'a u8))`.
1457     ///
1458     /// See [issue #56105] for more details.
1459     ///
1460     /// [issue #56105]: https://github.com/rust-lang/rust/issues/56105
1461     /// [newtypes]: https://doc.rust-lang.org/book/ch19-04-advanced-types.html#using-the-newtype-pattern-for-type-safety-and-abstraction
1462     /// [future-incompatible]: ../index.md#future-incompatible-lints
1463     pub COHERENCE_LEAK_CHECK,
1464     Warn,
1465     "distinct impls distinguished only by the leak-check code",
1466     @future_incompatible = FutureIncompatibleInfo {
1467         reference: "issue #56105 <https://github.com/rust-lang/rust/issues/56105>",
1468     };
1469 }
1470
1471 declare_lint! {
1472     /// The `deprecated` lint detects use of deprecated items.
1473     ///
1474     /// ### Example
1475     ///
1476     /// ```rust
1477     /// #[deprecated]
1478     /// fn foo() {}
1479     ///
1480     /// fn bar() {
1481     ///     foo();
1482     /// }
1483     /// ```
1484     ///
1485     /// {{produces}}
1486     ///
1487     /// ### Explanation
1488     ///
1489     /// Items may be marked "deprecated" with the [`deprecated` attribute] to
1490     /// indicate that they should no longer be used. Usually the attribute
1491     /// should include a note on what to use instead, or check the
1492     /// documentation.
1493     ///
1494     /// [`deprecated` attribute]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute
1495     pub DEPRECATED,
1496     Warn,
1497     "detects use of deprecated items",
1498     report_in_external_macro
1499 }
1500
1501 declare_lint! {
1502     /// The `unused_unsafe` lint detects unnecessary use of an `unsafe` block.
1503     ///
1504     /// ### Example
1505     ///
1506     /// ```rust
1507     /// unsafe {}
1508     /// ```
1509     ///
1510     /// {{produces}}
1511     ///
1512     /// ### Explanation
1513     ///
1514     /// If nothing within the block requires `unsafe`, then remove the
1515     /// `unsafe` marker because it is not required and may cause confusion.
1516     pub UNUSED_UNSAFE,
1517     Warn,
1518     "unnecessary use of an `unsafe` block"
1519 }
1520
1521 declare_lint! {
1522     /// The `unused_mut` lint detects mut variables which don't need to be
1523     /// mutable.
1524     ///
1525     /// ### Example
1526     ///
1527     /// ```rust
1528     /// let mut x = 5;
1529     /// ```
1530     ///
1531     /// {{produces}}
1532     ///
1533     /// ### Explanation
1534     ///
1535     /// The preferred style is to only mark variables as `mut` if it is
1536     /// required.
1537     pub UNUSED_MUT,
1538     Warn,
1539     "detect mut variables which don't need to be mutable"
1540 }
1541
1542 declare_lint! {
1543     /// The `unconditional_recursion` lint detects functions that cannot
1544     /// return without calling themselves.
1545     ///
1546     /// ### Example
1547     ///
1548     /// ```rust
1549     /// fn foo() {
1550     ///     foo();
1551     /// }
1552     /// ```
1553     ///
1554     /// {{produces}}
1555     ///
1556     /// ### Explanation
1557     ///
1558     /// It is usually a mistake to have a recursive call that does not have
1559     /// some condition to cause it to terminate. If you really intend to have
1560     /// an infinite loop, using a `loop` expression is recommended.
1561     pub UNCONDITIONAL_RECURSION,
1562     Warn,
1563     "functions that cannot return without calling themselves"
1564 }
1565
1566 declare_lint! {
1567     /// The `single_use_lifetimes` lint detects lifetimes that are only used
1568     /// once.
1569     ///
1570     /// ### Example
1571     ///
1572     /// ```rust,compile_fail
1573     /// #![deny(single_use_lifetimes)]
1574     ///
1575     /// fn foo<'a>(x: &'a u32) {}
1576     /// ```
1577     ///
1578     /// {{produces}}
1579     ///
1580     /// ### Explanation
1581     ///
1582     /// Specifying an explicit lifetime like `'a` in a function or `impl`
1583     /// should only be used to link together two things. Otherwise, you should
1584     /// just use `'_` to indicate that the lifetime is not linked to anything,
1585     /// or elide the lifetime altogether if possible.
1586     ///
1587     /// This lint is "allow" by default because it was introduced at a time
1588     /// when `'_` and elided lifetimes were first being introduced, and this
1589     /// lint would be too noisy. Also, there are some known false positives
1590     /// that it produces. See [RFC 2115] for historical context, and [issue
1591     /// #44752] for more details.
1592     ///
1593     /// [RFC 2115]: https://github.com/rust-lang/rfcs/blob/master/text/2115-argument-lifetimes.md
1594     /// [issue #44752]: https://github.com/rust-lang/rust/issues/44752
1595     pub SINGLE_USE_LIFETIMES,
1596     Allow,
1597     "detects lifetime parameters that are only used once"
1598 }
1599
1600 declare_lint! {
1601     /// The `unused_lifetimes` lint detects lifetime parameters that are never
1602     /// used.
1603     ///
1604     /// ### Example
1605     ///
1606     /// ```rust,compile_fail
1607     /// #[deny(unused_lifetimes)]
1608     ///
1609     /// pub fn foo<'a>() {}
1610     /// ```
1611     ///
1612     /// {{produces}}
1613     ///
1614     /// ### Explanation
1615     ///
1616     /// Unused lifetime parameters may signal a mistake or unfinished code.
1617     /// Consider removing the parameter.
1618     pub UNUSED_LIFETIMES,
1619     Allow,
1620     "detects lifetime parameters that are never used"
1621 }
1622
1623 declare_lint! {
1624     /// The `tyvar_behind_raw_pointer` lint detects raw pointer to an
1625     /// inference variable.
1626     ///
1627     /// ### Example
1628     ///
1629     /// ```rust,edition2015
1630     /// // edition 2015
1631     /// let data = std::ptr::null();
1632     /// let _ = &data as *const *const ();
1633     ///
1634     /// if data.is_null() {}
1635     /// ```
1636     ///
1637     /// {{produces}}
1638     ///
1639     /// ### Explanation
1640     ///
1641     /// This kind of inference was previously allowed, but with the future
1642     /// arrival of [arbitrary self types], this can introduce ambiguity. To
1643     /// resolve this, use an explicit type instead of relying on type
1644     /// inference.
1645     ///
1646     /// This is a [future-incompatible] lint to transition this to a hard
1647     /// error in the 2018 edition. See [issue #46906] for more details. This
1648     /// is currently a hard-error on the 2018 edition, and is "warn" by
1649     /// default in the 2015 edition.
1650     ///
1651     /// [arbitrary self types]: https://github.com/rust-lang/rust/issues/44874
1652     /// [issue #46906]: https://github.com/rust-lang/rust/issues/46906
1653     /// [future-incompatible]: ../index.md#future-incompatible-lints
1654     pub TYVAR_BEHIND_RAW_POINTER,
1655     Warn,
1656     "raw pointer to an inference variable",
1657     @future_incompatible = FutureIncompatibleInfo {
1658         reference: "issue #46906 <https://github.com/rust-lang/rust/issues/46906>",
1659         reason: FutureIncompatibilityReason::EditionError(Edition::Edition2018),
1660     };
1661 }
1662
1663 declare_lint! {
1664     /// The `elided_lifetimes_in_paths` lint detects the use of hidden
1665     /// lifetime parameters.
1666     ///
1667     /// ### Example
1668     ///
1669     /// ```rust,compile_fail
1670     /// #![deny(elided_lifetimes_in_paths)]
1671     /// #![deny(warnings)]
1672     /// struct Foo<'a> {
1673     ///     x: &'a u32
1674     /// }
1675     ///
1676     /// fn foo(x: &Foo) {
1677     /// }
1678     /// ```
1679     ///
1680     /// {{produces}}
1681     ///
1682     /// ### Explanation
1683     ///
1684     /// Elided lifetime parameters can make it difficult to see at a glance
1685     /// that borrowing is occurring. This lint ensures that lifetime
1686     /// parameters are always explicitly stated, even if it is the `'_`
1687     /// [placeholder lifetime].
1688     ///
1689     /// This lint is "allow" by default because it has some known issues, and
1690     /// may require a significant transition for old code.
1691     ///
1692     /// [placeholder lifetime]: https://doc.rust-lang.org/reference/lifetime-elision.html#lifetime-elision-in-functions
1693     pub ELIDED_LIFETIMES_IN_PATHS,
1694     Allow,
1695     "hidden lifetime parameters in types are deprecated",
1696     crate_level_only
1697 }
1698
1699 declare_lint! {
1700     /// The `bare_trait_objects` lint suggests using `dyn Trait` for trait
1701     /// objects.
1702     ///
1703     /// ### Example
1704     ///
1705     /// ```rust,edition2018
1706     /// trait Trait { }
1707     ///
1708     /// fn takes_trait_object(_: Box<Trait>) {
1709     /// }
1710     /// ```
1711     ///
1712     /// {{produces}}
1713     ///
1714     /// ### Explanation
1715     ///
1716     /// Without the `dyn` indicator, it can be ambiguous or confusing when
1717     /// reading code as to whether or not you are looking at a trait object.
1718     /// The `dyn` keyword makes it explicit, and adds a symmetry to contrast
1719     /// with [`impl Trait`].
1720     ///
1721     /// [`impl Trait`]: https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
1722     pub BARE_TRAIT_OBJECTS,
1723     Warn,
1724     "suggest using `dyn Trait` for trait objects",
1725     @future_incompatible = FutureIncompatibleInfo {
1726         reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html>",
1727         reason: FutureIncompatibilityReason::EditionError(Edition::Edition2021),
1728     };
1729 }
1730
1731 declare_lint! {
1732     /// The `absolute_paths_not_starting_with_crate` lint detects fully
1733     /// qualified paths that start with a module name instead of `crate`,
1734     /// `self`, or an extern crate name
1735     ///
1736     /// ### Example
1737     ///
1738     /// ```rust,edition2015,compile_fail
1739     /// #![deny(absolute_paths_not_starting_with_crate)]
1740     ///
1741     /// mod foo {
1742     ///     pub fn bar() {}
1743     /// }
1744     ///
1745     /// fn main() {
1746     ///     ::foo::bar();
1747     /// }
1748     /// ```
1749     ///
1750     /// {{produces}}
1751     ///
1752     /// ### Explanation
1753     ///
1754     /// Rust [editions] allow the language to evolve without breaking
1755     /// backwards compatibility. This lint catches code that uses absolute
1756     /// paths in the style of the 2015 edition. In the 2015 edition, absolute
1757     /// paths (those starting with `::`) refer to either the crate root or an
1758     /// external crate. In the 2018 edition it was changed so that they only
1759     /// refer to external crates. The path prefix `crate::` should be used
1760     /// instead to reference items from the crate root.
1761     ///
1762     /// If you switch the compiler from the 2015 to 2018 edition without
1763     /// updating the code, then it will fail to compile if the old style paths
1764     /// are used. You can manually change the paths to use the `crate::`
1765     /// prefix to transition to the 2018 edition.
1766     ///
1767     /// This lint solves the problem automatically. It is "allow" by default
1768     /// because the code is perfectly valid in the 2015 edition. The [`cargo
1769     /// fix`] tool with the `--edition` flag will switch this lint to "warn"
1770     /// and automatically apply the suggested fix from the compiler. This
1771     /// provides a completely automated way to update old code to the 2018
1772     /// edition.
1773     ///
1774     /// [editions]: https://doc.rust-lang.org/edition-guide/
1775     /// [`cargo fix`]: https://doc.rust-lang.org/cargo/commands/cargo-fix.html
1776     pub ABSOLUTE_PATHS_NOT_STARTING_WITH_CRATE,
1777     Allow,
1778     "fully qualified paths that start with a module name \
1779      instead of `crate`, `self`, or an extern crate name",
1780      @future_incompatible = FutureIncompatibleInfo {
1781         reference: "issue #53130 <https://github.com/rust-lang/rust/issues/53130>",
1782         reason: FutureIncompatibilityReason::EditionError(Edition::Edition2018),
1783      };
1784 }
1785
1786 declare_lint! {
1787     /// The `illegal_floating_point_literal_pattern` lint detects
1788     /// floating-point literals used in patterns.
1789     ///
1790     /// ### Example
1791     ///
1792     /// ```rust
1793     /// let x = 42.0;
1794     ///
1795     /// match x {
1796     ///     5.0 => {}
1797     ///     _ => {}
1798     /// }
1799     /// ```
1800     ///
1801     /// {{produces}}
1802     ///
1803     /// ### Explanation
1804     ///
1805     /// Previous versions of the compiler accepted floating-point literals in
1806     /// patterns, but it was later determined this was a mistake. The
1807     /// semantics of comparing floating-point values may not be clear in a
1808     /// pattern when contrasted with "structural equality". Typically you can
1809     /// work around this by using a [match guard], such as:
1810     ///
1811     /// ```rust
1812     /// # let x = 42.0;
1813     ///
1814     /// match x {
1815     ///     y if y == 5.0 => {}
1816     ///     _ => {}
1817     /// }
1818     /// ```
1819     ///
1820     /// This is a [future-incompatible] lint to transition this to a hard
1821     /// error in the future. See [issue #41620] for more details.
1822     ///
1823     /// [issue #41620]: https://github.com/rust-lang/rust/issues/41620
1824     /// [match guard]: https://doc.rust-lang.org/reference/expressions/match-expr.html#match-guards
1825     /// [future-incompatible]: ../index.md#future-incompatible-lints
1826     pub ILLEGAL_FLOATING_POINT_LITERAL_PATTERN,
1827     Warn,
1828     "floating-point literals cannot be used in patterns",
1829     @future_incompatible = FutureIncompatibleInfo {
1830         reference: "issue #41620 <https://github.com/rust-lang/rust/issues/41620>",
1831     };
1832 }
1833
1834 declare_lint! {
1835     /// The `unstable_name_collisions` lint detects that you have used a name
1836     /// that the standard library plans to add in the future.
1837     ///
1838     /// ### Example
1839     ///
1840     /// ```rust
1841     /// trait MyIterator : Iterator {
1842     ///     // is_sorted is an unstable method that already exists on the Iterator trait
1843     ///     fn is_sorted(self) -> bool where Self: Sized {true}
1844     /// }
1845     ///
1846     /// impl<T: ?Sized> MyIterator for T where T: Iterator { }
1847     ///
1848     /// let x = vec![1, 2, 3];
1849     /// let _ = x.iter().is_sorted();
1850     /// ```
1851     ///
1852     /// {{produces}}
1853     ///
1854     /// ### Explanation
1855     ///
1856     /// When new methods are added to traits in the standard library, they are
1857     /// usually added in an "unstable" form which is only available on the
1858     /// [nightly channel] with a [`feature` attribute]. If there is any
1859     /// preexisting code which extends a trait to have a method with the same
1860     /// name, then the names will collide. In the future, when the method is
1861     /// stabilized, this will cause an error due to the ambiguity. This lint
1862     /// is an early-warning to let you know that there may be a collision in
1863     /// the future. This can be avoided by adding type annotations to
1864     /// disambiguate which trait method you intend to call, such as
1865     /// `MyIterator::is_sorted(my_iter)` or renaming or removing the method.
1866     ///
1867     /// [nightly channel]: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
1868     /// [`feature` attribute]: https://doc.rust-lang.org/nightly/unstable-book/
1869     pub UNSTABLE_NAME_COLLISIONS,
1870     Warn,
1871     "detects name collision with an existing but unstable method",
1872     @future_incompatible = FutureIncompatibleInfo {
1873         reason: FutureIncompatibilityReason::Custom(
1874             "once this associated item is added to the standard library, \
1875              the ambiguity may cause an error or change in behavior!"
1876         ),
1877         reference: "issue #48919 <https://github.com/rust-lang/rust/issues/48919>",
1878         // Note: this item represents future incompatibility of all unstable functions in the
1879         //       standard library, and thus should never be removed or changed to an error.
1880     };
1881 }
1882
1883 declare_lint! {
1884     /// The `irrefutable_let_patterns` lint detects [irrefutable patterns]
1885     /// in [`if let`]s, [`while let`]s, and `if let` guards.
1886     ///
1887     /// ### Example
1888     ///
1889     /// ```rust
1890     /// if let _ = 123 {
1891     ///     println!("always runs!");
1892     /// }
1893     /// ```
1894     ///
1895     /// {{produces}}
1896     ///
1897     /// ### Explanation
1898     ///
1899     /// There usually isn't a reason to have an irrefutable pattern in an
1900     /// `if let` or `while let` statement, because the pattern will always match
1901     /// successfully. A [`let`] or [`loop`] statement will suffice. However,
1902     /// when generating code with a macro, forbidding irrefutable patterns
1903     /// would require awkward workarounds in situations where the macro
1904     /// doesn't know if the pattern is refutable or not. This lint allows
1905     /// macros to accept this form, while alerting for a possibly incorrect
1906     /// use in normal code.
1907     ///
1908     /// See [RFC 2086] for more details.
1909     ///
1910     /// [irrefutable patterns]: https://doc.rust-lang.org/reference/patterns.html#refutability
1911     /// [`if let`]: https://doc.rust-lang.org/reference/expressions/if-expr.html#if-let-expressions
1912     /// [`while let`]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#predicate-pattern-loops
1913     /// [`let`]: https://doc.rust-lang.org/reference/statements.html#let-statements
1914     /// [`loop`]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#infinite-loops
1915     /// [RFC 2086]: https://github.com/rust-lang/rfcs/blob/master/text/2086-allow-if-let-irrefutables.md
1916     pub IRREFUTABLE_LET_PATTERNS,
1917     Warn,
1918     "detects irrefutable patterns in `if let` and `while let` statements"
1919 }
1920
1921 declare_lint! {
1922     /// The `unused_labels` lint detects [labels] that are never used.
1923     ///
1924     /// [labels]: https://doc.rust-lang.org/reference/expressions/loop-expr.html#loop-labels
1925     ///
1926     /// ### Example
1927     ///
1928     /// ```rust,no_run
1929     /// 'unused_label: loop {}
1930     /// ```
1931     ///
1932     /// {{produces}}
1933     ///
1934     /// ### Explanation
1935     ///
1936     /// Unused labels may signal a mistake or unfinished code. To silence the
1937     /// warning for the individual label, prefix it with an underscore such as
1938     /// `'_my_label:`.
1939     pub UNUSED_LABELS,
1940     Warn,
1941     "detects labels that are never used"
1942 }
1943
1944 declare_lint! {
1945     /// The `where_clauses_object_safety` lint detects for [object safety] of
1946     /// [where clauses].
1947     ///
1948     /// [object safety]: https://doc.rust-lang.org/reference/items/traits.html#object-safety
1949     /// [where clauses]: https://doc.rust-lang.org/reference/items/generics.html#where-clauses
1950     ///
1951     /// ### Example
1952     ///
1953     /// ```rust,no_run
1954     /// trait Trait {}
1955     ///
1956     /// trait X { fn foo(&self) where Self: Trait; }
1957     ///
1958     /// impl X for () { fn foo(&self) {} }
1959     ///
1960     /// impl Trait for dyn X {}
1961     ///
1962     /// // Segfault at opt-level 0, SIGILL otherwise.
1963     /// pub fn main() { <dyn X as X>::foo(&()); }
1964     /// ```
1965     ///
1966     /// {{produces}}
1967     ///
1968     /// ### Explanation
1969     ///
1970     /// The compiler previously allowed these object-unsafe bounds, which was
1971     /// incorrect. This is a [future-incompatible] lint to transition this to
1972     /// a hard error in the future. See [issue #51443] for more details.
1973     ///
1974     /// [issue #51443]: https://github.com/rust-lang/rust/issues/51443
1975     /// [future-incompatible]: ../index.md#future-incompatible-lints
1976     pub WHERE_CLAUSES_OBJECT_SAFETY,
1977     Warn,
1978     "checks the object safety of where clauses",
1979     @future_incompatible = FutureIncompatibleInfo {
1980         reference: "issue #51443 <https://github.com/rust-lang/rust/issues/51443>",
1981     };
1982 }
1983
1984 declare_lint! {
1985     /// The `proc_macro_derive_resolution_fallback` lint detects proc macro
1986     /// derives using inaccessible names from parent modules.
1987     ///
1988     /// ### Example
1989     ///
1990     /// ```rust,ignore (proc-macro)
1991     /// // foo.rs
1992     /// #![crate_type = "proc-macro"]
1993     ///
1994     /// extern crate proc_macro;
1995     ///
1996     /// use proc_macro::*;
1997     ///
1998     /// #[proc_macro_derive(Foo)]
1999     /// pub fn foo1(a: TokenStream) -> TokenStream {
2000     ///     drop(a);
2001     ///     "mod __bar { static mut BAR: Option<Something> = None; }".parse().unwrap()
2002     /// }
2003     /// ```
2004     ///
2005     /// ```rust,ignore (needs-dependency)
2006     /// // bar.rs
2007     /// #[macro_use]
2008     /// extern crate foo;
2009     ///
2010     /// struct Something;
2011     ///
2012     /// #[derive(Foo)]
2013     /// struct Another;
2014     ///
2015     /// fn main() {}
2016     /// ```
2017     ///
2018     /// This will produce:
2019     ///
2020     /// ```text
2021     /// warning: cannot find type `Something` in this scope
2022     ///  --> src/main.rs:8:10
2023     ///   |
2024     /// 8 | #[derive(Foo)]
2025     ///   |          ^^^ names from parent modules are not accessible without an explicit import
2026     ///   |
2027     ///   = note: `#[warn(proc_macro_derive_resolution_fallback)]` on by default
2028     ///   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
2029     ///   = note: for more information, see issue #50504 <https://github.com/rust-lang/rust/issues/50504>
2030     /// ```
2031     ///
2032     /// ### Explanation
2033     ///
2034     /// If a proc-macro generates a module, the compiler unintentionally
2035     /// allowed items in that module to refer to items in the crate root
2036     /// without importing them. This is a [future-incompatible] lint to
2037     /// transition this to a hard error in the future. See [issue #50504] for
2038     /// more details.
2039     ///
2040     /// [issue #50504]: https://github.com/rust-lang/rust/issues/50504
2041     /// [future-incompatible]: ../index.md#future-incompatible-lints
2042     pub PROC_MACRO_DERIVE_RESOLUTION_FALLBACK,
2043     Deny,
2044     "detects proc macro derives using inaccessible names from parent modules",
2045     @future_incompatible = FutureIncompatibleInfo {
2046         reference: "issue #83583 <https://github.com/rust-lang/rust/issues/83583>",
2047         reason: FutureIncompatibilityReason::FutureReleaseErrorReportNow,
2048     };
2049 }
2050
2051 declare_lint! {
2052     /// The `macro_use_extern_crate` lint detects the use of the
2053     /// [`macro_use` attribute].
2054     ///
2055     /// ### Example
2056     ///
2057     /// ```rust,ignore (needs extern crate)
2058     /// #![deny(macro_use_extern_crate)]
2059     ///
2060     /// #[macro_use]
2061     /// extern crate serde_json;
2062     ///
2063     /// fn main() {
2064     ///     let _ = json!{{}};
2065     /// }
2066     /// ```
2067     ///
2068     /// This will produce:
2069     ///
2070     /// ```text
2071     /// error: deprecated `#[macro_use]` attribute used to import macros should be replaced at use sites with a `use` item to import the macro instead
2072     ///  --> src/main.rs:3:1
2073     ///   |
2074     /// 3 | #[macro_use]
2075     ///   | ^^^^^^^^^^^^
2076     ///   |
2077     /// note: the lint level is defined here
2078     ///  --> src/main.rs:1:9
2079     ///   |
2080     /// 1 | #![deny(macro_use_extern_crate)]
2081     ///   |         ^^^^^^^^^^^^^^^^^^^^^^
2082     /// ```
2083     ///
2084     /// ### Explanation
2085     ///
2086     /// The [`macro_use` attribute] on an [`extern crate`] item causes
2087     /// macros in that external crate to be brought into the prelude of the
2088     /// crate, making the macros in scope everywhere. As part of the efforts
2089     /// to simplify handling of dependencies in the [2018 edition], the use of
2090     /// `extern crate` is being phased out. To bring macros from extern crates
2091     /// into scope, it is recommended to use a [`use` import].
2092     ///
2093     /// This lint is "allow" by default because this is a stylistic choice
2094     /// that has not been settled, see [issue #52043] for more information.
2095     ///
2096     /// [`macro_use` attribute]: https://doc.rust-lang.org/reference/macros-by-example.html#the-macro_use-attribute
2097     /// [`use` import]: https://doc.rust-lang.org/reference/items/use-declarations.html
2098     /// [issue #52043]: https://github.com/rust-lang/rust/issues/52043
2099     pub MACRO_USE_EXTERN_CRATE,
2100     Allow,
2101     "the `#[macro_use]` attribute is now deprecated in favor of using macros \
2102      via the module system"
2103 }
2104
2105 declare_lint! {
2106     /// The `macro_expanded_macro_exports_accessed_by_absolute_paths` lint
2107     /// detects macro-expanded [`macro_export`] macros from the current crate
2108     /// that cannot be referred to by absolute paths.
2109     ///
2110     /// [`macro_export`]: https://doc.rust-lang.org/reference/macros-by-example.html#path-based-scope
2111     ///
2112     /// ### Example
2113     ///
2114     /// ```rust,compile_fail
2115     /// macro_rules! define_exported {
2116     ///     () => {
2117     ///         #[macro_export]
2118     ///         macro_rules! exported {
2119     ///             () => {};
2120     ///         }
2121     ///     };
2122     /// }
2123     ///
2124     /// define_exported!();
2125     ///
2126     /// fn main() {
2127     ///     crate::exported!();
2128     /// }
2129     /// ```
2130     ///
2131     /// {{produces}}
2132     ///
2133     /// ### Explanation
2134     ///
2135     /// The intent is that all macros marked with the `#[macro_export]`
2136     /// attribute are made available in the root of the crate. However, when a
2137     /// `macro_rules!` definition is generated by another macro, the macro
2138     /// expansion is unable to uphold this rule. This is a
2139     /// [future-incompatible] lint to transition this to a hard error in the
2140     /// future. See [issue #53495] for more details.
2141     ///
2142     /// [issue #53495]: https://github.com/rust-lang/rust/issues/53495
2143     /// [future-incompatible]: ../index.md#future-incompatible-lints
2144     pub MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS,
2145     Deny,
2146     "macro-expanded `macro_export` macros from the current crate \
2147      cannot be referred to by absolute paths",
2148     @future_incompatible = FutureIncompatibleInfo {
2149         reference: "issue #52234 <https://github.com/rust-lang/rust/issues/52234>",
2150     };
2151     crate_level_only
2152 }
2153
2154 declare_lint! {
2155     /// The `explicit_outlives_requirements` lint detects unnecessary
2156     /// lifetime bounds that can be inferred.
2157     ///
2158     /// ### Example
2159     ///
2160     /// ```rust,compile_fail
2161     /// # #![allow(unused)]
2162     /// #![deny(explicit_outlives_requirements)]
2163     /// #![deny(warnings)]
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     /// ```rust,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 `unnameable_test_items` lint detects [`#[test]`][test] functions
2851     /// that are not able to be run by the test harness because they are in a
2852     /// position where they are not nameable.
2853     ///
2854     /// [test]: https://doc.rust-lang.org/reference/attributes/testing.html#the-test-attribute
2855     ///
2856     /// ### Example
2857     ///
2858     /// ```rust,test
2859     /// fn main() {
2860     ///     #[test]
2861     ///     fn foo() {
2862     ///         // This test will not fail because it does not run.
2863     ///         assert_eq!(1, 2);
2864     ///     }
2865     /// }
2866     /// ```
2867     ///
2868     /// {{produces}}
2869     ///
2870     /// ### Explanation
2871     ///
2872     /// In order for the test harness to run a test, the test function must be
2873     /// located in a position where it can be accessed from the crate root.
2874     /// This generally means it must be defined in a module, and not anywhere
2875     /// else such as inside another function. The compiler previously allowed
2876     /// this without an error, so a lint was added as an alert that a test is
2877     /// not being used. Whether or not this should be allowed has not yet been
2878     /// decided, see [RFC 2471] and [issue #36629].
2879     ///
2880     /// [RFC 2471]: https://github.com/rust-lang/rfcs/pull/2471#issuecomment-397414443
2881     /// [issue #36629]: https://github.com/rust-lang/rust/issues/36629
2882     pub UNNAMEABLE_TEST_ITEMS,
2883     Warn,
2884     "detects an item that cannot be named being marked as `#[test_case]`",
2885     report_in_external_macro
2886 }
2887
2888 declare_lint! {
2889     /// The `useless_deprecated` lint detects deprecation attributes with no effect.
2890     ///
2891     /// ### Example
2892     ///
2893     /// ```rust,compile_fail
2894     /// struct X;
2895     ///
2896     /// #[deprecated = "message"]
2897     /// impl Default for X {
2898     ///     fn default() -> Self {
2899     ///         X
2900     ///     }
2901     /// }
2902     /// ```
2903     ///
2904     /// {{produces}}
2905     ///
2906     /// ### Explanation
2907     ///
2908     /// Deprecation attributes have no effect on trait implementations.
2909     pub USELESS_DEPRECATED,
2910     Deny,
2911     "detects deprecation attributes with no effect",
2912 }
2913
2914 declare_lint! {
2915     /// The `undefined_naked_function_abi` lint detects naked function definitions that
2916     /// either do not specify an ABI or specify the Rust ABI.
2917     ///
2918     /// ### Example
2919     ///
2920     /// ```rust
2921     /// #![feature(asm_experimental_arch, naked_functions)]
2922     ///
2923     /// use std::arch::asm;
2924     ///
2925     /// #[naked]
2926     /// pub fn default_abi() -> u32 {
2927     ///     unsafe { asm!("", options(noreturn)); }
2928     /// }
2929     ///
2930     /// #[naked]
2931     /// pub extern "Rust" fn rust_abi() -> u32 {
2932     ///     unsafe { asm!("", options(noreturn)); }
2933     /// }
2934     /// ```
2935     ///
2936     /// {{produces}}
2937     ///
2938     /// ### Explanation
2939     ///
2940     /// The Rust ABI is currently undefined. Therefore, naked functions should
2941     /// specify a non-Rust ABI.
2942     pub UNDEFINED_NAKED_FUNCTION_ABI,
2943     Warn,
2944     "undefined naked function ABI"
2945 }
2946
2947 declare_lint! {
2948     /// The `ineffective_unstable_trait_impl` lint detects `#[unstable]` attributes which are not used.
2949     ///
2950     /// ### Example
2951     ///
2952     /// ```rust,compile_fail
2953     /// #![feature(staged_api)]
2954     ///
2955     /// #[derive(Clone)]
2956     /// #[stable(feature = "x", since = "1")]
2957     /// struct S {}
2958     ///
2959     /// #[unstable(feature = "y", issue = "none")]
2960     /// impl Copy for S {}
2961     /// ```
2962     ///
2963     /// {{produces}}
2964     ///
2965     /// ### Explanation
2966     ///
2967     /// `staged_api` does not currently support using a stability attribute on `impl` blocks.
2968     /// `impl`s are always stable if both the type and trait are stable, and always unstable otherwise.
2969     pub INEFFECTIVE_UNSTABLE_TRAIT_IMPL,
2970     Deny,
2971     "detects `#[unstable]` on stable trait implementations for stable types"
2972 }
2973
2974 declare_lint! {
2975     /// The `semicolon_in_expressions_from_macros` lint detects trailing semicolons
2976     /// in macro bodies when the macro is invoked in expression position.
2977     /// This was previous accepted, but is being phased out.
2978     ///
2979     /// ### Example
2980     ///
2981     /// ```rust,compile_fail
2982     /// #![deny(semicolon_in_expressions_from_macros)]
2983     /// macro_rules! foo {
2984     ///     () => { true; }
2985     /// }
2986     ///
2987     /// fn main() {
2988     ///     let val = match true {
2989     ///         true => false,
2990     ///         _ => foo!()
2991     ///     };
2992     /// }
2993     /// ```
2994     ///
2995     /// {{produces}}
2996     ///
2997     /// ### Explanation
2998     ///
2999     /// Previous, Rust ignored trailing semicolon in a macro
3000     /// body when a macro was invoked in expression position.
3001     /// However, this makes the treatment of semicolons in the language
3002     /// inconsistent, and could lead to unexpected runtime behavior
3003     /// in some circumstances (e.g. if the macro author expects
3004     /// a value to be dropped).
3005     ///
3006     /// This is a [future-incompatible] lint to transition this
3007     /// to a hard error in the future. See [issue #79813] for more details.
3008     ///
3009     /// [issue #79813]: https://github.com/rust-lang/rust/issues/79813
3010     /// [future-incompatible]: ../index.md#future-incompatible-lints
3011     pub SEMICOLON_IN_EXPRESSIONS_FROM_MACROS,
3012     Warn,
3013     "trailing semicolon in macro body used as expression",
3014     @future_incompatible = FutureIncompatibleInfo {
3015         reference: "issue #79813 <https://github.com/rust-lang/rust/issues/79813>",
3016         reason: FutureIncompatibilityReason::FutureReleaseErrorReportNow,
3017     };
3018 }
3019
3020 declare_lint! {
3021     /// The `legacy_derive_helpers` lint detects derive helper attributes
3022     /// that are used before they are introduced.
3023     ///
3024     /// ### Example
3025     ///
3026     /// ```rust,ignore (needs extern crate)
3027     /// #[serde(rename_all = "camelCase")]
3028     /// #[derive(Deserialize)]
3029     /// struct S { /* fields */ }
3030     /// ```
3031     ///
3032     /// produces:
3033     ///
3034     /// ```text
3035     /// warning: derive helper attribute is used before it is introduced
3036     ///   --> $DIR/legacy-derive-helpers.rs:1:3
3037     ///    |
3038     ///  1 | #[serde(rename_all = "camelCase")]
3039     ///    |   ^^^^^
3040     /// ...
3041     ///  2 | #[derive(Deserialize)]
3042     ///    |          ----------- the attribute is introduced here
3043     /// ```
3044     ///
3045     /// ### Explanation
3046     ///
3047     /// Attributes like this work for historical reasons, but attribute expansion works in
3048     /// left-to-right order in general, so, to resolve `#[serde]`, compiler has to try to "look
3049     /// into the future" at not yet expanded part of the item , but such attempts are not always
3050     /// reliable.
3051     ///
3052     /// To fix the warning place the helper attribute after its corresponding derive.
3053     /// ```rust,ignore (needs extern crate)
3054     /// #[derive(Deserialize)]
3055     /// #[serde(rename_all = "camelCase")]
3056     /// struct S { /* fields */ }
3057     /// ```
3058     pub LEGACY_DERIVE_HELPERS,
3059     Warn,
3060     "detects derive helper attributes that are used before they are introduced",
3061     @future_incompatible = FutureIncompatibleInfo {
3062         reference: "issue #79202 <https://github.com/rust-lang/rust/issues/79202>",
3063     };
3064 }
3065
3066 declare_lint! {
3067     /// The `large_assignments` lint detects when objects of large
3068     /// types are being moved around.
3069     ///
3070     /// ### Example
3071     ///
3072     /// ```rust,ignore (can crash on some platforms)
3073     /// let x = [0; 50000];
3074     /// let y = x;
3075     /// ```
3076     ///
3077     /// produces:
3078     ///
3079     /// ```text
3080     /// warning: moving a large value
3081     ///   --> $DIR/move-large.rs:1:3
3082     ///   let y = x;
3083     ///           - Copied large value here
3084     /// ```
3085     ///
3086     /// ### Explanation
3087     ///
3088     /// When using a large type in a plain assignment or in a function
3089     /// argument, idiomatic code can be inefficient.
3090     /// Ideally appropriate optimizations would resolve this, but such
3091     /// optimizations are only done in a best-effort manner.
3092     /// This lint will trigger on all sites of large moves and thus allow the
3093     /// user to resolve them in code.
3094     pub LARGE_ASSIGNMENTS,
3095     Warn,
3096     "detects large moves or copies",
3097 }
3098
3099 declare_lint! {
3100     /// The `deprecated_cfg_attr_crate_type_name` lint detects uses of the
3101     /// `#![cfg_attr(..., crate_type = "...")]` and
3102     /// `#![cfg_attr(..., crate_name = "...")]` attributes to conditionally
3103     /// specify the crate type and name in the source code.
3104     ///
3105     /// ### Example
3106     ///
3107     /// ```rust,compile_fail
3108     /// #![cfg_attr(debug_assertions, crate_type = "lib")]
3109     /// ```
3110     ///
3111     /// {{produces}}
3112     ///
3113     ///
3114     /// ### Explanation
3115     ///
3116     /// The `#![crate_type]` and `#![crate_name]` attributes require a hack in
3117     /// the compiler to be able to change the used crate type and crate name
3118     /// after macros have been expanded. Neither attribute works in combination
3119     /// with Cargo as it explicitly passes `--crate-type` and `--crate-name` on
3120     /// the commandline. These values must match the value used in the source
3121     /// code to prevent an error.
3122     ///
3123     /// To fix the warning use `--crate-type` on the commandline when running
3124     /// rustc instead of `#![cfg_attr(..., crate_type = "...")]` and
3125     /// `--crate-name` instead of `#![cfg_attr(..., crate_name = "...")]`.
3126     pub DEPRECATED_CFG_ATTR_CRATE_TYPE_NAME,
3127     Deny,
3128     "detects usage of `#![cfg_attr(..., crate_type/crate_name = \"...\")]`",
3129     @future_incompatible = FutureIncompatibleInfo {
3130         reference: "issue #91632 <https://github.com/rust-lang/rust/issues/91632>",
3131     };
3132 }
3133
3134 declare_lint! {
3135     /// The `unexpected_cfgs` lint detects unexpected conditional compilation conditions.
3136     ///
3137     /// ### Example
3138     ///
3139     /// ```text
3140     /// rustc --check-cfg 'names()'
3141     /// ```
3142     ///
3143     /// ```rust,ignore (needs command line option)
3144     /// #[cfg(widnows)]
3145     /// fn foo() {}
3146     /// ```
3147     ///
3148     /// This will produce:
3149     ///
3150     /// ```text
3151     /// warning: unknown condition name used
3152     ///  --> lint_example.rs:1:7
3153     ///   |
3154     /// 1 | #[cfg(widnows)]
3155     ///   |       ^^^^^^^
3156     ///   |
3157     ///   = note: `#[warn(unexpected_cfgs)]` on by default
3158     /// ```
3159     ///
3160     /// ### Explanation
3161     ///
3162     /// This lint is only active when a `--check-cfg='names(...)'` option has been passed
3163     /// to the compiler and triggers whenever an unknown condition name or value is used.
3164     /// The known condition include names or values passed in `--check-cfg`, `--cfg`, and some
3165     /// well-knows names and values built into the compiler.
3166     pub UNEXPECTED_CFGS,
3167     Warn,
3168     "detects unexpected names and values in `#[cfg]` conditions",
3169 }
3170
3171 declare_lint! {
3172     /// The `repr_transparent_external_private_fields` lint
3173     /// detects types marked `#[repr(transparent)]` that (transitively)
3174     /// contain an external ZST type marked `#[non_exhaustive]` or containing
3175     /// private fields
3176     ///
3177     /// ### Example
3178     ///
3179     /// ```rust,ignore (needs external crate)
3180     /// #![deny(repr_transparent_external_private_fields)]
3181     /// use foo::NonExhaustiveZst;
3182     ///
3183     /// #[repr(transparent)]
3184     /// struct Bar(u32, ([u32; 0], NonExhaustiveZst));
3185     /// ```
3186     ///
3187     /// This will produce:
3188     ///
3189     /// ```text
3190     /// error: zero-sized fields in repr(transparent) cannot contain external non-exhaustive types
3191     ///  --> src/main.rs:5:28
3192     ///   |
3193     /// 5 | struct Bar(u32, ([u32; 0], NonExhaustiveZst));
3194     ///   |                            ^^^^^^^^^^^^^^^^
3195     ///   |
3196     /// note: the lint level is defined here
3197     ///  --> src/main.rs:1:9
3198     ///   |
3199     /// 1 | #![deny(repr_transparent_external_private_fields)]
3200     ///   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3201     ///   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
3202     ///   = note: for more information, see issue #78586 <https://github.com/rust-lang/rust/issues/78586>
3203     ///   = 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.
3204     /// ```
3205     ///
3206     /// ### Explanation
3207     ///
3208     /// Previous, Rust accepted fields that contain external private zero-sized types,
3209     /// even though it should not be a breaking change to add a non-zero-sized field to
3210     /// that private type.
3211     ///
3212     /// This is a [future-incompatible] lint to transition this
3213     /// to a hard error in the future. See [issue #78586] for more details.
3214     ///
3215     /// [issue #78586]: https://github.com/rust-lang/rust/issues/78586
3216     /// [future-incompatible]: ../index.md#future-incompatible-lints
3217     pub REPR_TRANSPARENT_EXTERNAL_PRIVATE_FIELDS,
3218     Warn,
3219     "transparent type contains an external ZST that is marked #[non_exhaustive] or contains private fields",
3220     @future_incompatible = FutureIncompatibleInfo {
3221         reference: "issue #78586 <https://github.com/rust-lang/rust/issues/78586>",
3222     };
3223 }
3224
3225 declare_lint! {
3226     /// The `unstable_syntax_pre_expansion` lint detects the use of unstable
3227     /// syntax that is discarded during attribute expansion.
3228     ///
3229     /// ### Example
3230     ///
3231     /// ```rust
3232     /// #[cfg(FALSE)]
3233     /// macro foo() {}
3234     /// ```
3235     ///
3236     /// {{produces}}
3237     ///
3238     /// ### Explanation
3239     ///
3240     /// The input to active attributes such as `#[cfg]` or procedural macro
3241     /// attributes is required to be valid syntax. Previously, the compiler only
3242     /// gated the use of unstable syntax features after resolving `#[cfg]` gates
3243     /// and expanding procedural macros.
3244     ///
3245     /// To avoid relying on unstable syntax, move the use of unstable syntax
3246     /// into a position where the compiler does not parse the syntax, such as a
3247     /// functionlike macro.
3248     ///
3249     /// ```rust
3250     /// # #![deny(unstable_syntax_pre_expansion)]
3251     ///
3252     /// macro_rules! identity {
3253     ///    ( $($tokens:tt)* ) => { $($tokens)* }
3254     /// }
3255     ///
3256     /// #[cfg(FALSE)]
3257     /// identity! {
3258     ///    macro foo() {}
3259     /// }
3260     /// ```
3261     ///
3262     /// This is a [future-incompatible] lint to transition this
3263     /// to a hard error in the future. See [issue #65860] for more details.
3264     ///
3265     /// [issue #65860]: https://github.com/rust-lang/rust/issues/65860
3266     /// [future-incompatible]: ../index.md#future-incompatible-lints
3267     pub UNSTABLE_SYNTAX_PRE_EXPANSION,
3268     Warn,
3269     "unstable syntax can change at any point in the future, causing a hard error!",
3270     @future_incompatible = FutureIncompatibleInfo {
3271         reference: "issue #65860 <https://github.com/rust-lang/rust/issues/65860>",
3272     };
3273 }
3274
3275 declare_lint! {
3276     /// The `ambiguous_glob_reexports` lint detects cases where names re-exported via globs
3277     /// collide. Downstream users trying to use the same name re-exported from multiple globs
3278     /// will receive a warning pointing out redefinition of the same name.
3279     ///
3280     /// ### Example
3281     ///
3282     /// ```rust,compile_fail
3283     /// #![deny(ambiguous_glob_reexports)]
3284     /// pub mod foo {
3285     ///     pub type X = u8;
3286     /// }
3287     ///
3288     /// pub mod bar {
3289     ///     pub type Y = u8;
3290     ///     pub type X = u8;
3291     /// }
3292     ///
3293     /// pub use foo::*;
3294     /// pub use bar::*;
3295     ///
3296     ///
3297     /// pub fn main() {}
3298     /// ```
3299     ///
3300     /// {{produces}}
3301     ///
3302     /// ### Explanation
3303     ///
3304     /// This was previously accepted but it could silently break a crate's downstream users code.
3305     /// For example, if `foo::*` and `bar::*` were re-exported before `bar::X` was added to the
3306     /// re-exports, down stream users could use `this_crate::X` without problems. However, adding
3307     /// `bar::X` would cause compilation errors in downstream crates because `X` is defined
3308     /// multiple times in the same namespace of `this_crate`.
3309     pub AMBIGUOUS_GLOB_REEXPORTS,
3310     Warn,
3311     "ambiguous glob re-exports",
3312 }
3313
3314 declare_lint! {
3315     /// The `hidden_glob_reexports` lint detects cases where glob re-export items are shadowed by
3316     /// private items.
3317     ///
3318     /// ### Example
3319     ///
3320     /// ```rust,compile_fail
3321     /// #![deny(hidden_glob_reexports)]
3322     ///
3323     /// pub mod upstream {
3324     ///     mod inner { pub struct Foo {}; pub struct Bar {}; }
3325     ///     pub use self::inner::*;
3326     ///     struct Foo {} // private item shadows `inner::Foo`
3327     /// }
3328     ///
3329     /// // mod downstream {
3330     /// //     fn test() {
3331     /// //         let _ = crate::upstream::Foo; // inaccessible
3332     /// //     }
3333     /// // }
3334     ///
3335     /// pub fn main() {}
3336     /// ```
3337     ///
3338     /// {{produces}}
3339     ///
3340     /// ### Explanation
3341     ///
3342     /// This was previously accepted without any errors or warnings but it could silently break a
3343     /// crate's downstream user code. If the `struct Foo` was added, `dep::inner::Foo` would
3344     /// silently become inaccessible and trigger a "`struct `Foo` is private`" visibility error at
3345     /// the downstream use site.
3346     pub HIDDEN_GLOB_REEXPORTS,
3347     Warn,
3348     "name introduced by a private item shadows a name introduced by a public glob re-export",
3349 }
3350
3351 declare_lint_pass! {
3352     /// Does nothing as a lint pass, but registers some `Lint`s
3353     /// that are used by other parts of the compiler.
3354     HardwiredLints => [
3355         // tidy-alphabetical-start
3356         ABSOLUTE_PATHS_NOT_STARTING_WITH_CRATE,
3357         AMBIGUOUS_ASSOCIATED_ITEMS,
3358         AMBIGUOUS_GLOB_IMPORTS,
3359         AMBIGUOUS_GLOB_REEXPORTS,
3360         ARITHMETIC_OVERFLOW,
3361         ASM_SUB_REGISTER,
3362         BAD_ASM_STYLE,
3363         BARE_TRAIT_OBJECTS,
3364         BINDINGS_WITH_VARIANT_NAME,
3365         BREAK_WITH_LABEL_AND_LOOP,
3366         BYTE_SLICE_IN_PACKED_STRUCT_WITH_DERIVE,
3367         CENUM_IMPL_DROP_CAST,
3368         COHERENCE_LEAK_CHECK,
3369         COINDUCTIVE_OVERLAP_IN_COHERENCE,
3370         CONFLICTING_REPR_HINTS,
3371         CONST_EVALUATABLE_UNCHECKED,
3372         CONST_ITEM_MUTATION,
3373         DEAD_CODE,
3374         DEPRECATED,
3375         DEPRECATED_CFG_ATTR_CRATE_TYPE_NAME,
3376         DEPRECATED_IN_FUTURE,
3377         DEPRECATED_WHERE_CLAUSE_LOCATION,
3378         DUPLICATE_MACRO_ATTRIBUTES,
3379         ELIDED_LIFETIMES_IN_PATHS,
3380         EXPORTED_PRIVATE_DEPENDENCIES,
3381         FFI_UNWIND_CALLS,
3382         FORBIDDEN_LINT_GROUPS,
3383         FUNCTION_ITEM_REFERENCES,
3384         FUZZY_PROVENANCE_CASTS,
3385         HIDDEN_GLOB_REEXPORTS,
3386         ILL_FORMED_ATTRIBUTE_INPUT,
3387         ILLEGAL_FLOATING_POINT_LITERAL_PATTERN,
3388         IMPLIED_BOUNDS_ENTAILMENT,
3389         INCOMPLETE_INCLUDE,
3390         INDIRECT_STRUCTURAL_MATCH,
3391         INEFFECTIVE_UNSTABLE_TRAIT_IMPL,
3392         INLINE_NO_SANITIZE,
3393         INVALID_ALIGNMENT,
3394         INVALID_DOC_ATTRIBUTES,
3395         INVALID_MACRO_EXPORT_ARGUMENTS,
3396         INVALID_TYPE_PARAM_DEFAULT,
3397         IRREFUTABLE_LET_PATTERNS,
3398         LARGE_ASSIGNMENTS,
3399         LATE_BOUND_LIFETIME_ARGUMENTS,
3400         LEGACY_DERIVE_HELPERS,
3401         LONG_RUNNING_CONST_EVAL,
3402         LOSSY_PROVENANCE_CASTS,
3403         MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS,
3404         MACRO_USE_EXTERN_CRATE,
3405         META_VARIABLE_MISUSE,
3406         MISSING_ABI,
3407         MISSING_FRAGMENT_SPECIFIER,
3408         MUST_NOT_SUSPEND,
3409         NAMED_ARGUMENTS_USED_POSITIONALLY,
3410         NON_EXHAUSTIVE_OMITTED_PATTERNS,
3411         NONTRIVIAL_STRUCTURAL_MATCH,
3412         ORDER_DEPENDENT_TRAIT_OBJECTS,
3413         OVERLAPPING_RANGE_ENDPOINTS,
3414         PATTERNS_IN_FNS_WITHOUT_BODY,
3415         POINTER_STRUCTURAL_MATCH,
3416         PRIVATE_BOUNDS,
3417         PRIVATE_IN_PUBLIC,
3418         PRIVATE_INTERFACES,
3419         PROC_MACRO_BACK_COMPAT,
3420         PROC_MACRO_DERIVE_RESOLUTION_FALLBACK,
3421         PUB_USE_OF_PRIVATE_EXTERN_CRATE,
3422         RENAMED_AND_REMOVED_LINTS,
3423         REPR_TRANSPARENT_EXTERNAL_PRIVATE_FIELDS,
3424         RUST_2021_INCOMPATIBLE_CLOSURE_CAPTURES,
3425         RUST_2021_INCOMPATIBLE_OR_PATTERNS,
3426         RUST_2021_PREFIXES_INCOMPATIBLE_SYNTAX,
3427         RUST_2021_PRELUDE_COLLISIONS,
3428         SEMICOLON_IN_EXPRESSIONS_FROM_MACROS,
3429         SINGLE_USE_LIFETIMES,
3430         SOFT_UNSTABLE,
3431         STABLE_FEATURES,
3432         SUSPICIOUS_AUTO_TRAIT_IMPLS,
3433         TEST_UNSTABLE_LINT,
3434         TEXT_DIRECTION_CODEPOINT_IN_COMMENT,
3435         TRIVIAL_CASTS,
3436         TRIVIAL_NUMERIC_CASTS,
3437         TYVAR_BEHIND_RAW_POINTER,
3438         UNCONDITIONAL_PANIC,
3439         UNCONDITIONAL_RECURSION,
3440         UNDEFINED_NAKED_FUNCTION_ABI,
3441         UNFULFILLED_LINT_EXPECTATIONS,
3442         UNINHABITED_STATIC,
3443         UNKNOWN_CRATE_TYPES,
3444         UNKNOWN_DIAGNOSTIC_ATTRIBUTES,
3445         UNKNOWN_LINTS,
3446         UNNAMEABLE_TEST_ITEMS,
3447         UNNAMEABLE_TYPES,
3448         UNREACHABLE_CODE,
3449         UNREACHABLE_PATTERNS,
3450         UNSAFE_OP_IN_UNSAFE_FN,
3451         UNSTABLE_NAME_COLLISIONS,
3452         UNSTABLE_SYNTAX_PRE_EXPANSION,
3453         UNSUPPORTED_CALLING_CONVENTIONS,
3454         UNUSED_ASSIGNMENTS,
3455         UNUSED_ASSOCIATED_TYPE_BOUNDS,
3456         UNUSED_ATTRIBUTES,
3457         UNUSED_CRATE_DEPENDENCIES,
3458         UNUSED_EXTERN_CRATES,
3459         UNUSED_FEATURES,
3460         UNUSED_IMPORTS,
3461         UNUSED_LABELS,
3462         UNUSED_LIFETIMES,
3463         UNUSED_MACRO_RULES,
3464         UNUSED_MACROS,
3465         UNUSED_MUT,
3466         UNUSED_QUALIFICATIONS,
3467         UNUSED_TUPLE_STRUCT_FIELDS,
3468         UNUSED_UNSAFE,
3469         UNUSED_VARIABLES,
3470         USELESS_DEPRECATED,
3471         WARNINGS,
3472         WHERE_CLAUSES_OBJECT_SAFETY,
3473         // tidy-alphabetical-end
3474     ]
3475 }
3476
3477 declare_lint! {
3478     /// The `long_running_const_eval` lint is emitted when const
3479     /// eval is running for a long time to ensure rustc terminates
3480     /// even if you accidentally wrote an infinite loop.
3481     ///
3482     /// ### Example
3483     ///
3484     /// ```rust,compile_fail
3485     /// const FOO: () = loop {};
3486     /// ```
3487     ///
3488     /// {{produces}}
3489     ///
3490     /// ### Explanation
3491     ///
3492     /// Loops allow const evaluation to compute arbitrary code, but may also
3493     /// cause infinite loops or just very long running computations.
3494     /// Users can enable long running computations by allowing the lint
3495     /// on individual constants or for entire crates.
3496     ///
3497     /// ### Unconditional warnings
3498     ///
3499     /// Note that regardless of whether the lint is allowed or set to warn,
3500     /// the compiler will issue warnings if constant evaluation runs significantly
3501     /// longer than this lint's limit. These warnings are also shown to downstream
3502     /// users from crates.io or similar registries. If you are above the lint's limit,
3503     /// both you and downstream users might be exposed to these warnings.
3504     /// They might also appear on compiler updates, as the compiler makes minor changes
3505     /// about how complexity is measured: staying below the limit ensures that there
3506     /// is enough room, and given that the lint is disabled for people who use your
3507     /// dependency it means you will be the only one to get the warning and can put
3508     /// out an update in your own time.
3509     pub LONG_RUNNING_CONST_EVAL,
3510     Deny,
3511     "detects long const eval operations",
3512     report_in_external_macro
3513 }
3514
3515 declare_lint! {
3516     /// The `unused_associated_type_bounds` lint is emitted when an
3517     /// associated type bound is added to a trait object, but the associated
3518     /// type has a `where Self: Sized` bound, and is thus unavailable on the
3519     /// trait object anyway.
3520     ///
3521     /// ### Example
3522     ///
3523     /// ```rust
3524     /// trait Foo {
3525     ///     type Bar where Self: Sized;
3526     /// }
3527     /// type Mop = dyn Foo<Bar = ()>;
3528     /// ```
3529     ///
3530     /// {{produces}}
3531     ///
3532     /// ### Explanation
3533     ///
3534     /// Just like methods with `Self: Sized` bounds are unavailable on trait
3535     /// objects, associated types can be removed from the trait object.
3536     pub UNUSED_ASSOCIATED_TYPE_BOUNDS,
3537     Warn,
3538     "detects unused `Foo = Bar` bounds in `dyn Trait<Foo = Bar>`"
3539 }
3540
3541 declare_lint! {
3542     /// The `unused_doc_comments` lint detects doc comments that aren't used
3543     /// by `rustdoc`.
3544     ///
3545     /// ### Example
3546     ///
3547     /// ```rust
3548     /// /// docs for x
3549     /// let x = 12;
3550     /// ```
3551     ///
3552     /// {{produces}}
3553     ///
3554     /// ### Explanation
3555     ///
3556     /// `rustdoc` does not use doc comments in all positions, and so the doc
3557     /// comment will be ignored. Try changing it to a normal comment with `//`
3558     /// to avoid the warning.
3559     pub UNUSED_DOC_COMMENTS,
3560     Warn,
3561     "detects doc comments that aren't used by rustdoc"
3562 }
3563
3564 declare_lint! {
3565     /// The `rust_2021_incompatible_closure_captures` lint detects variables that aren't completely
3566     /// captured in Rust 2021, such that the `Drop` order of their fields may differ between
3567     /// Rust 2018 and 2021.
3568     ///
3569     /// It can also detect when a variable implements a trait like `Send`, but one of its fields does not,
3570     /// and the field is captured by a closure and used with the assumption that said field implements
3571     /// the same trait as the root variable.
3572     ///
3573     /// ### Example of drop reorder
3574     ///
3575     /// ```rust,edition2018,compile_fail
3576     /// #![deny(rust_2021_incompatible_closure_captures)]
3577     /// # #![allow(unused)]
3578     ///
3579     /// struct FancyInteger(i32);
3580     ///
3581     /// impl Drop for FancyInteger {
3582     ///     fn drop(&mut self) {
3583     ///         println!("Just dropped {}", self.0);
3584     ///     }
3585     /// }
3586     ///
3587     /// struct Point { x: FancyInteger, y: FancyInteger }
3588     ///
3589     /// fn main() {
3590     ///   let p = Point { x: FancyInteger(10), y: FancyInteger(20) };
3591     ///
3592     ///   let c = || {
3593     ///      let x = p.x;
3594     ///   };
3595     ///
3596     ///   c();
3597     ///
3598     ///   // ... More code ...
3599     /// }
3600     /// ```
3601     ///
3602     /// {{produces}}
3603     ///
3604     /// ### Explanation
3605     ///
3606     /// In the above example, `p.y` will be dropped at the end of `f` instead of
3607     /// with `c` in Rust 2021.
3608     ///
3609     /// ### Example of auto-trait
3610     ///
3611     /// ```rust,edition2018,compile_fail
3612     /// #![deny(rust_2021_incompatible_closure_captures)]
3613     /// use std::thread;
3614     ///
3615     /// struct Pointer(*mut i32);
3616     /// unsafe impl Send for Pointer {}
3617     ///
3618     /// fn main() {
3619     ///     let mut f = 10;
3620     ///     let fptr = Pointer(&mut f as *mut i32);
3621     ///     thread::spawn(move || unsafe {
3622     ///         *fptr.0 = 20;
3623     ///     });
3624     /// }
3625     /// ```
3626     ///
3627     /// {{produces}}
3628     ///
3629     /// ### Explanation
3630     ///
3631     /// In the above example, only `fptr.0` is captured in Rust 2021.
3632     /// The field is of type `*mut i32`, which doesn't implement `Send`,
3633     /// making the code invalid as the field cannot be sent between threads safely.
3634     pub RUST_2021_INCOMPATIBLE_CLOSURE_CAPTURES,
3635     Allow,
3636     "detects closures affected by Rust 2021 changes",
3637     @future_incompatible = FutureIncompatibleInfo {
3638         reason: FutureIncompatibilityReason::EditionSemanticsChange(Edition::Edition2021),
3639         explain_reason: false,
3640     };
3641 }
3642
3643 declare_lint_pass!(UnusedDocComment => [UNUSED_DOC_COMMENTS]);
3644
3645 declare_lint! {
3646     /// The `missing_abi` lint detects cases where the ABI is omitted from
3647     /// extern declarations.
3648     ///
3649     /// ### Example
3650     ///
3651     /// ```rust,compile_fail
3652     /// #![deny(missing_abi)]
3653     ///
3654     /// extern fn foo() {}
3655     /// ```
3656     ///
3657     /// {{produces}}
3658     ///
3659     /// ### Explanation
3660     ///
3661     /// Historically, Rust implicitly selected C as the ABI for extern
3662     /// declarations. We expect to add new ABIs, like `C-unwind`, in the future,
3663     /// though this has not yet happened, and especially with their addition
3664     /// seeing the ABI easily will make code review easier.
3665     pub MISSING_ABI,
3666     Allow,
3667     "No declared ABI for extern declaration"
3668 }
3669
3670 declare_lint! {
3671     /// The `invalid_doc_attributes` lint detects when the `#[doc(...)]` is
3672     /// misused.
3673     ///
3674     /// ### Example
3675     ///
3676     /// ```rust,compile_fail
3677     /// #![deny(warnings)]
3678     ///
3679     /// pub mod submodule {
3680     ///     #![doc(test(no_crate_inject))]
3681     /// }
3682     /// ```
3683     ///
3684     /// {{produces}}
3685     ///
3686     /// ### Explanation
3687     ///
3688     /// Previously, incorrect usage of the `#[doc(..)]` attribute was not
3689     /// being validated. Usually these should be rejected as a hard error,
3690     /// but this lint was introduced to avoid breaking any existing
3691     /// crates which included them.
3692     ///
3693     /// This is a [future-incompatible] lint to transition this to a hard
3694     /// error in the future. See [issue #82730] for more details.
3695     ///
3696     /// [issue #82730]: https://github.com/rust-lang/rust/issues/82730
3697     pub INVALID_DOC_ATTRIBUTES,
3698     Warn,
3699     "detects invalid `#[doc(...)]` attributes",
3700     @future_incompatible = FutureIncompatibleInfo {
3701         reference: "issue #82730 <https://github.com/rust-lang/rust/issues/82730>",
3702     };
3703 }
3704
3705 declare_lint! {
3706     /// The `proc_macro_back_compat` lint detects uses of old versions of certain
3707     /// proc-macro crates, which have hardcoded workarounds in the compiler.
3708     ///
3709     /// ### Example
3710     ///
3711     /// ```rust,ignore (needs-dependency)
3712     ///
3713     /// use time_macros_impl::impl_macros;
3714     /// struct Foo;
3715     /// impl_macros!(Foo);
3716     /// ```
3717     ///
3718     /// This will produce:
3719     ///
3720     /// ```text
3721     /// warning: using an old version of `time-macros-impl`
3722     ///   ::: $DIR/group-compat-hack.rs:27:5
3723     ///    |
3724     /// LL |     impl_macros!(Foo);
3725     ///    |     ------------------ in this macro invocation
3726     ///    |
3727     ///    = note: `#[warn(proc_macro_back_compat)]` on by default
3728     ///    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
3729     ///    = note: for more information, see issue #83125 <https://github.com/rust-lang/rust/issues/83125>
3730     ///    = 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
3731     ///    = note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
3732     /// ```
3733     ///
3734     /// ### Explanation
3735     ///
3736     /// Eventually, the backwards-compatibility hacks present in the compiler will be removed,
3737     /// causing older versions of certain crates to stop compiling.
3738     /// This is a [future-incompatible] lint to ease the transition to an error.
3739     /// See [issue #83125] for more details.
3740     ///
3741     /// [issue #83125]: https://github.com/rust-lang/rust/issues/83125
3742     /// [future-incompatible]: ../index.md#future-incompatible-lints
3743     pub PROC_MACRO_BACK_COMPAT,
3744     Deny,
3745     "detects usage of old versions of certain proc-macro crates",
3746     @future_incompatible = FutureIncompatibleInfo {
3747         reference: "issue #83125 <https://github.com/rust-lang/rust/issues/83125>",
3748         reason: FutureIncompatibilityReason::FutureReleaseErrorReportNow,
3749     };
3750 }
3751
3752 declare_lint! {
3753     /// The `rust_2021_incompatible_or_patterns` lint detects usage of old versions of or-patterns.
3754     ///
3755     /// ### Example
3756     ///
3757     /// ```rust,compile_fail
3758     /// #![deny(rust_2021_incompatible_or_patterns)]
3759     ///
3760     /// macro_rules! match_any {
3761     ///     ( $expr:expr , $( $( $pat:pat )|+ => $expr_arm:expr ),+ ) => {
3762     ///         match $expr {
3763     ///             $(
3764     ///                 $( $pat => $expr_arm, )+
3765     ///             )+
3766     ///         }
3767     ///     };
3768     /// }
3769     ///
3770     /// fn main() {
3771     ///     let result: Result<i64, i32> = Err(42);
3772     ///     let int: i64 = match_any!(result, Ok(i) | Err(i) => i.into());
3773     ///     assert_eq!(int, 42);
3774     /// }
3775     /// ```
3776     ///
3777     /// {{produces}}
3778     ///
3779     /// ### Explanation
3780     ///
3781     /// In Rust 2021, the `pat` matcher will match additional patterns, which include the `|` character.
3782     pub RUST_2021_INCOMPATIBLE_OR_PATTERNS,
3783     Allow,
3784     "detects usage of old versions of or-patterns",
3785     @future_incompatible = FutureIncompatibleInfo {
3786         reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2021/or-patterns-macro-rules.html>",
3787         reason: FutureIncompatibilityReason::EditionError(Edition::Edition2021),
3788     };
3789 }
3790
3791 declare_lint! {
3792     /// The `rust_2021_prelude_collisions` lint detects the usage of trait methods which are ambiguous
3793     /// with traits added to the prelude in future editions.
3794     ///
3795     /// ### Example
3796     ///
3797     /// ```rust,compile_fail
3798     /// #![deny(rust_2021_prelude_collisions)]
3799     ///
3800     /// trait Foo {
3801     ///     fn try_into(self) -> Result<String, !>;
3802     /// }
3803     ///
3804     /// impl Foo for &str {
3805     ///     fn try_into(self) -> Result<String, !> {
3806     ///         Ok(String::from(self))
3807     ///     }
3808     /// }
3809     ///
3810     /// fn main() {
3811     ///     let x: String = "3".try_into().unwrap();
3812     ///     //                  ^^^^^^^^
3813     ///     // This call to try_into matches both Foo::try_into and TryInto::try_into as
3814     ///     // `TryInto` has been added to the Rust prelude in 2021 edition.
3815     ///     println!("{x}");
3816     /// }
3817     /// ```
3818     ///
3819     /// {{produces}}
3820     ///
3821     /// ### Explanation
3822     ///
3823     /// In Rust 2021, one of the important introductions is the [prelude changes], which add
3824     /// `TryFrom`, `TryInto`, and `FromIterator` into the standard library's prelude. Since this
3825     /// results in an ambiguity as to which method/function to call when an existing `try_into`
3826     /// method is called via dot-call syntax or a `try_from`/`from_iter` associated function
3827     /// is called directly on a type.
3828     ///
3829     /// [prelude changes]: https://blog.rust-lang.org/inside-rust/2021/03/04/planning-rust-2021.html#prelude-changes
3830     pub RUST_2021_PRELUDE_COLLISIONS,
3831     Allow,
3832     "detects the usage of trait methods which are ambiguous with traits added to the \
3833         prelude in future editions",
3834     @future_incompatible = FutureIncompatibleInfo {
3835         reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2021/prelude.html>",
3836         reason: FutureIncompatibilityReason::EditionError(Edition::Edition2021),
3837     };
3838 }
3839
3840 declare_lint! {
3841     /// The `rust_2021_prefixes_incompatible_syntax` lint detects identifiers that will be parsed as a
3842     /// prefix instead in Rust 2021.
3843     ///
3844     /// ### Example
3845     ///
3846     /// ```rust,edition2018,compile_fail
3847     /// #![deny(rust_2021_prefixes_incompatible_syntax)]
3848     ///
3849     /// macro_rules! m {
3850     ///     (z $x:expr) => ();
3851     /// }
3852     ///
3853     /// m!(z"hey");
3854     /// ```
3855     ///
3856     /// {{produces}}
3857     ///
3858     /// ### Explanation
3859     ///
3860     /// In Rust 2015 and 2018, `z"hey"` is two tokens: the identifier `z`
3861     /// followed by the string literal `"hey"`. In Rust 2021, the `z` is
3862     /// considered a prefix for `"hey"`.
3863     ///
3864     /// This lint suggests to add whitespace between the `z` and `"hey"` tokens
3865     /// to keep them separated in Rust 2021.
3866     // Allow this lint -- rustdoc doesn't yet support threading edition into this lint's parser.
3867     #[allow(rustdoc::invalid_rust_codeblocks)]
3868     pub RUST_2021_PREFIXES_INCOMPATIBLE_SYNTAX,
3869     Allow,
3870     "identifiers that will be parsed as a prefix in Rust 2021",
3871     @future_incompatible = FutureIncompatibleInfo {
3872         reference: "<https://doc.rust-lang.org/nightly/edition-guide/rust-2021/reserving-syntax.html>",
3873         reason: FutureIncompatibilityReason::EditionError(Edition::Edition2021),
3874     };
3875     crate_level_only
3876 }
3877
3878 declare_lint! {
3879     /// The `unsupported_calling_conventions` lint is output whenever there is a use of the
3880     /// `stdcall`, `fastcall`, `thiscall`, `vectorcall` calling conventions (or their unwind
3881     /// variants) on targets that cannot meaningfully be supported for the requested target.
3882     ///
3883     /// For example `stdcall` does not make much sense for a x86_64 or, more apparently, powerpc
3884     /// code, because this calling convention was never specified for those targets.
3885     ///
3886     /// Historically MSVC toolchains have fallen back to the regular C calling convention for
3887     /// targets other than x86, but Rust doesn't really see a similar need to introduce a similar
3888     /// hack across many more targets.
3889     ///
3890     /// ### Example
3891     ///
3892     /// ```rust,ignore (needs specific targets)
3893     /// extern "stdcall" fn stdcall() {}
3894     /// ```
3895     ///
3896     /// This will produce:
3897     ///
3898     /// ```text
3899     /// warning: use of calling convention not supported on this target
3900     ///   --> $DIR/unsupported.rs:39:1
3901     ///    |
3902     /// LL | extern "stdcall" fn stdcall() {}
3903     ///    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3904     ///    |
3905     ///    = note: `#[warn(unsupported_calling_conventions)]` on by default
3906     ///    = warning: this was previously accepted by the compiler but is being phased out;
3907     ///               it will become a hard error in a future release!
3908     ///    = note: for more information, see issue ...
3909     /// ```
3910     ///
3911     /// ### Explanation
3912     ///
3913     /// On most of the targets the behaviour of `stdcall` and similar calling conventions is not
3914     /// defined at all, but was previously accepted due to a bug in the implementation of the
3915     /// compiler.
3916     pub UNSUPPORTED_CALLING_CONVENTIONS,
3917     Warn,
3918     "use of unsupported calling convention",
3919     @future_incompatible = FutureIncompatibleInfo {
3920         reference: "issue #87678 <https://github.com/rust-lang/rust/issues/87678>",
3921     };
3922 }
3923
3924 declare_lint! {
3925     /// The `break_with_label_and_loop` lint detects labeled `break` expressions with
3926     /// an unlabeled loop as their value expression.
3927     ///
3928     /// ### Example
3929     ///
3930     /// ```rust
3931     /// 'label: loop {
3932     ///     break 'label loop { break 42; };
3933     /// };
3934     /// ```
3935     ///
3936     /// {{produces}}
3937     ///
3938     /// ### Explanation
3939     ///
3940     /// In Rust, loops can have a label, and `break` expressions can refer to that label to
3941     /// break out of specific loops (and not necessarily the innermost one). `break` expressions
3942     /// can also carry a value expression, which can be another loop. A labeled `break` with an
3943     /// unlabeled loop as its value expression is easy to confuse with an unlabeled break with
3944     /// a labeled loop and is thus discouraged (but allowed for compatibility); use parentheses
3945     /// around the loop expression to silence this warning. Unlabeled `break` expressions with
3946     /// labeled loops yield a hard error, which can also be silenced by wrapping the expression
3947     /// in parentheses.
3948     pub BREAK_WITH_LABEL_AND_LOOP,
3949     Warn,
3950     "`break` expression with label and unlabeled loop as value expression"
3951 }
3952
3953 declare_lint! {
3954     /// The `non_exhaustive_omitted_patterns` lint detects when a wildcard (`_` or `..`) in a
3955     /// pattern for a `#[non_exhaustive]` struct or enum is reachable.
3956     ///
3957     /// ### Example
3958     ///
3959     /// ```rust,ignore (needs separate crate)
3960     /// // crate A
3961     /// #[non_exhaustive]
3962     /// pub enum Bar {
3963     ///     A,
3964     ///     B, // added variant in non breaking change
3965     /// }
3966     ///
3967     /// // in crate B
3968     /// #![feature(non_exhaustive_omitted_patterns_lint)]
3969     /// match Bar::A {
3970     ///     Bar::A => {},
3971     ///     #[warn(non_exhaustive_omitted_patterns)]
3972     ///     _ => {},
3973     /// }
3974     /// ```
3975     ///
3976     /// This will produce:
3977     ///
3978     /// ```text
3979     /// warning: reachable patterns not covered of non exhaustive enum
3980     ///    --> $DIR/reachable-patterns.rs:70:9
3981     ///    |
3982     /// LL |         _ => {}
3983     ///    |         ^ pattern `B` not covered
3984     ///    |
3985     ///  note: the lint level is defined here
3986     ///   --> $DIR/reachable-patterns.rs:69:16
3987     ///    |
3988     /// LL |         #[warn(non_exhaustive_omitted_patterns)]
3989     ///    |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3990     ///    = help: ensure that all possible cases are being handled by adding the suggested match arms
3991     ///    = note: the matched value is of type `Bar` and the `non_exhaustive_omitted_patterns` attribute was found
3992     /// ```
3993     ///
3994     /// ### Explanation
3995     ///
3996     /// Structs and enums tagged with `#[non_exhaustive]` force the user to add a
3997     /// (potentially redundant) wildcard when pattern-matching, to allow for future
3998     /// addition of fields or variants. The `non_exhaustive_omitted_patterns` lint
3999     /// detects when such a wildcard happens to actually catch some fields/variants.
4000     /// In other words, when the match without the wildcard would not be exhaustive.
4001     /// This lets the user be informed if new fields/variants were added.
4002     pub NON_EXHAUSTIVE_OMITTED_PATTERNS,
4003     Allow,
4004     "detect when patterns of types marked `non_exhaustive` are missed",
4005     @feature_gate = sym::non_exhaustive_omitted_patterns_lint;
4006 }
4007
4008 declare_lint! {
4009     /// The `text_direction_codepoint_in_comment` lint detects Unicode codepoints in comments that
4010     /// change the visual representation of text on screen in a way that does not correspond to
4011     /// their on memory representation.
4012     ///
4013     /// ### Example
4014     ///
4015     /// ```rust,compile_fail
4016     /// #![deny(text_direction_codepoint_in_comment)]
4017     /// fn main() {
4018     ///     println!("{:?}"); // '‮');
4019     /// }
4020     /// ```
4021     ///
4022     /// {{produces}}
4023     ///
4024     /// ### Explanation
4025     ///
4026     /// Unicode allows changing the visual flow of text on screen in order to support scripts that
4027     /// are written right-to-left, but a specially crafted comment can make code that will be
4028     /// compiled appear to be part of a comment, depending on the software used to read the code.
4029     /// To avoid potential problems or confusion, such as in CVE-2021-42574, by default we deny
4030     /// their use.
4031     pub TEXT_DIRECTION_CODEPOINT_IN_COMMENT,
4032     Deny,
4033     "invisible directionality-changing codepoints in comment"
4034 }
4035
4036 declare_lint! {
4037     /// The `duplicate_macro_attributes` lint detects when a `#[test]`-like built-in macro
4038     /// attribute is duplicated on an item. This lint may trigger on `bench`, `cfg_eval`, `test`
4039     /// and `test_case`.
4040     ///
4041     /// ### Example
4042     ///
4043     /// ```rust,ignore (needs --test)
4044     /// #[test]
4045     /// #[test]
4046     /// fn foo() {}
4047     /// ```
4048     ///
4049     /// This will produce:
4050     ///
4051     /// ```text
4052     /// warning: duplicated attribute
4053     ///  --> src/lib.rs:2:1
4054     ///   |
4055     /// 2 | #[test]
4056     ///   | ^^^^^^^
4057     ///   |
4058     ///   = note: `#[warn(duplicate_macro_attributes)]` on by default
4059     /// ```
4060     ///
4061     /// ### Explanation
4062     ///
4063     /// A duplicated attribute may erroneously originate from a copy-paste and the effect of it
4064     /// being duplicated may not be obvious or desirable.
4065     ///
4066     /// For instance, doubling the `#[test]` attributes registers the test to be run twice with no
4067     /// change to its environment.
4068     ///
4069     /// [issue #90979]: https://github.com/rust-lang/rust/issues/90979
4070     pub DUPLICATE_MACRO_ATTRIBUTES,
4071     Warn,
4072     "duplicated attribute"
4073 }
4074
4075 declare_lint! {
4076     /// The `suspicious_auto_trait_impls` lint checks for potentially incorrect
4077     /// implementations of auto traits.
4078     ///
4079     /// ### Example
4080     ///
4081     /// ```rust
4082     /// struct Foo<T>(T);
4083     ///
4084     /// unsafe impl<T> Send for Foo<*const T> {}
4085     /// ```
4086     ///
4087     /// {{produces}}
4088     ///
4089     /// ### Explanation
4090     ///
4091     /// A type can implement auto traits, e.g. `Send`, `Sync` and `Unpin`,
4092     /// in two different ways: either by writing an explicit impl or if
4093     /// all fields of the type implement that auto trait.
4094     ///
4095     /// The compiler disables the automatic implementation if an explicit one
4096     /// exists for given type constructor. The exact rules governing this
4097     /// were previously unsound, quite subtle, and have been recently modified.
4098     /// This change caused the automatic implementation to be disabled in more
4099     /// cases, potentially breaking some code.
4100     pub SUSPICIOUS_AUTO_TRAIT_IMPLS,
4101     Warn,
4102     "the rules governing auto traits have recently changed resulting in potential breakage",
4103     @future_incompatible = FutureIncompatibleInfo {
4104         reason: FutureIncompatibilityReason::FutureReleaseSemanticsChange,
4105         reference: "issue #93367 <https://github.com/rust-lang/rust/issues/93367>",
4106     };
4107 }
4108
4109 declare_lint! {
4110     /// The `deprecated_where_clause_location` lint detects when a where clause in front of the equals
4111     /// in an associated type.
4112     ///
4113     /// ### Example
4114     ///
4115     /// ```rust
4116     /// trait Trait {
4117     ///   type Assoc<'a> where Self: 'a;
4118     /// }
4119     ///
4120     /// impl Trait for () {
4121     ///   type Assoc<'a> where Self: 'a = ();
4122     /// }
4123     /// ```
4124     ///
4125     /// {{produces}}
4126     ///
4127     /// ### Explanation
4128     ///
4129     /// The preferred location for where clauses on associated types
4130     /// is after the type. However, for most of generic associated types development,
4131     /// it was only accepted before the equals. To provide a transition period and
4132     /// further evaluate this change, both are currently accepted. At some point in
4133     /// the future, this may be disallowed at an edition boundary; but, that is
4134     /// undecided currently.
4135     pub DEPRECATED_WHERE_CLAUSE_LOCATION,
4136     Warn,
4137     "deprecated where clause location"
4138 }
4139
4140 declare_lint! {
4141     /// The `test_unstable_lint` lint tests unstable lints and is perma-unstable.
4142     ///
4143     /// ### Example
4144     ///
4145     /// ```rust
4146     /// #![allow(test_unstable_lint)]
4147     /// ```
4148     ///
4149     /// {{produces}}
4150     ///
4151     /// ### Explanation
4152     ///
4153     /// In order to test the behavior of unstable lints, a permanently-unstable
4154     /// lint is required. This lint can be used to trigger warnings and errors
4155     /// from the compiler related to unstable lints.
4156     pub TEST_UNSTABLE_LINT,
4157     Deny,
4158     "this unstable lint is only for testing",
4159     @feature_gate = sym::test_unstable_lint;
4160 }
4161
4162 declare_lint! {
4163     /// The `ffi_unwind_calls` lint detects calls to foreign functions or function pointers with
4164     /// `C-unwind` or other FFI-unwind ABIs.
4165     ///
4166     /// ### Example
4167     ///
4168     /// ```rust
4169     /// #![warn(ffi_unwind_calls)]
4170     ///
4171     /// extern "C-unwind" {
4172     ///     fn foo();
4173     /// }
4174     ///
4175     /// fn bar() {
4176     ///     unsafe { foo(); }
4177     ///     let ptr: unsafe extern "C-unwind" fn() = foo;
4178     ///     unsafe { ptr(); }
4179     /// }
4180     /// ```
4181     ///
4182     /// {{produces}}
4183     ///
4184     /// ### Explanation
4185     ///
4186     /// For crates containing such calls, if they are compiled with `-C panic=unwind` then the
4187     /// produced library cannot be linked with crates compiled with `-C panic=abort`. For crates
4188     /// that desire this ability it is therefore necessary to avoid such calls.
4189     pub FFI_UNWIND_CALLS,
4190     Allow,
4191     "call to foreign functions or function pointers with FFI-unwind ABI"
4192 }
4193
4194 declare_lint! {
4195     /// The `named_arguments_used_positionally` lint detects cases where named arguments are only
4196     /// used positionally in format strings. This usage is valid but potentially very confusing.
4197     ///
4198     /// ### Example
4199     ///
4200     /// ```rust,compile_fail
4201     /// #![deny(named_arguments_used_positionally)]
4202     /// fn main() {
4203     ///     let _x = 5;
4204     ///     println!("{}", _x = 1); // Prints 1, will trigger lint
4205     ///
4206     ///     println!("{}", _x); // Prints 5, no lint emitted
4207     ///     println!("{_x}", _x = _x); // Prints 5, no lint emitted
4208     /// }
4209     /// ```
4210     ///
4211     /// {{produces}}
4212     ///
4213     /// ### Explanation
4214     ///
4215     /// Rust formatting strings can refer to named arguments by their position, but this usage is
4216     /// potentially confusing. In particular, readers can incorrectly assume that the declaration
4217     /// of named arguments is an assignment (which would produce the unit type).
4218     /// For backwards compatibility, this is not a hard error.
4219     pub NAMED_ARGUMENTS_USED_POSITIONALLY,
4220     Warn,
4221     "named arguments in format used positionally"
4222 }
4223
4224 declare_lint! {
4225     /// The `implied_bounds_entailment` lint detects cases where the arguments of an impl method
4226     /// have stronger implied bounds than those from the trait method it's implementing.
4227     ///
4228     /// ### Example
4229     ///
4230     /// ```rust,compile_fail
4231     /// #![deny(implied_bounds_entailment)]
4232     ///
4233     /// trait Trait {
4234     ///     fn get<'s>(s: &'s str, _: &'static &'static ()) -> &'static str;
4235     /// }
4236     ///
4237     /// impl Trait for () {
4238     ///     fn get<'s>(s: &'s str, _: &'static &'s ()) -> &'static str {
4239     ///         s
4240     ///     }
4241     /// }
4242     ///
4243     /// let val = <() as Trait>::get(&String::from("blah blah blah"), &&());
4244     /// println!("{}", val);
4245     /// ```
4246     ///
4247     /// {{produces}}
4248     ///
4249     /// ### Explanation
4250     ///
4251     /// Neither the trait method, which provides no implied bounds about `'s`, nor the impl,
4252     /// requires the main function to prove that 's: 'static, but the impl method is allowed
4253     /// to assume that `'s: 'static` within its own body.
4254     ///
4255     /// This can be used to implement an unsound API if used incorrectly.
4256     pub IMPLIED_BOUNDS_ENTAILMENT,
4257     Deny,
4258     "impl method assumes more implied bounds than its corresponding trait method",
4259     @future_incompatible = FutureIncompatibleInfo {
4260         reference: "issue #105572 <https://github.com/rust-lang/rust/issues/105572>",
4261         reason: FutureIncompatibilityReason::FutureReleaseErrorReportNow,
4262     };
4263 }
4264
4265 declare_lint! {
4266     /// The `byte_slice_in_packed_struct_with_derive` lint detects cases where a byte slice field
4267     /// (`[u8]`) or string slice field (`str`) is used in a `packed` struct that derives one or
4268     /// more built-in traits.
4269     ///
4270     /// ### Example
4271     ///
4272     /// ```rust
4273     /// #[repr(packed)]
4274     /// #[derive(Hash)]
4275     /// struct FlexZeroSlice {
4276     ///     width: u8,
4277     ///     data: [u8],
4278     /// }
4279     /// ```
4280     ///
4281     /// {{produces}}
4282     ///
4283     /// ### Explanation
4284     ///
4285     /// This was previously accepted but is being phased out, because fields in packed structs are
4286     /// now required to implement `Copy` for `derive` to work. Byte slices and string slices are a
4287     /// temporary exception because certain crates depended on them.
4288     pub BYTE_SLICE_IN_PACKED_STRUCT_WITH_DERIVE,
4289     Warn,
4290     "`[u8]` or `str` used in a packed struct with `derive`",
4291     @future_incompatible = FutureIncompatibleInfo {
4292         reference: "issue #107457 <https://github.com/rust-lang/rust/issues/107457>",
4293         reason: FutureIncompatibilityReason::FutureReleaseErrorReportNow,
4294     };
4295     report_in_external_macro
4296 }
4297
4298 declare_lint! {
4299     /// The `invalid_macro_export_arguments` lint detects cases where `#[macro_export]` is being used with invalid arguments.
4300     ///
4301     /// ### Example
4302     ///
4303     /// ```rust,compile_fail
4304     /// #![deny(invalid_macro_export_arguments)]
4305     ///
4306     /// #[macro_export(invalid_parameter)]
4307     /// macro_rules! myMacro {
4308     ///    () => {
4309     ///         // [...]
4310     ///    }
4311     /// }
4312     ///
4313     /// #[macro_export(too, many, items)]
4314     /// ```
4315     ///
4316     /// {{produces}}
4317     ///
4318     /// ### Explanation
4319     ///
4320     /// The only valid argument is `#[macro_export(local_inner_macros)]` or no argument (`#[macro_export]`).
4321     /// You can't have multiple arguments in a `#[macro_export(..)]`, or mention arguments other than `local_inner_macros`.
4322     ///
4323     pub INVALID_MACRO_EXPORT_ARGUMENTS,
4324     Warn,
4325     "\"invalid_parameter\" isn't a valid argument for `#[macro_export]`",
4326 }
4327
4328 declare_lint! {
4329     /// The `private_interfaces` lint detects types in a primary interface of an item,
4330     /// that are more private than the item itself. Primary interface of an item is all
4331     /// its interface except for bounds on generic parameters and where clauses.
4332     ///
4333     /// ### Example
4334     ///
4335     /// ```rust,compile_fail
4336     /// # #![feature(type_privacy_lints)]
4337     /// # #![allow(unused)]
4338     /// # #![allow(private_in_public)]
4339     /// #![deny(private_interfaces)]
4340     /// struct SemiPriv;
4341     ///
4342     /// mod m1 {
4343     ///     struct Priv;
4344     ///     impl crate::SemiPriv {
4345     ///         pub fn f(_: Priv) {}
4346     ///     }
4347     /// }
4348     ///
4349     /// # fn main() {}
4350     /// ```
4351     ///
4352     /// {{produces}}
4353     ///
4354     /// ### Explanation
4355     ///
4356     /// Having something private in primary interface guarantees that
4357     /// the item will be unusable from outer modules due to type privacy.
4358     pub PRIVATE_INTERFACES,
4359     Allow,
4360     "private type in primary interface of an item",
4361     @feature_gate = sym::type_privacy_lints;
4362 }
4363
4364 declare_lint! {
4365     /// The `private_bounds` lint detects types in a secondary interface of an item,
4366     /// that are more private than the item itself. Secondary interface of an item consists of
4367     /// bounds on generic parameters and where clauses, including supertraits for trait items.
4368     ///
4369     /// ### Example
4370     ///
4371     /// ```rust,compile_fail
4372     /// # #![feature(type_privacy_lints)]
4373     /// # #![allow(private_in_public)]
4374     /// # #![allow(unused)]
4375     /// #![deny(private_bounds)]
4376     ///
4377     /// struct PrivTy;
4378     /// pub struct S
4379     ///     where PrivTy:
4380     /// {}
4381     /// # fn main() {}
4382     /// ```
4383     ///
4384     /// {{produces}}
4385     ///
4386     /// ### Explanation
4387     ///
4388     /// Having private types or traits in item bounds makes it less clear what interface
4389     /// the item actually provides.
4390     pub PRIVATE_BOUNDS,
4391     Allow,
4392     "private type in secondary interface of an item",
4393     @feature_gate = sym::type_privacy_lints;
4394 }
4395
4396 declare_lint! {
4397     /// The `unnameable_types` lint detects types for which you can get objects of that type,
4398     /// but cannot name the type itself.
4399     ///
4400     /// ### Example
4401     ///
4402     /// ```rust,compile_fail
4403     /// # #![feature(type_privacy_lints)]
4404     /// # #![allow(unused)]
4405     /// #![deny(unnameable_types)]
4406     /// mod m {
4407     ///     pub struct S;
4408     /// }
4409     ///
4410     /// pub fn get_voldemort() -> m::S { m::S }
4411     /// # fn main() {}
4412     /// ```
4413     ///
4414     /// {{produces}}
4415     ///
4416     /// ### Explanation
4417     ///
4418     /// It is often expected that if you can obtain an object of type `T`, then
4419     /// you can name the type `T` as well, this lint attempts to enforce this rule.
4420     pub UNNAMEABLE_TYPES,
4421     Allow,
4422     "effective visibility of a type is larger than the area in which it can be named",
4423     @feature_gate = sym::type_privacy_lints;
4424 }
4425
4426 declare_lint! {
4427     /// The `coinductive_overlap_in_coherence` lint detects impls which are currently
4428     /// considered not overlapping, but may be considered to overlap if support for
4429     /// coinduction is added to the trait solver.
4430     ///
4431     /// ### Example
4432     ///
4433     /// ```rust,compile_fail
4434     /// #![deny(coinductive_overlap_in_coherence)]
4435     ///
4436     /// trait CyclicTrait {}
4437     /// impl<T: CyclicTrait> CyclicTrait for T {}
4438     ///
4439     /// trait Trait {}
4440     /// impl<T: CyclicTrait> Trait for T {}
4441     /// // conflicting impl with the above
4442     /// impl Trait for u8 {}
4443     /// ```
4444     ///
4445     /// {{produces}}
4446     ///
4447     /// ### Explanation
4448     ///
4449     /// We have two choices for impl which satisfy `u8: Trait`: the blanket impl
4450     /// for generic `T`, and the direct impl for `u8`. These two impls nominally
4451     /// overlap, since we can infer `T = u8` in the former impl, but since the where
4452     /// clause `u8: CyclicTrait` would end up resulting in a cycle (since it depends
4453     /// on itself), the blanket impl is not considered to hold for `u8`. This will
4454     /// change in a future release.
4455     pub COINDUCTIVE_OVERLAP_IN_COHERENCE,
4456     Warn,
4457     "impls that are not considered to overlap may be considered to \
4458     overlap in the future",
4459     @future_incompatible = FutureIncompatibleInfo {
4460         reference: "issue #114040 <https://github.com/rust-lang/rust/issues/114040>",
4461     };
4462 }
4463
4464 declare_lint! {
4465     /// The `unknown_diagnostic_attributes` lint detects unrecognized diagnostic attributes.
4466     ///
4467     /// ### Example
4468     ///
4469     /// ```rust
4470     /// #![feature(diagnostic_namespace)]
4471     /// #[diagnostic::does_not_exist]
4472     /// struct Foo;
4473     /// ```
4474     ///
4475     /// {{produces}}
4476     ///
4477     /// ### Explanation
4478     ///
4479     /// It is usually a mistake to specify a diagnostic attribute that does not exist. Check
4480     /// the spelling, and check the diagnostic attribute listing for the correct name. Also
4481     /// consider if you are using an old version of the compiler, and the attribute
4482     /// is only available in a newer version.
4483     pub UNKNOWN_DIAGNOSTIC_ATTRIBUTES,
4484     Warn,
4485     "unrecognized diagnostic attribute"
4486 }
4487
4488 declare_lint! {
4489     /// The `ambiguous_glob_imports` lint detects glob imports that should report ambiguity
4490     /// errors, but previously didn't do that due to rustc bugs.
4491     ///
4492     /// ### Example
4493     ///
4494     /// ```rust,compile_fail
4495     ///
4496     /// #![deny(ambiguous_glob_imports)]
4497     /// pub fn foo() -> u32 {
4498     ///     use sub::*;
4499     ///     C
4500     /// }
4501     ///
4502     /// mod sub {
4503     ///     mod mod1 { pub const C: u32 = 1; }
4504     ///     mod mod2 { pub const C: u32 = 2; }
4505     ///
4506     ///     pub use mod1::*;
4507     ///     pub use mod2::*;
4508     /// }
4509     /// ```
4510     ///
4511     /// {{produces}}
4512     ///
4513     /// ### Explanation
4514     ///
4515     /// Previous versions of Rust compile it successfully because it
4516     /// had lost the ambiguity error when resolve `use sub::mod2::*`.
4517     ///
4518     /// This is a [future-incompatible] lint to transition this to a
4519     /// hard error in the future.
4520     ///
4521     /// [future-incompatible]: ../index.md#future-incompatible-lints
4522     pub AMBIGUOUS_GLOB_IMPORTS,
4523     Warn,
4524     "detects certain glob imports that require reporting an ambiguity error",
4525     @future_incompatible = FutureIncompatibleInfo {
4526         reason: FutureIncompatibilityReason::FutureReleaseError,
4527         reference: "issue #114095 <https://github.com/rust-lang/rust/issues/114095>",
4528     };
4529 }