-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Macro input future proofing #20563
Macro input future proofing #20563
Conversation
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
See RFC 550 (rust-lang/rfcs#550) for the motivation and details. If this breaks your code, add one of the listed tokens after the relevant non-terminal in your matcher. [breaking-change]
fn check_matcher(cx: &mut ExtCtxt, matcher: &[TokenTree], follow: &Token) { | ||
use print::pprust::token_to_string; | ||
|
||
// 1. If there are no tokens in M, accept |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This case doesn't need to exist, does it?
OK, reviewed. Algorithm seems close but not quite right, particularly around adjacent non-terminals (which can't be soundly permitted without a |
@cmr I'm ok with |
Sorry, that was too strong. And we don't need type ascription, we already have |
I use this macro a lot: macro_rules! is_match {
($value:expr, $($pattern:pat)|+) => {
match $value {
$($pattern)|+ => true,
_ => false
}
}
} But it now gives |
For what it’s worth, upgrading rust-url to the latest nightly is blocked on this. |
@SimonSapin that combination is disallowed to provide for extending patterns with The only tokens allowed to follow |
@cmr, so there is no way to write a macro the accepts multiple patterns with the same syntax as |
@SimonSapin thanks for pointing this out! We were deliberately quite conservative in choosing the "follow sets" for this RFC as we can always expand them over time! For patterns specifically, I think we must allow If you'd like, you could open a PR modifying the relevant code to have a bit more discussion (someone should validate my thinking) |
Per rust-lang#20563 (comment) This enables writing macros that accept `$($pattern:pat)|+` and expand to the same thing in a `match` statement. See for example [the `matches!` macro](https://github.com/SimonSapin/rust-std-candidates#the-matches-macro).
Ok, @huonw suggested a work around that I’m happy with: #[macro_export]
macro_rules! matches {
($expression: expr, $($pattern:tt)+) => {
_tt_as_expr_hack! {
match $expression {
$($pattern)+ => true,
_ => false
}
}
}
}
/// Work around "error: unexpected token: `an interpolated tt`", whatever that means.
#[macro_export]
macro_rules! _tt_as_expr_hack {
($value:expr) => ($value)
}
matches!("foo", "bar" | "baz" => 42 > 9000, "fuzz"); |
Semicolon after ty is no longer supported. See rust-lang/rust#20563
Also, update description of macro invocation syntax: after rust-lang#20563 there is a number of additional limitations on macro syntax.
Implements RFC 550 (rust-lang/rfcs#550)