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