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

Tracking Issue for denying trailing semicolons in expression macro bodies #79813

Open
5 of 7 tasks
Aaron1011 opened this issue Dec 7, 2020 · 13 comments
Open
5 of 7 tasks
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. S-tracking-needs-to-bake Status: The implementation is "complete" but it needs time to bake. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@Aaron1011
Copy link
Member

Aaron1011 commented Dec 7, 2020

This is a tracking issue for MCP rust-lang/lang-team#70

What is this issue?

If you're a crate author who's been linked here, this issue tracks emitting a hard error when a trailing semicolon occurs in a macro used in expression position. See rust-lang/lang-team#70 for some background about the issue.

In the future, code like this may stop compiling:

macro_rules! foo {
    () => {
        true;
    }
}

fn main() {
    let val = match true {
        true => false,
        _ => foo!()
    };
}

In the above code snippet, foo!() is invoked in expression position (in this case, a macro arm). However, foo!() expands to the token stream true;, which is not a valid expression due to the presence of a trailing semicolon.

To make the behavior of macro expansion more consistent, we plan to turn this into a hard error at some point in the future.

Fixing issues in your crate is usually as simple as removing the trailing semicolon from the macro definition.

Currently, the associated lint (semicolon_in_expressions_from_macros) is set to allow-by-default. As time goes on, we may increase this to warn-by-default.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Unresolved Questions

Implementation history

  1. Lint implemented in Add SEMICOLON_IN_EXPRESSIONS_FROM_MACROS lint #79819
  2. Made warn-by-default in Make SEMICOLON_IN_EXPRESSIONS_FROM_MACROS warn by default #87385
  3. Added to future-incompat report in Add SEMICOLON_IN_EXPRESSIONS_FROM_MACROS to future-incompat report #103418
@Aaron1011 Aaron1011 added T-lang Relevant to the language team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Dec 7, 2020
@camelid camelid added the A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) label Dec 10, 2020
Aaron1011 added a commit to Aaron1011/rust that referenced this issue Jan 27, 2021
cc rust-lang#79813

This PR adds an allow-by-default future-compatibility lint
`MACRO_TRAILING_SEMICOLON`. It fires when a trailing semicolon in a
macro body is ignored due to the macro being used in expression
position:

```rust
macro_rules! foo {
    () => {
        true; // WARN
    }
}

fn main() {
    let val = match true {
        true => false,
        _ => foo!()
    };
}
```

The lint takes its level from the macro call site, and
can be allowed for a particular macro by adding
`#[allow(macro_trailing_semicolon)]`.

The lint is set to warn for all internal rustc crates (when being built
by a stage1 compiler). After the next beta bump, we can enable
the lint for the bootstrap compiler as well.
Aaron1011 added a commit to Aaron1011/rust that referenced this issue Jan 28, 2021
cc rust-lang#79813

This PR adds an allow-by-default future-compatibility lint
`SEMICOLON_IN_EXPRESSIONS_FROM_MACROS`. It fires when a trailing semicolon in a
macro body is ignored due to the macro being used in expression
position:

```rust
macro_rules! foo {
    () => {
        true; // WARN
    }
}

fn main() {
    let val = match true {
        true => false,
        _ => foo!()
    };
}
```

The lint takes its level from the macro call site, and
can be allowed for a particular macro by adding
`#[allow(semicolon_in_expressions_from_macros)]`.

The lint is set to warn for all internal rustc crates (when being built
by a stage1 compiler). After the next beta bump, we can enable
the lint for the bootstrap compiler as well.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jan 28, 2021
…micolon, r=petrochenkov

Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint

cc rust-lang#79813

This PR adds an allow-by-default future-compatibility lint
`SEMICOLON_IN_EXPRESSIONS_FROM_MACROS`. It fires when a trailing semicolon in a
macro body is ignored due to the macro being used in expression
position:

```rust
macro_rules! foo {
    () => {
        true; // WARN
    }
}

fn main() {
    let val = match true {
        true => false,
        _ => foo!()
    };
}
```

The lint takes its level from the macro call site, and
can be allowed for a particular macro by adding
`#[allow(macro_trailing_semicolon)]`.

The lint is set to warn for all internal rustc crates (when being built
by a stage1 compiler). After the next beta bump, we can enable
the lint for the bootstrap compiler as well.
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jan 29, 2021
…micolon, r=petrochenkov

Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint

cc rust-lang#79813

This PR adds an allow-by-default future-compatibility lint
`SEMICOLON_IN_EXPRESSIONS_FROM_MACROS`. It fires when a trailing semicolon in a
macro body is ignored due to the macro being used in expression
position:

```rust
macro_rules! foo {
    () => {
        true; // WARN
    }
}

fn main() {
    let val = match true {
        true => false,
        _ => foo!()
    };
}
```

The lint takes its level from the macro call site, and
can be allowed for a particular macro by adding
`#[allow(macro_trailing_semicolon)]`.

