Tracking Issue for denying trailing semicolons in expression macro bodies

[Aaron1011]

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

• Implement the lint: Add SEMICOLON_IN_EXPRESSIONS_FROM_MACROS lint #79819
• Do a Crater run to determine the full extent of the impact ([EXPERIMENT] Error on trailing semicolons in macro expressions #81477)
• Fix lint_node_id so that we can apply #[allow] close to a macro call site (Compute a better lint_node_id during expansion #87146)
• When Don't insert semicolons inside of a macro_rules! arm body rustfmt#4507 makes it way into a stable release, make the lint warn-by-default
• Mark the lint for inclusion in the cargo future-incompat-report (see Tracking Issue for cargo report future-incompat #71249) (Add SEMICOLON_IN_EXPRESSIONS_FROM_MACROS to future-incompat report #103418)
• Switch the lint to deny-by-default
• Consider making the lint a hard error over an edition boundary

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

[nikomatsakis]

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]

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.

[nikomatsakis]

@Aaron1011 any updates for the planning meeting this month?

[Aaron1011]

@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]

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?

[John-Nagle]

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

[sffc]

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]

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!([
   |  _____________^