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