Stop compilation early if macro expansion failed #144409

GuillaumeGomez · 2025-07-24T16:04:57Z

So there isn't really a type that is central for macro expansion and some errors are actually emitted (because the resolution happens after the expansion I suppose) after the expansion pass (like "not found macro"). Sometimes, errors are only emitted on the second "try" (to improve error output). So I couldn't reach a similar solution than what was done in #133937 and suggested by @estebank in #116180 (comment). But maybe I missed something?

So in the end, I realized that there is method called every time (except one, described below) a macro error is actually emitted: ExtCtxt::trace_macros_diag. Considering I updated what it did, I renamed it into macro_error_and_trace_macros_diag to better reflect it.

There is only one call of trace_macros_diag which isn't reporting an error but just used for macro_trace feature, so I kept it as is.

r? @oli-obk

tests/ui/editions/edition-keywords-2018-2015-2.rs

tests/ui/editions/edition-keywords-2018-2015-parsing.rs

GuillaumeGomez · 2025-07-24T17:00:50Z

Removed split ui tests to trigger old errors but in separate files.

tests/ui/const-generics/min_const_generics/macro-fail.rs

compiler/rustc_interface/src/passes.rs

oli-obk · 2025-07-25T10:01:11Z

r=me with nit (should allow reverting the changes to the timed closure)

GuillaumeGomez · 2025-07-25T12:29:58Z

@bors r=oli rollup

bors · 2025-07-25T12:30:01Z

📌 Commit faa28f9 has been approved by oli

It is now in the queue for this repository.

GuillaumeGomez · 2025-07-25T12:30:09Z

Got the handle wrong...

@bors r=oli-obk

bors · 2025-07-25T12:30:11Z

💡 This pull request was already approved, no need to approve it again.

There's another pull request that is currently being tested, blocking this pull request: Rollup of 12 pull requests #144440

bors · 2025-07-25T12:30:12Z

📌 Commit faa28f9 has been approved by oli-obk

It is now in the queue for this repository.

…ly-abort, r=oli-obk Stop compilation early if macro expansion failed Fixes rust-lang#116180. So there isn't really a type that is central for macro expansion and some errors are actually emitted (because the resolution happens after the expansion I suppose) after the expansion pass (like "not found macro"). Sometimes, errors are only emitted on the second "try" (to improve error output). So I couldn't reach a similar solution than what was done in rust-lang#133937 and suggested by `@estebank` in rust-lang#116180 (comment). But maybe I missed something? So in the end, I realized that there is method called every time (except one, described below) a macro error is actually emitted: `ExtCtxt::trace_macros_diag`. Considering I updated what it did, I renamed it into `macro_error_and_trace_macros_diag` to better reflect it. There is only one call of `trace_macros_diag` which isn't reporting an error but just used for `macro_trace` feature, so I kept it as is. r? `@oli-obk`

Rollup of 13 pull requests Successful merges: - #144356 (Add `ignore-backends` annotations in failing GCC backend ui tests) - #144359 (add codegen test for variadics) - #144376 (Suggest unwrapping when private method name is available in inner type) - #144379 (test using multiple c-variadic ABIs in the same program) - #144383 (disable cfg.has_reliable_f128 on amdgcn) - #144409 (Stop compilation early if macro expansion failed) - #144412 (Small cleanup: Use LocalKey<Cell> methods more) - #144421 (Call `is_parsed_attribute` rather than keeping track of a list of parsed attributes manually) - #144422 (library/windows_targets: Fix macro expansion error in 'link' macro) - #144424 (Allow setting `release-blog-post` label with rustbot) - #144430 (tests: aarch64-outline-atomics: Remove hardcoded target) - #144435 (rustc-dev-guide subtree update) - #144445 (Fix `./x check bootstrap` (again)) r? `@ghost` `@rustbot` modify labels: rollup

GuillaumeGomez · 2025-07-25T20:53:58Z

Failed in #144450.

GuillaumeGomez · 2025-07-25T20:54:03Z

@bors r-

…=<try> Stop compilation early if macro expansion failed

compiler/rustc_interface/src/passes.rs