The lint is set to warn for all internal rustc crates (when being built
by a stage1 compiler). After the next beta bump, we can enable
the lint for the bootstrap compiler as well.
Aaron1011 added a commit to Aaron1011/fs_extra that referenced this issue Feb 7, 2021
If the `semicolon_in_expressions_from_macros` lint is ever turned into a
hard error, your crate will stop compiling. This commit ensures that
your crate will compile on both current and future versions of Rust.

See rust-lang/rust#79813 for more details
Aaron1011 added a commit to Aaron1011/rust-snappy that referenced this issue Feb 9, 2021
If the semicolon_in_expressions_from_macros lint is ever turned into a
hard error, your crate will stop compiling. This commit ensures that
your crate will compile on both current and future versions of Rust.

See rust-lang/rust#79813 for more details
BurntSushi added a commit to BurntSushi/rust-snappy that referenced this issue Feb 9, 2021
If the semicolon_in_expressions_from_macros lint is ever turned into a
hard error, your crate will stop compiling. This commit ensures that
your crate will compile on both current and future versions of Rust.

See rust-lang/rust#79813 for more details

PR #39
@nikomatsakis
Copy link
Contributor

Hey @Aaron1011! Sorry for the late notice, but any chance you can post an update as a comment on this issue sometime before the lang-team planning meeting tomorrow? Here are some prompts and questions.

@Aaron1011
Copy link
Member Author

Sure!

This is currently blocked on bumping the stdarch submodule to include rust-lang/stdarch#1080. Once that's done, I'll do a Crater run to determine how many crates need to be updated.

Before we make this warn-by-default, we'll probably want to fix lint_node_id to allow placing semicolon_in_expressions_from_macros closer to the offending macro call - currently, it can only be placed on the enclosing item definition (e.g. a function).

Design-wise, I don't think there's anything that needs to be done - this lint is about removing a special check for the macro parsing code.

jyn514 added a commit to jyn514/rust that referenced this issue May 5, 2021
This avoids the following warning:

```
warning: trailing semicolon in macro used in expression position
   --> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/log-0.4.11/src/macros.rs:152:45
    |
147 | / macro_rules! debug {
148 | |     (target: $target:expr, $($arg:tt)+) => (
149 | |         log!(target: $target, $crate::Level::Debug, $($arg)+);
150 | |     );
151 | |     ($($arg:tt)+) => (
152 | |         log!($crate::Level::Debug, $($arg)+);
    | |                                             ^
153 | |     )
154 | | }
    | |_- in this expansion of `debug!`
    |
   ::: src/tools/rustfmt/src/modules/visitor.rs:36:23
    |
36  |               Err(e) => debug!("{}", e),
    |                         --------------- in this macro invocation
    |
    = note: requested on the command line with `-W semicolon-in-expressions-from-macros`
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue rust-lang#79813 <rust-lang#79813>
```
@nikomatsakis
Copy link
Contributor

@Aaron1011 any updates for the planning meeting this month?

@Aaron1011
Copy link
Member Author

@nikomatsakis: #83089 was recently merged, so we're now denying the lint within the compiler and standard library. The next step is to do a Crater run, which I'll kick off.

@vitalytarasov
Copy link

vitalytarasov commented Jul 30, 2023

i was a little perplexed landing on this page from rustc warning for a macro defined as following:

macro_rules! debug {
    ($fmt:expr) => {
        debug!("{}", &format!($fmt))
    };
    ($fmt:expr, $($arg:tt)+) => {
        crate::logger::log(crate::logger::Level::Debug, &format!($fmt, $($arg)+))
    }
}

how does this result in a trailing semicolon?

Xanewok added a commit to Xanewok/miri that referenced this issue Dec 5, 2023
This warns-by-default since 2 years and already has been added to the future-incompat group since Rust 1.68.

