Skip to content

mbe: Defer checks for compile_error! until reporting an unused macro rule #143416

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jul 6, 2025

Conversation

joshtriplett
Copy link
Member

@joshtriplett joshtriplett commented Jul 4, 2025

The current MBE parser checks rules at initial parse time to see if their RHS has compile_error! in it, and returns a list of rule indexes and LHS spans that don't map to compile_error!, for use in unused macro rule checking.

Instead, have the unused macro rule reporting ask the macro for the rule to report, and let the macro check at that time. That avoids checking rules unless they're unused.

In the process, refactor the data structure used to store macro rules, to group the LHS and RHS (and LHS span) of each rule together, and refactor the unused rule tracking to only track rule indexes.

This builds atop a couple of minor MBE refactors. I would suggest reviewing commit-by-commit.

The overall result is a further simplification of the macro code.

@joshtriplett joshtriplett added the A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) label Jul 4, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jul 4, 2025

r? @compiler-errors

rustbot has assigned @compiler-errors.
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

@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 4, 2025
@joshtriplett
Copy link
Member Author

As a potential added improvement, it might make sense to change unused_macro_rules to use DenseBitSet in place of UnordSet. That'd be a slightly larger change, and I didn't want to mix it into this PR, but it seems worth trying. I'd like to get the perf numbers with and without that, though.

@joshtriplett

This comment was marked as outdated.

@rust-timer

This comment was marked as outdated.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 4, 2025
bors added a commit that referenced this pull request Jul 4, 2025
mbe: Defer checks for `compile_error!` until reporting an unused macro rule

The current MBE parser checks rules at initial parse time to see if their RHS has `compile_error!` in it, and returns a list of rule indexes and LHS spans that don't map to `compile_error!`, for use in unused macro rule checking.

Instead, have the unused macro rule reporting ask the macro for the rule to report, and let the macro check at that time. That avoids checking rules unless they're unused.

In the process, refactor the data structure used to store macro rules, to group the LHS and RHS (and LHS span) of each rule together, and refactor the unused rule tracking to only track rule indexes.

This builds atop a couple of minor MBE refactors. I would suggest reviewing commit-by-commit.

This PR builds atop the fix for #143408 to avoid conflicts.
@bors

This comment was marked as outdated.

@rust-log-analyzer

This comment was marked as outdated.

@joshtriplett joshtriplett force-pushed the mbe-simplifications branch from 9c9bed5 to d6422f8 Compare July 4, 2025 08:58
@joshtriplett
Copy link
Member Author

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

bors added a commit that referenced this pull request Jul 4, 2025
mbe: Defer checks for `compile_error!` until reporting an unused macro rule

The current MBE parser checks rules at initial parse time to see if their RHS has `compile_error!` in it, and returns a list of rule indexes and LHS spans that don't map to `compile_error!`, for use in unused macro rule checking.

Instead, have the unused macro rule reporting ask the macro for the rule to report, and let the macro check at that time. That avoids checking rules unless they're unused.

In the process, refactor the data structure used to store macro rules, to group the LHS and RHS (and LHS span) of each rule together, and refactor the unused rule tracking to only track rule indexes.

This builds atop a couple of minor MBE refactors. I would suggest reviewing commit-by-commit.

This PR builds atop the fix for #143408 to avoid conflicts.
@bors
Copy link
Collaborator

bors commented Jul 4, 2025

⌛ Trying commit d6422f8 with merge 0d199d4...

@bors
Copy link
Collaborator

bors commented Jul 4, 2025

☀️ Try build successful - checks-actions
Build commit: 0d199d4 (0d199d444a215e6b14a6d0142770f95a1f5067eb)

@rust-timer

This comment has been minimized.