rust-bors · 2025-07-25T23:31:06Z

☀️ Try build successful (CI)
Build commit: 443457b (443457b816e475c3fb59bab3aff59b7fa9d55f8c, parent: a955f1cd09a027363729ceed919952d09f76f28e)

GuillaumeGomez · 2025-07-26T09:33:01Z

@bors r=oli-obk

bors · 2025-07-26T09:33:04Z

📌 Commit 2725138 has been approved by oli-obk

It is now in the queue for this repository.

…ly-abort, r=oli-obk Stop compilation early if macro expansion failed Fixes rust-lang#116180. So there isn't really a type that is central for macro expansion and some errors are actually emitted (because the resolution happens after the expansion I suppose) after the expansion pass (like "not found macro"). Sometimes, errors are only emitted on the second "try" (to improve error output). So I couldn't reach a similar solution than what was done in rust-lang#133937 and suggested by `@estebank` in rust-lang#116180 (comment). But maybe I missed something? So in the end, I realized that there is method called every time (except one, described below) a macro error is actually emitted: `ExtCtxt::trace_macros_diag`. Considering I updated what it did, I renamed it into `macro_error_and_trace_macros_diag` to better reflect it. There is only one call of `trace_macros_diag` which isn't reporting an error but just used for `macro_trace` feature, so I kept it as is. r? `@oli-obk`

Rollup of 10 pull requests Successful merges: - #144359 (add codegen test for variadics) - #144409 (Stop compilation early if macro expansion failed) - #144422 (library/windows_targets: Fix macro expansion error in 'link' macro) - #144430 (tests: aarch64-outline-atomics: Remove hardcoded target) - #144445 (Fix `./x check bootstrap` (again)) - #144453 (canonicalize build root in `tests/run-make/linker-warning`) - #144454 (move uefi test to run-make) - #144464 (Only run bootstrap tests in `x test` on CI) - #144495 (bump cargo_metadata) - #144500 (thread name in stack overflow message) r? `@ghost` `@rustbot` modify labels: rollup

…ly-abort, r=oli-obk Stop compilation early if macro expansion failed Fixes rust-lang#116180. So there isn't really a type that is central for macro expansion and some errors are actually emitted (because the resolution happens after the expansion I suppose) after the expansion pass (like "not found macro"). Sometimes, errors are only emitted on the second "try" (to improve error output). So I couldn't reach a similar solution than what was done in rust-lang#133937 and suggested by ``@estebank`` in rust-lang#116180 (comment). But maybe I missed something? So in the end, I realized that there is method called every time (except one, described below) a macro error is actually emitted: `ExtCtxt::trace_macros_diag`. Considering I updated what it did, I renamed it into `macro_error_and_trace_macros_diag` to better reflect it. There is only one call of `trace_macros_diag` which isn't reporting an error but just used for `macro_trace` feature, so I kept it as is. r? ``@oli-obk``

Rollup of 9 pull requests Successful merges: - #144359 (add codegen test for variadics) - #144409 (Stop compilation early if macro expansion failed) - #144422 (library/windows_targets: Fix macro expansion error in 'link' macro) - #144430 (tests: aarch64-outline-atomics: Remove hardcoded target) - #144445 (Fix `./x check bootstrap` (again)) - #144453 (canonicalize build root in `tests/run-make/linker-warning`) - #144454 (move uefi test to run-make) - #144464 (Only run bootstrap tests in `x test` on CI) - #144495 (bump cargo_metadata) r? `@ghost` `@rustbot` modify labels: rollup

…ly-abort, r=oli-obk Stop compilation early if macro expansion failed Fixes rust-lang#116180. So there isn't really a type that is central for macro expansion and some errors are actually emitted (because the resolution happens after the expansion I suppose) after the expansion pass (like "not found macro"). Sometimes, errors are only emitted on the second "try" (to improve error output). So I couldn't reach a similar solution than what was done in rust-lang#133937 and suggested by ```@estebank``` in rust-lang#116180 (comment). But maybe I missed something? So in the end, I realized that there is method called every time (except one, described below) a macro error is actually emitted: `ExtCtxt::trace_macros_diag`. Considering I updated what it did, I renamed it into `macro_error_and_trace_macros_diag` to better reflect it. There is only one call of `trace_macros_diag` which isn't reporting an error but just used for `macro_trace` feature, so I kept it as is. r? ```@oli-obk```

