Skip to content

Update references to the missing_fragment_specifier lint #376

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 7 additions & 13 deletions src/rust-2024/missing-macro-fragment-specifiers.md
Original file line number Diff line number Diff line change
@@ -1,14 +1,14 @@
# Missing macro fragment specifiers

## Summary
> **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.
- The [`missing_fragment_specifier`] lint is now a hard error.
## Summary

[`missing_fragment_specifier`]: ../../rustc/lints/listing/deny-by-default.html#missing-fragment-specifier
- The `missing_fragment_specifier` lint is now a hard error.

## Details

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.
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.

```rust,compile_fail
macro_rules! foo {
Expand All @@ -21,16 +21,10 @@ fn main() {
}
```

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.

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]

[^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.

[#40107]: https://github.com/rust-lang/rust/issues/40107
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.

## Migration

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.
To migrate your code to the 2024 Edition, remove the unused matcher rule from the macro.

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.
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.