Skip to content

Conversation

GuillaumeGomez
Copy link
Member

@GuillaumeGomez GuillaumeGomez commented Jul 24, 2025

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

@rustbot 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
@GuillaumeGomez GuillaumeGomez force-pushed the macro-expansion-early-abort branch from b6bd61c to 3ec0e1a Compare July 24, 2025 17:00
@GuillaumeGomez
Copy link
Member Author

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

@GuillaumeGomez GuillaumeGomez force-pushed the macro-expansion-early-abort branch from 3ec0e1a to faa28f9 Compare July 25, 2025 09:51
@oli-obk
Copy link
Contributor

oli-obk commented Jul 25, 2025

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

@rust-log-analyzer

This comment has been minimized.

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

@bors r=oli rollup

@bors
Copy link
Collaborator

bors commented Jul 25, 2025

📌 Commit faa28f9 has been approved by oli

It is now in the queue for this repository.

@bors 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
Copy link
Member Author

Got the handle wrong...

@bors r=oli-obk

@bors
Copy link
Collaborator

bors commented Jul 25, 2025

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

@bors
Copy link
Collaborator

bors commented Jul 25, 2025

📌 Commit faa28f9 has been approved by oli-obk

It is now in the queue for this repository.

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Jul 25, 2025
…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`
bors added a commit that referenced this pull request Jul 25, 2025
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
bors added a commit that referenced this pull request Jul 25, 2025
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
bors added a commit that referenced this pull request Jul 25, 2025
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
Copy link
Member Author

Failed in #144450.

@GuillaumeGomez
Copy link
Member Author

@bors r-

@bors 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 GuillaumeGomez force-pushed the macro-expansion-early-abort branch from 72e4a6b to a0d6db3 Compare July 25, 2025 21:15
@GuillaumeGomez
Copy link
Member Author

Just in case.

@bors try

@rust-bors
Copy link

rust-bors bot commented Jul 25, 2025

⌛ Trying commit a0d6db3 with merge 443457b

To cancel the try build, run the command @bors try cancel.

rust-bors bot added a commit that referenced this pull request Jul 25, 2025
…=<try>

Stop compilation early if macro expansion failed
@GuillaumeGomez GuillaumeGomez force-pushed the macro-expansion-early-abort branch from a0d6db3 to 2725138 Compare July 25, 2025 21:46
@rust-bors
Copy link

rust-bors bot commented Jul 25, 2025

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

@GuillaumeGomez
Copy link
Member Author

@bors r=oli-obk

@bors
Copy link
Collaborator

bors commented Jul 26, 2025

📌 Commit 2725138 has been approved by oli-obk

It is now in the queue for this repository.

@bors 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 added a commit to matthiaskrgr/rust that referenced this pull request Jul 26, 2025
…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`
bors added a commit that referenced this pull request Jul 26, 2025
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
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 26, 2025
…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``
bors added a commit that referenced this pull request Jul 26, 2025
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
jhpratt added a commit to jhpratt/rust that referenced this pull request Jul 26, 2025
…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```
bors added a commit that referenced this pull request Jul 27, 2025
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
bors added a commit that referenced this pull request Jul 27, 2025
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
@bors bors merged commit c92d61d into rust-lang:master Jul 27, 2025
10 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jul 27, 2025
rust-timer added a commit that referenced this pull request Jul 27, 2025
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````
@GuillaumeGomez GuillaumeGomez deleted the macro-expansion-early-abort branch July 27, 2025 09:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Error recovery after errors during macro expansion is usually futile
6 participants