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

Parser mistakes macro argument for struct initialization? #15198

Closed
hannobraun opened this issue Jun 26, 2014 · 1 comment
Closed

Parser mistakes macro argument for struct initialization? #15198

hannobraun opened this issue Jun 26, 2014 · 1 comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)

Comments

@hannobraun
Copy link

When I updated to Rust master yesterday, some of my macro invocations broke in an interesting way. Here's a reduced example:

#![feature(macro_rules)]

macro_rules! my_macro(
    ($condition:expr $action:block) => ({})
)

fn main() {
    my_macro!(0 == y {
        y = 1;
    });
}
$ rustc main.rs
main.rs:10:5: 10:6 error: expected `:` but found `=`
main.rs:10      y = 1;
                  ^

With this workaround, it compiles without errors:

#![feature(macro_rules)]

macro_rules! my_macro(
    ($condition:expr $action:block) => ({})
)

fn main() {
    my_macro!(0 == y && true {
        y = 1;
    });
}

Looks to me like the parser sees "y { ..." and mistakes it for a struct initialization.

This problem occurs with commit 2f74325.
Before the upgrade, it worked fine with commit db29814.

hannobraun added a commit to hannobraun/vndf-2016 that referenced this issue Jun 26, 2014
This includes a few ugly workarounds for this bug:
rust-lang/rust#15198
@steveklabnik steveklabnik added the A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) label Jan 23, 2015
@kmcallister
Copy link
Contributor

This is an example of the problem that RFC 550 was meant to prevent, which indeed it does:

<anon>:2:6: 2:21 error: `$condition:expr` is followed by `$action:block`, which is not allowed for `expr` fragments
<anon>:2     ($condition:expr $action:block) => ({})
              ^~~~~~~~~~~~~~~

The ambiguity between struct initializers and blocks is a long-standing wart of the expression grammar. It's probably responsible for other bugs, but it should again not cause macro breakage like this, thanks to RFC 550.

matthiaskrgr pushed a commit to matthiaskrgr/rust that referenced this issue Mar 10, 2024
fix: keep attributes in assist 'generate_delegate_trait'

fix rust-lang#15198.

This PR address the issue that `impl` generated by `generate_delegate_trait` doesn't keep attributes.
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

No branches or pull requests

3 participants