@@ -16,11 +16,12 @@ use crate::lints::MacroExprFragment2024;
1616use crate :: EarlyLintPass ;
1717
1818declare_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.
2121 ///
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.
2425 ///
2526 /// ### Example
2627 ///
@@ -41,21 +42,34 @@ declare_lint! {
4142 ///
4243 /// ### Explanation
4344 ///
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.
5050 ///
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.
5770 ///
5871 /// [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
5973 /// [`cargo fix`]: https://doc.rust-lang.org/cargo/commands/cargo-fix.html
6074 pub EDITION_2024_EXPR_FRAGMENT_SPECIFIER ,
6175 Allow ,
0 commit comments