Rollup of 13 pull requests Successful merges: - #144359 (add codegen test for variadics) - #144379 (test using multiple c-variadic ABIs in the same program) - #144383 (disable cfg.has_reliable_f128 on amdgcn) - #144409 (Stop compilation early if macro expansion failed) - #144422 (library/windows_targets: Fix macro expansion error in 'link' macro) - #144429 (Enable outline-atomics for aarch64-unknown-linux-musl) - #144430 (tests: aarch64-outline-atomics: Remove hardcoded target) - #144445 (Fix `./x check bootstrap` (again)) - #144453 (canonicalize build root in `tests/run-make/linker-warning`) - #144464 (Only run bootstrap tests in `x test` on CI) - #144470 (clif: Don't set the `compiler-builtins-no-f16-f128` feature) - #144480 (Revert "coverage: Enlarge empty spans during MIR instrumentation, not codegen") - #144495 (bump cargo_metadata) r? `@ghost` `@rustbot` modify labels: rollup

Rollup of 13 pull requests Successful merges: - #141840 (If `HOME` is empty, use the fallback instead) - #144359 (add codegen test for variadics) - #144379 (test using multiple c-variadic ABIs in the same program) - #144383 (disable cfg.has_reliable_f128 on amdgcn) - #144409 (Stop compilation early if macro expansion failed) - #144422 (library/windows_targets: Fix macro expansion error in 'link' macro) - #144429 (Enable outline-atomics for aarch64-unknown-linux-musl) - #144430 (tests: aarch64-outline-atomics: Remove hardcoded target) - #144445 (Fix `./x check bootstrap` (again)) - #144453 (canonicalize build root in `tests/run-make/linker-warning`) - #144464 (Only run bootstrap tests in `x test` on CI) - #144470 (clif: Don't set the `compiler-builtins-no-f16-f128` feature) - #144480 (Revert "coverage: Enlarge empty spans during MIR instrumentation, not codegen") r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #144409 - GuillaumeGomez:macro-expansion-early-abort, r=oli-obk Stop compilation early if macro expansion failed Fixes #116180. So there isn't really a type that is central for macro expansion and some errors are actually emitted (because the resolution happens after the expansion I suppose) after the expansion pass (like "not found macro"). Sometimes, errors are only emitted on the second "try" (to improve error output). So I couldn't reach a similar solution than what was done in #133937 and suggested by ````@estebank```` in #116180 (comment). But maybe I missed something? So in the end, I realized that there is method called every time (except one, described below) a macro error is actually emitted: `ExtCtxt::trace_macros_diag`. Considering I updated what it did, I renamed it into `macro_error_and_trace_macros_diag` to better reflect it. There is only one call of `trace_macros_diag` which isn't reporting an error but just used for `macro_trace` feature, so I kept it as is. r? ````@oli-obk````

fmease · 2025-09-10T18:31:44Z

tests/ui/traits/const-traits/macro-const-trait-bound-theoretical-regression.rs

+    (impl $c:ident Trait) => { impl $c Trait {} };
+    //~^ ERROR inherent
+    //~| WARN trait objects without an explicit `dyn` are deprecated
+    //~| WARN this is accepted in the current edition
+    (dyn $c:ident Trait) => { dyn $c Trait {} }; //~ ERROR macro expansion


Wait what?? Wait, why was this modification made? That doesn't make any sense. This destroyed the original test intention.

This is an extremely carefully crafted test case.

Same as previously: to keep an output as close as possible to the original because otherwise the new "early exit if the expansion macro failed" truncated the output.

I'm sorry but that's not how it should've been approached. These test cases are all about the macro matchers, it doesn't matter what the diagnostics look like, it's about MATCH vs. NO MATCH, so the ordering, amount of the matchers is extremely important. This changed the meaning of this test case.

