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