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