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

librustc: Always parse macro!()/macro![] as expressions if not followed by a semicolon. #18958

Closed
wants to merge 1 commit into from

Conversation

pcwalton
Copy link
Contributor

This allows code like vec![1i, 2, 3].len(); to work.

This breaks code that uses macros as statements without putting
semicolons after them, such as:

fn main() {
    ...
    assert!(a == b)
    assert!(c == d)
    println(...);
}

It also breaks code that uses macros as items without semicolons:

fn main() {
    local_data_key!(foo)

    println("hello world")
}

Add semicolons to fix this code. Those two examples can be fixed as
follows:

fn main() {
    ...
    assert!(a == b);
    assert!(c == d);
    println(...);
}

fn main() {
    local_data_key!(foo);

    println("hello world")
}

RFC #378.

Closes #18635.

[breaking-change]

r? @alexcrichton

@pcwalton pcwalton changed the title librustc: Always parse macro!()/macro![] as expressions if not librustc: Always parse macro!()/macro![] as expressions if not followed by a semicolon. Nov 14, 2014
@alexcrichton
Copy link
Member

Really liking this cleanup, thanks @pcwalton!

Could you add some tests for ensuring that macro!() macro!() is an error, as well as tests like macro!().len(); macro![].len(); parsing?

Other than that, r=me

@ftxqxd
Copy link
Contributor

ftxqxd commented Nov 14, 2014

To quote from the RFC:

Require all item-position macro invocations to be either invoked with curly braces, {}, or be followed by a semicolon (for consistency).

Does this pull request handle that? That is, this should require that all macros invoked at the top level (not inside a function or block, which I can see is handled) also must be followed by a semicolon, unless they are invoked with {}.

@pcwalton pcwalton force-pushed the macro-expressions branch 2 times, most recently from 67c1b03 to b38bbae Compare November 19, 2014 05:15
@pcwalton
Copy link
Contributor Author

Now implements the rules @P1start suggested. This broke a lot of code.

re-r? @alexcrichton

@alexcrichton
Copy link
Member

Parentheses for you, and you, and you!

Another heroic effort by @pcwalton!

followed by a semicolon.

This allows code like `vec![1i, 2, 3].len();` to work.

This breaks code that uses macros as statements without putting
semicolons after them, such as:

    fn main() {
        ...
        assert!(a == b)
        assert!(c == d)
        println(...);
    }

It also breaks code that uses macros as items without semicolons:

    local_data_key!(foo)

    fn main() {
        println("hello world")
    }

Add semicolons to fix this code. Those two examples can be fixed as
follows:

    fn main() {
        ...
        assert!(a == b);
        assert!(c == d);
        println(...);
    }

    local_data_key!(foo);

    fn main() {
        println("hello world")
    }

RFC rust-lang#378.

Closes rust-lang#18635.

[breaking-change]
@steveklabnik
Copy link
Member

This needs rebased by now 😦

bors added a commit that referenced this pull request Dec 18, 2014
followed by a semicolon.

This allows code like `vec![1i, 2, 3].len();` to work.

This breaks code that uses macros as statements without putting
semicolons after them, such as:

    fn main() {
        ...
        assert!(a == b)
        assert!(c == d)
        println(...);
    }

It also breaks code that uses macros as items without semicolons:

    local_data_key!(foo)

    fn main() {
        println("hello world")
    }

Add semicolons to fix this code. Those two examples can be fixed as
follows:

    fn main() {
        ...
        assert!(a == b);
        assert!(c == d);
        println(...);
    }

    local_data_key!(foo);

    fn main() {
        println("hello world")
    }

RFC #378.

Closes #18635.

[breaking-change]

---

Rebased version of #18958
r? @alexcrichton 
cc @pcwalton
@alexcrichton
Copy link
Member

Closing in favor of #19984

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement parse macro!() / macro![] as expr (RFC 378)
4 participants