Skip to content
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

Never regard macro rules with compile_error! invocations as unused #97903

Merged
merged 3 commits into from
Jun 11, 2022

Conversation

est31
Copy link
Member

@est31 est31 commented Jun 9, 2022

The very point of compile_error! is to never be reached, and one of
the use cases of the macro, currently also listed as examples in the
documentation of compile_error, is to create nicer errors for wrong
macro invocations. Thus, we should never warn about unused macro arms
that contain invocations of compile_error.

See also #96150 (comment) and the discussion after that.

Furthermore, the PR also contains two commits to silence unused_macro_rules when a macro has an invalid rule, and to add a test that unused_macros does not behave badly in the same situation.

r? @petrochenkov as I've talked to them about this

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 9, 2022
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 9, 2022
@petrochenkov petrochenkov 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-review Status: Awaiting review from the assignee but also interested parties. labels Jun 9, 2022
est31 added 3 commits June 9, 2022 23:21
The very point of compile_error! is to never be reached, and one of
the use cases of the macro, currently also listed as examples in the
documentation of compile_error, is to create nicer errors for wrong
macro invocations. Thus, we shuuld never warn about unused macro arms
that contain invocations of compile_error.
Prior to this commit, if a macro had any malformed rules, all rules would
be reported as unused, regardless of whether they were used or not.
So we just turn off unused rule checking completely for macros with
malformed rules.
The unused_macro_rules lint had a bug where it would regard all rules of
a macro as unused if one rule were malformed. This bug doesn't exist
with the unused_macros lint. To ensure it doesn't appear in the future,
we add a test for it.
@est31 est31 force-pushed the unused_macro_rules_compile_error branch from dd95fe3 to 787e24c Compare June 9, 2022 21:49
@est31
Copy link
Member Author

est31 commented Jun 9, 2022

As requested, I've removed the glob import. I've also added two commits. The first added commit silences unused_macro_rules when a macro has a malformed rule. The second added commit ensures that the unused_macros lint works correctly when a macro has a malformed rule. I don't think it needs to be turned off as well, but feel free to disagree.

r? @petrochenkov

@petrochenkov petrochenkov added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 10, 2022
@petrochenkov
Copy link
Contributor

Thanks!
@bors r+

@bors
Copy link
Contributor

bors commented Jun 10, 2022

📌 Commit 787e24c has been approved by petrochenkov

@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 Jun 10, 2022
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Jun 10, 2022
…ror, r=petrochenkov

Never regard macro rules with compile_error! invocations as unused

The very point of compile_error! is to never be reached, and one of
the use cases of the macro, currently also listed as examples in the
documentation of compile_error, is to create nicer errors for wrong
macro invocations. Thus, we should never warn about unused macro arms
that contain invocations of compile_error.

See also rust-lang#96150 (comment) and the discussion after that.

Furthermore, the PR also contains two commits to silence `unused_macro_rules` when a macro has an invalid rule, and to add a test that `unused_macros` does not behave badly in the same situation.

r? `@petrochenkov` as I've talked to them about this
@bors
Copy link
Contributor

bors commented Jun 11, 2022

⌛ Testing commit 787e24c with merge fa68e73...

@bors
Copy link
Contributor

bors commented Jun 11, 2022

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing fa68e73 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 11, 2022
@bors bors merged commit fa68e73 into rust-lang:master Jun 11, 2022
@rustbot rustbot added this to the 1.63.0 milestone Jun 11, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (fa68e73): comparison url.

Instruction count

  • Primary benchmarks: no relevant changes found
  • Secondary benchmarks: 😿 relevant regression found
mean1 max count2
Regressions 😿
(primary)
N/A N/A 0
Regressions 😿
(secondary)
0.3% 0.3% 1
Improvements 🎉
(primary)
N/A N/A 0
Improvements 🎉
(secondary)
N/A N/A 0
All 😿🎉 (primary) N/A N/A 0

Max RSS (memory usage)

Results
  • Primary benchmarks: 😿 relevant regression found
  • Secondary benchmarks: mixed results
mean1 max count2
Regressions 😿
(primary)
3.2% 3.2% 1
Regressions 😿
(secondary)
2.4% 2.6% 4
Improvements 🎉
(primary)
N/A N/A 0
Improvements 🎉
(secondary)
-3.3% -3.3% 1
All 😿🎉 (primary) 3.2% 3.2% 1

Cycles

Results
  • Primary benchmarks: no relevant changes found
  • Secondary benchmarks: 🎉 relevant improvement found
mean1 max count2
Regressions 😿
(primary)
N/A N/A 0
Regressions 😿
(secondary)
N/A N/A 0
Improvements 🎉
(primary)
N/A N/A 0
Improvements 🎉
(secondary)
-2.9% -2.9% 1
All 😿🎉 (primary) N/A N/A 0

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

  1. the arithmetic mean of the percent change 2 3

  2. number of relevant changes 2 3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.

7 participants