See rust-lang/rust#79813 for the tracking issue.
Xanewok added a commit to Xanewok/rust that referenced this issue Dec 5, 2023
…pressions_from_macros`

This already wasn't passed in bootstrap.py and the lint itself already warns-by-default for 2 years now and has already been added to the future-incompat group in Rust 1.68.

See rust-lang#79813 for the tracking issue.
bors added a commit to rust-lang/rust-analyzer that referenced this issue Dec 5, 2023
… r=lnicola

internal: Don't explicitly warn against `semicolon_in_expressions_from_macros`

This has been warn-by-default for two years now and has already been added to the future-incompat lints in 1.68.

See rust-lang/rust#79813 for the tracking issue.
bors added a commit to rust-lang/miri that referenced this issue Dec 5, 2023
Don't explicitly warn against `semicolon_in_expressions_from_macros`

This warns-by-default since 2 years and already has been added to the future-incompat group since Rust 1.68.

See rust-lang/rust#79813 for the tracking issue.

Just something I noticed when trying to wrap my head around lints warned against in the rust-lang/rust and noticed it's not warned against anymore; let me know if the change makes sense 🙏
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Dec 5, 2023
bootstrap(builder.rs): Don't explicitly warn against `semicolon_in_expressions_from_macros`

This already wasn't passed in bootstrap.py and the lint itself already warns-by-default for 2 years now and has already been added to the future-incompat group in Rust 1.68.

See rust-lang#79813 for the tracking issue.
compiler-errors added a commit to compiler-errors/rust that referenced this issue Dec 5, 2023
bootstrap(builder.rs): Don't explicitly warn against `semicolon_in_expressions_from_macros`

This already wasn't passed in bootstrap.py and the lint itself already warns-by-default for 2 years now and has already been added to the future-incompat group in Rust 1.68.

See rust-lang#79813 for the tracking issue.
compiler-errors added a commit to compiler-errors/rust that referenced this issue Dec 5, 2023
bootstrap(builder.rs): Don't explicitly warn against `semicolon_in_expressions_from_macros`

This already wasn't passed in bootstrap.py and the lint itself already warns-by-default for 2 years now and has already been added to the future-incompat group in Rust 1.68.

See rust-lang#79813 for the tracking issue.
compiler-errors added a commit to compiler-errors/rust that referenced this issue Dec 5, 2023
bootstrap(builder.rs): Don't explicitly warn against `semicolon_in_expressions_from_macros`

This already wasn't passed in bootstrap.py and the lint itself already warns-by-default for 2 years now and has already been added to the future-incompat group in Rust 1.68.

See rust-lang#79813 for the tracking issue.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Dec 6, 2023
Rollup merge of rust-lang#118642 - Xanewok:patch-1, r=clubby789

bootstrap(builder.rs): Don't explicitly warn against `semicolon_in_expressions_from_macros`

This already wasn't passed in bootstrap.py and the lint itself already warns-by-default for 2 years now and has already been added to the future-incompat group in Rust 1.68.

See rust-lang#79813 for the tracking issue.
RalfJung pushed a commit to RalfJung/rust that referenced this issue Dec 17, 2023
This warns-by-default since 2 years and already has been added to the future-incompat group since Rust 1.68.

See rust-lang#79813 for the tracking issue.
RalfJung pushed a commit to RalfJung/rust that referenced this issue Dec 17, 2023
Don't explicitly warn against `semicolon_in_expressions_from_macros`

This warns-by-default since 2 years and already has been added to the future-incompat group since Rust 1.68.

See rust-lang#79813 for the tracking issue.

Just something I noticed when trying to wrap my head around lints warned against in the rust-lang/rust and noticed it's not warned against anymore; let me know if the change makes sense 🙏
johngavingraham added a commit to johngavingraham/wrapped-vec that referenced this issue Dec 19, 2023
@John-Nagle
Copy link

Breaks some older versions of "nom", which breaks an old version of "iso8601" (date parsing), which breaks "quick-xml", which breaks "simple-xmlrpc". Seems to be fixed in Github but new version of "simple-xmlrpc" has not been pushed to "crates.io". Probably because it was complete, stable, had no issues, and had not needed maintenance in four years, so no one is maintaining it.

Ref: https://github.com/belak/serde-xmlrpc/issues

lnicola pushed a commit to lnicola/rust-analyzer that referenced this issue Apr 7, 2024
bootstrap(builder.rs): Don't explicitly warn against `semicolon_in_expressions_from_macros`

This already wasn't passed in bootstrap.py and the lint itself already warns-by-default for 2 years now and has already been added to the future-incompat group in Rust 1.68.

See rust-lang/rust#79813 for the tracking issue.
RalfJung pushed a commit to RalfJung/rust-analyzer that referenced this issue Apr 27, 2024
bootstrap(builder.rs): Don't explicitly warn against `semicolon_in_expressions_from_macros`

This already wasn't passed in bootstrap.py and the lint itself already warns-by-default for 2 years now and has already been added to the future-incompat group in Rust 1.68.

See rust-lang/rust#79813 for the tracking issue.
@sffc
Copy link

sffc commented May 16, 2024

I have code where it's not evident to me how to write it in a way that avoids this warning. It is a macro that takes another macro as a callback and conditionally generates either expressions or items.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=75617c4dc910f1e7a1f044dbee8e6c9c

If I remove the semicolon, I can't generate items. If I add the semicolon, it works but I get this warning.

See unicode-org/icu4x#4910

@dtolnay
Copy link
Member

dtolnay commented May 16, 2024

Macros that expand to expressions sometimes and items sometimes need to use brace syntax and no semicolon. cb! {…}

The error message already suggests this as a solution too.

error: macros that expand to items must be delimited with braces or followed by a semicolon
  --> src/main.rs:9:13
   |
9  |           $cb!([
   |  _____________^

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, ..) C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. S-tracking-needs-to-bake Status: The implementation is "complete" but it needs time to bake. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

9 participants