For reference, tests like these were added (by me) to prevent (or demonstrate) regressions like the most recent #146417, so it's important keep the coverage 1:1.

I'll restore the test intention in a sec.

Yeah I completely missed the point, my bad. Is there a way to add constraints on a test to prevent this situation from happening again in the future? Like move it into another testsuite maybe?

fmease · 2025-09-10T18:31:59Z

tests/ui/traits/const-traits/macro-bare-trait-objects-const-trait-bounds.rs

    };
    (const $Trait:path) => {};
-    ([const] $Trait:path) => {};
+    ([const] $Trait:path) => { [const] Trait };


Wait what?? Wait, why was this modification made? That doesn't make any sense. This destroyed the original test intention.

To keep the same error output, otherwise it was truncated. Sorry if I understood wrongly what the test was checking...

…nds, r=estebank Less greedily parse `[const]` bounds > [!IMPORTANT] > If you're coming here from any beta backport nomination thread on Zulip, only the last commit is truly relevant (the first commit doesn't need to be backported, it only contains test modifications)! Don't consider `[` to start a bound, only consider `[const]` in its entirety to do so. This drastically reduces (but doesn't eliminate!) the chance of *real* breakages. Like `const`, `~const` and `async` before, `[const]` unavoidably brings along theoretical breakages, see preexisting tests: `macro-const-trait-bound-theoretical-regression.rs` and `macro-async-trait-bound-theoretical-regression.rs`. Side note: It's unfortunate that we have to do this but apart from the known fact that MBE hurts forward compatibility, the `[const]` syntax is simply a bit scuffed (also CC'ing rust-lang#146122, section (3)). Fixes [after beta backport] rust-lang#146417. * 1st commit: Restore the original test intentions of several preexisting related tests that were unfortunately lost over time * I've added a bunch of SCREAMING comments to make it less likely to be lost again * CC PR rust-lang#119099 which added most of these tests * CC [rust-lang#144409 (comment)](rust-lang#144409 (comment)) for further context (NB: It's not the only PR that negatively affected the test intention) * 2nd commit: Actually address the regression r? `@oli-obk` or anyone

Rollup merge of #146422 - fmease:less-greedy-maybe-const-bounds, r=estebank Less greedily parse `[const]` bounds > [!IMPORTANT] > If you're coming here from any beta backport nomination thread on Zulip, only the last commit is truly relevant (the first commit doesn't need to be backported, it only contains test modifications)! Don't consider `[` to start a bound, only consider `[const]` in its entirety to do so. This drastically reduces (but doesn't eliminate!) the chance of *real* breakages. Like `const`, `~const` and `async` before, `[const]` unavoidably brings along theoretical breakages, see preexisting tests: `macro-const-trait-bound-theoretical-regression.rs` and `macro-async-trait-bound-theoretical-regression.rs`. Side note: It's unfortunate that we have to do this but apart from the known fact that MBE hurts forward compatibility, the `[const]` syntax is simply a bit scuffed (also CC'ing #146122, section (3)). Fixes [after beta backport] #146417. * 1st commit: Restore the original test intentions of several preexisting related tests that were unfortunately lost over time * I've added a bunch of SCREAMING comments to make it less likely to be lost again * CC PR #119099 which added most of these tests * CC [#144409 (comment)](#144409 (comment)) for further context (NB: It's not the only PR that negatively affected the test intention) * 2nd commit: Actually address the regression r? `@oli-obk` or anyone

rustbot assigned oli-obk Jul 24, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 24, 2025

estebank reviewed Jul 24, 2025

View reviewed changes

tests/ui/editions/edition-keywords-2018-2015-2.rs Outdated Show resolved Hide resolved

tests/ui/editions/edition-keywords-2018-2015-parsing.rs Show resolved Hide resolved

GuillaumeGomez force-pushed the macro-expansion-early-abort branch from b6bd61c to 3ec0e1a Compare July 24, 2025 17:00

oli-obk reviewed Jul 25, 2025

View reviewed changes

tests/ui/const-generics/min_const_generics/macro-fail.rs Show resolved Hide resolved

GuillaumeGomez force-pushed the macro-expansion-early-abort branch from 3ec0e1a to faa28f9 Compare July 25, 2025 09:51

oli-obk approved these changes Jul 25, 2025

View reviewed changes

oli-obk reviewed Jul 25, 2025

View reviewed changes

compiler/rustc_interface/src/passes.rs Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

GuillaumeGomez force-pushed the macro-expansion-early-abort branch from faa28f9 to 72e4a6b Compare July 25, 2025 10:41

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 25, 2025

GuillaumeGomez mentioned this pull request Jul 25, 2025

Rollup of 13 pull requests #144450

Closed

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 25, 2025

GuillaumeGomez force-pushed the macro-expansion-early-abort branch from 72e4a6b to a0d6db3 Compare July 25, 2025 21:15

rust-bors bot added a commit that referenced this pull request Jul 25, 2025

Auto merge of #144409 - GuillaumeGomez:macro-expansion-early-abort, r…

443457b

…=<try> Stop compilation early if macro expansion failed

oli-obk reviewed Jul 25, 2025

View reviewed changes

compiler/rustc_interface/src/passes.rs Outdated Show resolved Hide resolved

GuillaumeGomez added 3 commits July 25, 2025 23:46

Stop compilation if macro expansion failed

96340f6

Add missing NOTE annotations in tests/ui/macros/trace-macro.rs

5dddba5

Update ui tests with new macro early erroring

2725138

GuillaumeGomez force-pushed the macro-expansion-early-abort branch from a0d6db3 to 2725138 Compare July 25, 2025 21:46

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 26, 2025

matthiaskrgr mentioned this pull request Jul 26, 2025

Rollup of 10 pull requests #144508

Closed

matthiaskrgr mentioned this pull request Jul 26, 2025

Rollup of 9 pull requests #144516

Closed

jhpratt mentioned this pull request Jul 26, 2025

Rollup of 13 pull requests #144520

Closed

jhpratt mentioned this pull request Jul 27, 2025

Rollup of 13 pull requests #144526

Merged

bors merged commit c92d61d into rust-lang:master Jul 27, 2025
10 checks passed

rustbot added this to the 1.90.0 milestone Jul 27, 2025

GuillaumeGomez deleted the macro-expansion-early-abort branch July 27, 2025 09:21

fmease reviewed Sep 10, 2025

View reviewed changes

fmease mentioned this pull request Sep 10, 2025

Less greedily parse [const] bounds #146422

Merged

Stop compilation early if macro expansion failed #144409

Stop compilation early if macro expansion failed #144409

Uh oh!

Conversation

GuillaumeGomez commented Jul 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

GuillaumeGomez commented Jul 24, 2025

Uh oh!

Uh oh!

Uh oh!

oli-obk commented Jul 25, 2025

Uh oh!

This comment has been minimized.

GuillaumeGomez commented Jul 25, 2025

Uh oh!

bors commented Jul 25, 2025

Uh oh!

GuillaumeGomez commented Jul 25, 2025

Uh oh!

bors commented Jul 25, 2025

Uh oh!

bors commented Jul 25, 2025

Uh oh!

GuillaumeGomez commented Jul 25, 2025

Uh oh!

GuillaumeGomez commented Jul 25, 2025

Uh oh!

Uh oh!

rust-bors bot commented Jul 25, 2025

Uh oh!

GuillaumeGomez commented Jul 26, 2025

Uh oh!

bors commented Jul 26, 2025

Uh oh!

Uh oh!

fmease Sep 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GuillaumeGomez Sep 10, 2025

Choose a reason for hiding this comment

Uh oh!

fmease Sep 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GuillaumeGomez Sep 10, 2025

Choose a reason for hiding this comment

Uh oh!

fmease Sep 10, 2025

Choose a reason for hiding this comment

Uh oh!

GuillaumeGomez Sep 10, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

GuillaumeGomez commented Jul 24, 2025 •

edited

Loading

fmease Sep 10, 2025 •

edited

Loading

fmease Sep 10, 2025 •

edited

Loading