Skip to content
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

Fragment specifiers in macro are not taken into account #35650

Closed
GuillaumeLestringant opened this issue Aug 13, 2016 · 7 comments · Fixed by #42913
Closed

Fragment specifiers in macro are not taken into account #35650

GuillaumeLestringant opened this issue Aug 13, 2016 · 7 comments · Fixed by #42913
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)

Comments

@GuillaumeLestringant
Copy link

Here is a minimum example of the problem.

macro_rules! size    {
    ($ty:ty) => {
        std::mem::size_of::<$ty>()
    };
    ($size:tt) => {
        $size
    };
}

fn main()   {
    println!("{}", size!(u32));
    println!("{}", size!(4));
}

Compilation fails with following error.

temp.rs:12:26: 12:27 error: expected type, found 4
temp.rs:12 println!("{}", size!(4));

Which means that the fragment qualifier is not taken into account to choose which variant of the macro is to be used.

@durka
Copy link
Contributor

durka commented Aug 13, 2016

Yeah, macros don't do backtracking. You'll need to adjust the matchers to provide some other way to disambiguate.

@GuillaumeLestringant
Copy link
Author

Yes, I obviously know that I could just put brackets or whatever around one of the patterns to make it distinct. But the whole point of having fragment qualifiers is precisely to distinguish between two otherwise identical patterns. If macros cannot do it although they have the perfect tool for it, then they are stupid and ought to be improved.

@durka
Copy link
Contributor

durka commented Aug 13, 2016

It wasn't obvious to me that you knew the workaround -- sorry for assuming!

Also see #33840.

@GuillaumeLestringant
Copy link
Author

Thanks for pointing the PR. It is blocked for now, but I suppose there is still hope.

Sorry for being harsh. I have been raging for months over how annoyingly limited and stupid Rust macros are, and I finally found a case general and obvious enough to justify my complaining…

@Mark-Simulacrum Mark-Simulacrum added the A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) label May 11, 2017
@Mark-Simulacrum
Copy link
Member

triage: Macros still don't backtrack. I can't find an issue for that, though I do suspect that one exists in some form. Labeling as A-macros, though.

@durka
Copy link
Contributor

durka commented May 11, 2017

@Mark-Simulacrum here is one (closed).

@Mark-Simulacrum
Copy link
Member

Closing in favor of #42838 -- macro rules do not backtrack.

kennytm added a commit to kennytm/rust that referenced this issue Jul 7, 2017
bors added a commit that referenced this issue Jul 11, 2017
…seyfried

Only match a fragment specifier the if it starts with certain tokens.

When trying to match a fragment specifier, we first predict whether the current token can be matched at all. If it cannot be matched, don't bother to push the Earley item to `bb_eis`. This can fix a lot of issues which otherwise requires full backtracking (#42838).

In this PR the prediction treatment is not done for `:item`, `:stmt` and `:tt`, but it could be expanded in the future.

Fixes #24189.
Fixes #26444.
Fixes #27832.
Fixes #34030.
Fixes #35650.
Fixes #39964.
Fixes the 4th comment in #40569.
Fixes the issue blocking #40984.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants