-
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 rules: using lifetime specifier inside recursion causes local ambiguity #50903
Comments
The problem is that currently a lifetime "may start with anything" because we haven't spelled out the rules. Mentoring instructionEdit rust/src/libsyntax/ext/tt/macro_parser.rs Lines 725 to 739 in 5c3960c
You may also want to review this function to see if any case did not consider |
I'd like to take this issue |
I'm on a train right now with limited connectivity, so I cant push my PR, but I have a change that I've compiled and tested, and I'm not sure if it's working correctly, I could use some more background. I added this to may_begin_with, compiled and set as a custom toolchain all good so far
I created a new cargo bin project (I didn't see any tests for macro_parser or any test dirs in the libsyntax directory, not sure if there's a better way to do this) and made the main function define that macro and use it, as in the original example. With nightly it showed the expected ambiguity error. Then I used rustup overrides with my custom toolchain and rebuilt, and it compiled with no errors. Is this the expected behavior when parsing the macro? I'm unclear on how the macro parser works in rust. Is it that, before adding this branch, when parsing Also, you mentioned reviewing the rest of the function to see if other things didn't consider lifetime or other new syntax additions, but I'm not sure what other syntax additions there are to consider. |
@jrlusby
Yes this is the expected behavior. When This is similar to the behavior of macro_rules! no_bug {
($($lif2:ident ,)* #) => {};
}
fn main() {
no_bug!(a, #);
}
Basically to check the interaction with all other fragment specifiers, e.g. macro_rules! check {
(1. $($a:lifetime,)* $b:block) => {};
(2. $($b:block,)* $a:lifetime) => {};
}
fn main() {
check!(1. 'a, 'b, {});
check!(2. {}, {}, 'a);
} Interpolated lifetimes are encoded as (For new syntax I'd like to reserve |
apparently not |
Enable fall through past $:lifetime matcher ```rust macro_rules! is_lifetime { ($lifetime:lifetime) => { true }; ($other:tt) => { false }; } fn main() { println!("{}", is_lifetime!('lifetime)); println!("{}", is_lifetime!(@)); } ``` Before this fix, the `is_lifetime!` invocation would fail to compile with: ``` error: expected a lifetime, found `@` --> src/main.rs:8:33 | 8 | println!("{}", is_lifetime!(@)); | ^ ``` Fixes #50903. Fixes #51477. r? @kennytm
#
is not valid lifetime, so using:litetime
specifier should not cause local ambiguity.Example:
Playground link
cc tracking issue for $:lifetime matcher: #34303
The text was updated successfully, but these errors were encountered: