Trailing semicolon silently ignored in expr macro #33953

mahkoh · 2016-05-29T23:36:10Z

fn main() {
    macro_rules! a {
        ($e:expr) => { $e; }
    }
    a!(true)
}

Error: Expected (), found bool

But:

fn main() {
    macro_rules! a {
        ($e:expr) => { $e; }
    }
    a!(true);  // <-- semicolon
}

does not warn that the ; is ignored.

So either

there should be a warning that the ; has no effect in the macro, or
the ; inside the macro should turn the expression into ().

The text was updated successfully, but these errors were encountered:

rozbb · 2016-05-30T05:35:30Z

I'm not sure there should be a warning for use of a semicolon in an expression expansion. The problem is fixed when you write ($e: expr) => {{ $e; }} which indicates a block expansion.

So the semicolon is silently ignored, but putting something after it throws a helpful error: ($e:expr) => { $e; blahblah } gives the error "macro expansion ignores token blahblah and any following".

The x86 code contains several macros that following this pattern: ```rust macro_rules! expr { () => { true; } } fn bar(_val: bool) {} fn main() { bar(expr!()); } ``` Here, we have a macro `expr!` that expands to tokens sequence with a trailing semicolon. Currently, the trailing semicolon is ignored when the macro is invoked in expression position, due to rust-lang/rust#33953 If this behavior is changed, then a large number of macro invocations in `stdarch` will stop compiling. Regardless of whether nor not this change is made, removing the semicolon more clearly expresses the intent of the code - these macros are designed to expand to the result of a function call, not ignore its results (as the `;` would suggest).

We no longer flatten a block that looks like this: ```rust match val { pat => { macro_call!() } } ``` Currently, rust ignores trailing semicolons in macro expansion in expression position (see rust-lang/rust#33953) If this is changed, flattening a block with a macro call may break the user's code - the trailing semicolon will no longer parse if the macro call occurs immediately on the right-hand side of the match arm (e.g. `pat => macro_call!()`)

Currently, rustfmt inserts semicolons for certain trailing expressions (`return`, `continue`, and `break`). However, this should not be done in the body of a `macro_rules!` arm, since the macro might be used in expression position (where a trailing semicolon will be invalid). Currently, this rewriting has no effect due to rust-lang/rust#33953 If this issue is fixed, then this rewriting will prevent some macros from being used in expression position. This commit prevents rustfmt from inserting semicolons for trailing expressions in `macro_rules!` arms. The user is free to either include or omit the semicolon - rustfmt will not modify either case.

The x86 code contains several macros that following this pattern: ```rust macro_rules! expr { () => { true; } } fn bar(_val: bool) {} fn main() { bar(expr!()); } ``` Here, we have a macro `expr!` that expands to tokens sequence with a trailing semicolon. Currently, the trailing semicolon is ignored when the macro is invoked in expression position, due to rust-lang/rust#33953 If this behavior is changed, then a large number of macro invocations in `stdarch` will stop compiling. Regardless of whether nor not this change is made, removing the semicolon more clearly expresses the intent of the code - these macros are designed to expand to the result of a function call, not ignore its results (as the `;` would suggest).

Currently, rustfmt inserts semicolons for certain trailing expressions (`return`, `continue`, and `break`). However, this should not be done in the body of a `macro_rules!` arm, since the macro might be used in expression position (where a trailing semicolon will be invalid). Currently, this rewriting has no effect due to rust-lang/rust#33953 If this issue is fixed, then this rewriting will prevent some macros from being used in expression position. This commit prevents rustfmt from inserting semicolons for trailing expressions in `macro_rules!` arms. The user is free to either include or omit the semicolon - rustfmt will not modify either case.

This will allow `bail!` to continue to be used in expression position if rust-lang/rust#33953 is fixed

This will keep `crates-io` compiling if rust-lang/rust#33953 is fixed. See dtolnay/anyhow#120

Bump `anyhow` dependency to `1.0.34` in `crates-io` crate This will keep `crates-io` compiling if rust-lang/rust#33953 is fixed. See dtolnay/anyhow#120

This will allow this crate to continue to compile if rust-lang/rust#33953 is fixed

We no longer flatten a block that looks like this: ```rust match val { pat => { macro_call!() } } ``` Currently, rust ignores trailing semicolons in macro expansion in expression position (see rust-lang/rust#33953) If this is changed, flattening a block with a macro call may break the user's code - the trailing semicolon will no longer parse if the macro call occurs immediately on the right-hand side of the match arm (e.g. `pat => macro_call!()`)

Currently, rustfmt inserts semicolons for certain trailing expressions (`return`, `continue`, and `break`). However, this should not be done in the body of a `macro_rules!` arm, since the macro might be used in expression position (where a trailing semicolon will be invalid). Currently, this rewriting has no effect due to rust-lang/rust#33953 If this issue is fixed, then this rewriting will prevent some macros from being used in expression position. This commit prevents rustfmt from inserting semicolons for trailing expressions in `macro_rules!` arms. The user is free to either include or omit the semicolon - rustfmt will not modify either case.

We no longer flatten a block that looks like this: ```rust match val { pat => { macro_call!() } } ``` Currently, rust ignores trailing semicolons in macro expansion in expression position (see rust-lang/rust#33953) If this is changed, flattening a block with a macro call may break the user's code - the trailing semicolon will no longer parse if the macro call occurs immediately on the right-hand side of the match arm (e.g. `pat => macro_call!()`)

Currently, rustfmt inserts semicolons for certain trailing expressions (`return`, `continue`, and `break`). However, this should not be done in the body of a `macro_rules!` arm, since the macro might be used in expression position (where a trailing semicolon will be invalid). Currently, this rewriting has no effect due to rust-lang/rust#33953 If this issue is fixed, then this rewriting will prevent some macros from being used in expression position. This commit prevents rustfmt from inserting semicolons for trailing expressions in `macro_rules!` arms. The user is free to either include or omit the semicolon - rustfmt will not modify either case.

This will allow these macros to continue to be used in expression position if rust-lang/rust#33953 is fixed.

cc rust-lang#33953 Currently, the following code produces an error ```rust fn main() { macro_rules! a { ($e:expr) => { $e; } } a!(true) } ```

cc rust-lang#33953 Currently, the following code produces an error ```rust fn main() { macro_rules! a { ($e:expr) => { $e; } } a!(true) } ``` With this change, it now compiles, since we parse `a!(true)` as a statement.

This macro is used in expression position (a match arm), and only compiles because of rust-lang#33953 Regardless of what happens with that issue, this makes the usage of the macro less confusing at the call site.

Remove semicolon from internal `err` macro This macro is used in expression position (a match arm), and only compiles because of rust-lang#33953 Regardless of what happens with that issue, this makes the usage of the macro less confusing at the call site.

Aaron1011 · 2020-12-08T02:06:28Z

Progress towards fixing this issue is tracked in #79813

Aatch added the A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) label May 30, 2016

This comment has been minimized.

Sign in to view

Mark-Simulacrum mentioned this issue May 6, 2017

macros: Expression macro expansions can have a trailing semicolon #34706

Closed

Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 25, 2017

estebank mentioned this issue Oct 23, 2018

macro expanding to nothing in match arm causes uninformative parse error #30128

Closed

petrochenkov mentioned this issue Jun 11, 2019

What is a trailing expression in a block exactly? #61733

Open

Aaron1011 mentioned this issue Oct 27, 2020

Remove trailing semicolons from several macro definitions rust-lang/stdarch#938

Merged

Aaron1011 mentioned this issue Oct 27, 2020

Remove semicolon from internal err macro #78449

Merged

This was referenced Oct 27, 2020

Don't flatten a block containing a single macro call rust-lang/rustfmt#4496

Merged

clarify match block requirement for single mac call rust-lang/style-team#159

Merged

Aaron1011 mentioned this issue Nov 1, 2020

Don't insert semicolons inside of a macro_rules! arm body rust-lang/rustfmt#4507

Merged

Aaron1011 added a commit to Aaron1011/anyhow that referenced this issue Nov 2, 2020

Don't emit trailing semicolon from bail!

3002c06

This will allow `bail!` to continue to be used in expression position if rust-lang/rust#33953 is fixed

Aaron1011 mentioned this issue Nov 2, 2020

Don't emit trailing semicolon from bail! dtolnay/anyhow#120

Merged

Aaron1011 added a commit to Aaron1011/cargo that referenced this issue Nov 2, 2020

Bump anyhow dependency to 1.0.34 in crates-io crate

939b5ff

This will keep `crates-io` compiling if rust-lang/rust#33953 is fixed. See dtolnay/anyhow#120

Aaron1011 mentioned this issue Nov 2, 2020

Bump anyhow dependency to 1.0.34 in crates-io crate rust-lang/cargo#8826

Merged

Aaron1011 added a commit to Aaron1011/git2-rs that referenced this issue Nov 3, 2020

Remove trailing semicolon from internal err! macro

7d261e8

This will allow this crate to continue to compile if rust-lang/rust#33953 is fixed

Aaron1011 mentioned this issue Nov 3, 2020

Remove trailing semicolon from internal err! macro rust-lang/git2-rs#631

Merged

Aaron1011 added a commit to Aaron1011/log that referenced this issue Nov 9, 2020

Remove some trailing semicolons from macro definitions

ed7a622

This will allow these macros to continue to be used in expression position if rust-lang/rust#33953 is fixed.

Aaron1011 mentioned this issue Nov 9, 2020

Remove some trailing semicolons from macro definitions rust-lang/log#422

Merged

Aaron1011 mentioned this issue Nov 12, 2020

Parse bang macro as a statement when used in trailing expr position #78991

Closed

Aaron1011 mentioned this issue Nov 19, 2020

Stop ignoring trailing semicolons in a macro body when a macro is invoked in expression position rust-lang/lang-team#70

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Trailing semicolon silently ignored in expr macro #33953

Trailing semicolon silently ignored in expr macro #33953

mahkoh commented May 29, 2016 •

edited

Loading

rozbb commented May 30, 2016

This comment has been minimized.

Aaron1011 commented Dec 8, 2020

Trailing semicolon silently ignored in expr macro #33953

Trailing semicolon silently ignored in expr macro #33953

Comments

mahkoh commented May 29, 2016 • edited Loading

rozbb commented May 30, 2016

This comment has been minimized.

Aaron1011 commented Dec 8, 2020

mahkoh commented May 29, 2016 •

edited

Loading