@@ -16,11 +16,12 @@ use crate::lints::MacroExprFragment2024;
16
16
use crate :: EarlyLintPass ;
17
17
18
18
declare_lint ! {
19
- /// The `edition_2024_expr_fragment_specifier` lint detects the use of `expr` fragments
20
- /// during migration to the 2024 edition.
19
+ /// The `edition_2024_expr_fragment_specifier` lint detects the use of
20
+ /// `expr` fragments in macros during migration to the 2024 edition.
21
21
///
22
- /// The `expr` fragment specifier will accept more expressions in the 2024 edition.
23
- /// To maintain the current behavior, use the `expr_2021` fragment specifier.
22
+ /// The `expr` fragment specifier will accept more expressions in the 2024
23
+ /// edition. To maintain the behavior from the 2021 edition and earlier, use
24
+ /// the `expr_2021` fragment specifier.
24
25
///
25
26
/// ### Example
26
27
///
@@ -41,21 +42,34 @@ declare_lint! {
41
42
///
42
43
/// ### Explanation
43
44
///
44
- /// Rust [editions] allow the language to evolve without breaking
45
- /// backwards compatibility. This lint catches code that uses new keywords
46
- /// that are added to the language that are used as identifiers (such as a
47
- /// variable name, function name, etc.). If you switch the compiler to a
48
- /// new edition without updating the code, then it will fail to compile if
49
- /// you are using a new keyword as an identifier.
45
+ /// Rust [editions] allow the language to evolve without breaking backwards
46
+ /// compatibility. This lint catches code that uses [macro matcher fragment
47
+ /// specifiers] that have changed meaning in the 2024 edition. If you switch
48
+ /// to the new edition without updating the code, your macros may behave
49
+ /// differently.
50
50
///
51
- /// This lint solves the problem automatically. It is "allow" by default
52
- /// because the code is perfectly valid in older editions. The [`cargo
53
- /// fix`] tool with the `--edition` flag will switch this lint to "warn"
54
- /// and automatically apply the suggested fix from the compiler.
55
- /// This provides a completely automated way to update old code for
56
- /// a new edition.
51
+ /// In the 2024 edition, the `expr` fragment specifier `expr` will also
52
+ /// match `const { ... }` blocks. This means if a macro had a pattern that
53
+ /// matched `$e:expr` and another that matches `const { $e: expr }`, for
54
+ /// example, that under the 2024 edition the first pattern would match while
55
+ /// in the 2021 and earlier editions the second pattern would match. To keep
56
+ /// the old behavior, use the `expr_2021` fragment specifier.
57
+ ///
58
+ /// This lint detects macros whose behavior might change due to the changing
59
+ /// meaning of the `expr` fragment specifier. It is "allow" by default
60
+ /// because the code is perfectly valid in older editions. The [`cargo fix`]
61
+ /// tool with the `--edition` flag will switch this lint to "warn" and
62
+ /// automatically apply the suggested fix from the compiler. This provides a
63
+ /// completely automated way to update old code for a new edition.
64
+ ///
65
+ /// Using `cargo fix --edition` with this lint will ensure that your code
66
+ /// retains the same behavior. This may not be the desired, as macro authors
67
+ /// often will want their macros to use the latest grammar for matching
68
+ /// expressions. Be sure to carefully review changes introduced by this lint
69
+ /// to ensure the macros implement the desired behavior.
57
70
///
58
71
/// [editions]: https://doc.rust-lang.org/edition-guide/
72
+ /// [macro matcher fragment specifiers]: https://doc.rust-lang.org/nightly/edition-guide/rust-2024/macro-fragment-specifiers.html
59
73
/// [`cargo fix`]: https://doc.rust-lang.org/cargo/commands/cargo-fix.html
60
74
pub EDITION_2024_EXPR_FRAGMENT_SPECIFIER ,
61
75
Allow ,
0 commit comments