Skip to content

Commit 67a1eff

Browse files
committed
Revise the chapter on missing macro fragment specifiers
Now that this is a hard error in all editions, let's adjust the text a bit to make it clear what behavior is current and what is historical.
1 parent 29ed8fe commit 67a1eff

File tree

1 file changed

+5
-11
lines changed

1 file changed

+5
-11
lines changed
Lines changed: 5 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,14 @@
11
# Missing macro fragment specifiers
22

3-
> **NOTE**: `missing_fragment_specifier` was originally made a hard error only for the 2024 Edition. In the time since this edition was released, the lint has been made into a hard error for all editions.
3+
> **NOTE**: This was originally made a hard error only for the 2024 Edition. In Rust 1.89, released after Rust 2024, the lint was made into a hard error in all editions.
44
55
## Summary
66

77
- The `missing_fragment_specifier` lint is now a hard error.
88

99
## Details
1010

11-
The `missing_fragment_specifier` lint detects a situation when an **unused** pattern in a `macro_rules!` macro definition has a meta-variable (e.g. `$e`) that is not followed by a fragment specifier (e.g. `:expr`). This is now a hard error in the 2024 Edition.
11+
The `missing_fragment_specifier` lint detected a situation when an **unused** pattern in a `macro_rules!` macro definition had a meta-variable (e.g. `$e`) that was not followed by a fragment specifier (e.g. `:expr`). This was made into a hard error in the 2024 Edition.
1212

1313
```rust,compile_fail
1414
macro_rules! foo {
@@ -21,16 +21,10 @@ fn main() {
2121
}
2222
```
2323

24-
Calling the macro with arguments that would match a rule with a missing specifier (e.g., `foo!($name)`) is a hard error in all editions. However, simply defining a macro with missing fragment specifiers is not, though we did add a lint in Rust 1.17.
25-
26-
We'd like to make this a hard error in all editions, but there would be too much breakage right now. So we're starting by making this a hard error in Rust 2024.[^future-incompat]
27-
28-
[^future-incompat]: The lint is marked as a "future-incompatible" warning to indicate that it may become a hard error in all editions in a future release. See [#40107] for more information.
29-
30-
[#40107]: https://github.com/rust-lang/rust/issues/40107
24+
Calling the macro with arguments that would match a rule with a missing specifier (e.g., `foo!($name)`) was a hard error in all editions. However, simply defining a macro with missing fragment specifiers was not, though we did add a lint in Rust 1.17.
3125

3226
## Migration
3327

34-
To migrate your code to the 2024 Edition, remove the unused matcher rule from the macro. The `missing_fragment_specifier` lint is on by default in all editions, and should alert you to macros with this issue.
28+
To migrate your code to the 2024 Edition, remove the unused matcher rule from the macro.
3529

36-
There is no automatic migration for this change. We expect that this style of macro is extremely rare. The lint has been a future-incompatibility lint since Rust 1.17, a deny-by-default lint since Rust 1.20, and since Rust 1.82, it has warned about dependencies that are using this pattern.
30+
There is no automatic migration for this change. We expect that this style of macro is extremely rare. The lint was a future-incompatibility lint since Rust 1.17, a deny-by-default lint since Rust 1.20, since Rust 1.82 it warned about dependencies using this pattern, and in Rust 1.89 it became a hard error.

0 commit comments

Comments
 (0)