@petrochenkov petrochenkov self-assigned this Jul 4, 2025
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (0d199d4): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.3% [-0.3%, -0.3%] 1
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (secondary -6.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-6.0% [-6.0%, -6.0%] 1
All ❌✅ (primary) - - 0

Cycles

Results (secondary -4.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
1.7% [0.6%, 2.4%] 3
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-9.0% [-12.0%, -2.2%] 4
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 461.827s -> 462.538s (0.15%)
Artifact size: 372.20 MiB -> 372.20 MiB (-0.00%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 4, 2025
@compiler-errors compiler-errors removed their assignment Jul 4, 2025
@joshtriplett
Copy link
Member Author

@bors rollup

bors added a commit that referenced this pull request Jul 4, 2025
mbe: Change `unused_macro_rules` to a `DenseBitSet`

Now that it only contains indexes, and no other information, a bitset provides a more compact and simpler representation.

This builds on <#143416>. Only the last commit is new.
Rather than a `bool` that's `true` for the LHS and `false` for the RHS,
use a self-documenting enum.
@joshtriplett joshtriplett force-pushed the mbe-simplifications branch from d6422f8 to 3c1559c Compare July 5, 2025 10:07
The parser repeatedly invokes the `parse` function, constructing a
one-entry vector, and assuming that the return value will be a one-entry
vector. Add a helper for that case. This will simplify adding additional
callers, and put all the logic in one place to allow potential future
simplification of the one-TT case.
…o rule

The MBE parser checks rules at initial parse time to see if their RHS
has `compile_error!` in it, and returns a list of rule indexes and LHS
spans that don't map to `compile_error!`, for use in unused macro rule
checking.

Instead, have the unused macro rule reporting ask the macro for the rule
to report, and let the macro check at that time. That avoids checking
rules unless they're unused.

In the process, refactor the data structure used to store macro rules,
to group the LHS and RHS (and LHS span) of each rule together, and
refactor the unused rule tracking to only track rule indexes.

This ends up being a net simplification, and reduction in code size.
@joshtriplett joshtriplett force-pushed the mbe-simplifications branch from 3c1559c to 63cfb3a Compare July 5, 2025 23:23
@nnethercote
Copy link
Contributor

@bors r+

@bors
Copy link
Collaborator

bors commented Jul 6, 2025

📌 Commit 63cfb3a has been approved by nnethercote

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 6, 2025
bors added a commit that referenced this pull request Jul 6, 2025
Rollup of 6 pull requests

Successful merges:

 - #143416 (mbe: Defer checks for `compile_error!` until reporting an unused macro rule)
 - #143470 (std: sys: net: uefi: tcp4: Implement read)
 - #143477 (use `is_multiple_of` and `div_ceil`)
 - #143484 (distinguish the duplicate item of rpitit)
 - #143493 (tidy: use --bless for tidy spellcheck instead of spellcheck:fix)
 - #143504 (compiletest: print slightly more information on fs::write failure)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 71b73e5 into rust-lang:master Jul 6, 2025
11 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jul 6, 2025
rust-timer added a commit that referenced this pull request Jul 6, 2025
Rollup merge of #143416 - joshtriplett:mbe-simplifications, r=nnethercote

mbe: Defer checks for `compile_error!` until reporting an unused macro rule

The current MBE parser checks rules at initial parse time to see if their RHS has `compile_error!` in it, and returns a list of rule indexes and LHS spans that don't map to `compile_error!`, for use in unused macro rule checking.

Instead, have the unused macro rule reporting ask the macro for the rule to report, and let the macro check at that time. That avoids checking rules unless they're unused.

In the process, refactor the data structure used to store macro rules, to group the LHS and RHS (and LHS span) of each rule together, and refactor the unused rule tracking to only track rule indexes.

This builds atop a couple of minor MBE refactors. I would suggest reviewing commit-by-commit.

The overall result is a further simplification of the macro code.
@joshtriplett joshtriplett deleted the mbe-simplifications branch July 6, 2025 18:55
jhpratt added a commit to jhpratt/rust that referenced this pull request Jul 7, 2025
…et, r=lqd

mbe: Change `unused_macro_rules` to a `DenseBitSet`

Now that it only contains indexes, and no other information, a bitset provides a more compact and simpler representation.

This builds on <rust-lang#143416>. Only the last commit is new.
rust-timer added a commit that referenced this pull request Jul 7, 2025
Rollup merge of #143456 - joshtriplett:mbe-unused-rules-bitset, r=lqd

mbe: Change `unused_macro_rules` to a `DenseBitSet`

Now that it only contains indexes, and no other information, a bitset provides a more compact and simpler representation.

This builds on <#143416>. Only the last commit is new.
@@ -348,6 +348,10 @@ pub trait TTMacroExpander {
span: Span,
input: TokenStream,
) -> MacroExpanderResult<'cx>;

fn get_unused_rule(&self, _rule_i: usize) -> Option<(&Ident, Span)> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This trait isn't supposed to know anything about rules or other ways to implement a macro, only about the macro's expander function.

It would probably be better to downcast from dyn TTMacroExpander (+ Any) to MacroRulesMacroExpander in check_unused_macros and extract the necessary data directly if the downcast succeeds.

Or just revert the change, it doesn't actually bring perf benefits, but complicates the logic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) 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.

8 participants