-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Introduce TtParser
#95159
Introduce TtParser
#95159
Conversation
It currently has no state, just the three methods `parse_tt`, `parse_tt_inner`, and `bb_items_ambiguity_error`. This commit is large but trivial, and mostly consists of changes to the indentation of those methods. Subsequent commits will do more.
Because it involves `next_items` as well as `bb_items`.
Instead of passing it into `parse_tt`.
Doc comments cannot appear in a matcher.
This type was a small performance win for `html5ever`, which uses a macro with hundreds of very simple rules that don't contain any metavariables. But this type is complicated (extra lifetimes) and perf-neutral for macros that do have metavariables. This commit removes `MatcherPosHandle`, simplifying things a lot. This increases the allocation rate for `html5ever` and similar cases a bit, but makes things easier for follow-up changes that will improve performance more than what we lost here.
By putting them in `TtParser`, we can reuse them for every rule in a macro. With that done, they can be `SmallVec` instead of `Vec`, and this is a performance win because these vectors are hot and `SmallVec` operations are a bit slower due to always needing an "inline or heap?" check.
Here are some instruction count results for the
|
Thank you for the fast review. I have added a commit that addresses your comments. |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 84960a1d972494a28fd3af4c57612afd1548eb42 with merge ca34b004599cc8dd6871c7ba9bb1d3ddaa73ed2f... |
☀️ Try build successful - checks-actions |
Queued ca34b004599cc8dd6871c7ba9bb1d3ddaa73ed2f with parent 3c17c84, future comparison URL. |
Finished benchmarking commit (ca34b004599cc8dd6871c7ba9bb1d3ddaa73ed2f): comparison url. Summary: This benchmark run shows 25 relevant improvements 🎉 but 7 relevant regressions 😿 to instruction counts.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never |
Some nice performance wins here, and a handful of tiny regressions that are probably just noise. @rustbot label: +perf-regression-triaged |
r=me after squashing the review commit into the previous relevant commits (or at least into the "Eliminate |
☀️ Test successful - checks-actions |
Finished benchmarking commit (a4a5e79): comparison url. Summary: This benchmark run shows 24 relevant improvements 🎉 to instruction counts.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Currently it copies a `KleeneOp` and a `Token` out of a `SequenceRepetition`. It's better to store a reference to the `SequenceRepetition`, which is now possible due to rust-lang#95159 having changed the lifetimes.
I think this caused the unexpected side effect seen in #95267, apparently this used to compile: macro_rules! f {
(
/// ab
) => {};
}
fn main() {
f!();
} |
Fixes rust-lang#95267. Reverts to the old behaviour before rust-lang#95159 introduced a regression.
…acros, r=petrochenkov Ignore doc comments in a declarative macro matcher. Fixes rust-lang#95267. Reverts to the old behaviour before rust-lang#95159 introduced a regression. r? `@petrochenkov`
They were introduced by the final commit in rust-lang#95159 and gave a performance win. But since the introduction of `MatcherLoc` they are no longer needed. This commit reverts that change, making the code a bit simpler.
…=petrochenkov Remove explicit delimiter token trees from `Delimited`. They were introduced by the final commit in rust-lang#95159 and gave a performance win. But since the introduction of `MatcherLoc` they are no longer needed. This commit reverts that change, making the code a bit simpler. r? `@petrochenkov`
PR rust-lang#95159 unintentionally changed the behaviour of declarative macro matching for `NoDelim` delimited sequences. - Before rust-lang#95159, delimiters were implicit in `mbe::Delimited`. When doing macro matching, normal delimiters were generated out of thin air as necessary, but `NoDelim` delimiters were not. This was done within `TokenTree::{get_tt,len}`. - After rust-lang#95159, the delimiters were explicit. There was an unintentional change whereby `NoDelim` delimiters were represented explicitly just like normal delimeters. - rust-lang#95555 introduced a new matcher representation (`MatcherLoc`) and the `NoDelim` delimiters were made explicit within it, just like `mbe::Delimited`. - rust-lang#95797 then changed `mbe::Delimited` back to having implicit delimiters, but because matching is now being done on `MatcherLoc`, the behavioural change persisted. The fix is simple: remove the explicit `NoDelim` delimiters in the `MatcherLoc` representation. This gives back the original behaviour. As for why this took so long to be found: it seems that `NoDelim` sequences are unusual. It took a macro that generates another macro (from the `yarte_lexer` crate, found via a crater run) to uncover this. Fixes rust-lang#96305.
Remove box syntax from rustc_mir_dataflow and rustc_mir_transform Continuation of rust-lang#87781, inspired by rust-lang#97239. The usages that this PR removes have not appeared from nothing, instead the usage in `rustc_mir_dataflow` and `rustc_mir_transform` was from rust-lang#80522 which split up `rustc_mir`, and which was filed before I filed rust-lang#87781, so it was using the state from before my PR. But it was merged after my PR was merged, so the `box_syntax` uses were able to survive here. Outside of this introduction due to the code being outside of the master branch at the point of merging of my PR, there was only one other introduction of box syntax, in rust-lang#95159. That box syntax was removed again though in rust-lang#95555. Outside of that, `box_syntax` has not made its reoccurrance in compiler crates.
These commits make a number of changes to declarative macro expansion, resulting in code that is shorter, simpler, and faster.
Best reviewed one commit at a time.
r? @petrochenkov