[tehforsch]

Closes #164087

[rustbot]

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 77 candidates
• Random selection from 20 candidates

[tehforsch]

The trailing a!() is sort of unnecessary but my first fix didn't handle this case properly, so I added it to the same test. I can remove this or move it to a separate test if necessary

View changes since the review

[xizheyin]

rust/compiler/rustc_expand/src/expand.rs

Lines 2149 to 2153 in d1a0517

	expansion_data: ExpansionData {
	id: expn_id,
	depth: self.cx.current_expansion.depth + 1,
	..self.cx.current_expansion.clone()
	},

if there is nest macro, the trailing_mac may be wrong. for example, inner will inherit the outer's is_trailing_mac(true), and make it add ;, it may be a regression. We should make is_trailing_mac correct for nested macro when constructing expansion data.🤔

macro_rules! inner {
    () => {;};
}

macro_rules! outer {
    () => {{ let _ = inner!(); }};
}

fn main() {
    outer!()
}

View changes since the review

[tehforsch]

Right, this also fails for the other diagnostic that is_trailing_mac is responsible for, like in

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

macro_rules! outer {
    () => {{ let _ = inner!(); }};
}

fn main() {
    outer!()
}

which will result in the wrong note

note: macro invocations at the end of a block are treated as expressions
note: to ignore the value produced by the macro, add a semicolon after the invocation of `inner`

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[tehforsch]

I don't know if this is the right way to fix this. The reason we can't just set is_trailing_mac to false is that in some cases, we have to inherit the is_trailing_mac from the parent so that a directly nested macro like

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

macro_rules! outer {
    () => { inner!() };
}

fn foo() -> bool {
    outer!()
}

is still treated as a trailing macro.
(I added a test for this, although its results are the same on main and on this branch, see tests/ui/lint/semicolon-in-expressions-from-macros/semicolon-in-expression-from-macros-nested-2.rs)

However, in the current logic, is_trailing_mac was basically always true for nested macros where the outer one is trailing, so that wasn't right either.

This fix is sort of the dumbest logic that solves the problem ...

View changes since the review

[tehforsch]

r? @xizheyin
@rustbot ready

[xizheyin]

I dont have the right to review. r? compiler

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[tehforsch]

I dont have the right to review. r? compiler

Oh sorry, didn't realize. I rebased this after the changes in #161035