Use an empty TokenCursorFrame stack when capturing tokens
#80830
Conversation
We will never need to pop past our starting frame during token capturing. Using an empty stack allows us to avoid pointless heap allocations/deallocations.
|
(rust-highfive has picked a reviewer for you, use r? to override) |
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. |
|
⌛ Trying commit 7b36408 with merge e63d87c7d985a3b28c39a68e1772b35a5cc24e72... |
|
☀️ Try build successful - checks-actions |
|
Queued e63d87c7d985a3b28c39a68e1772b35a5cc24e72 with parent 26438b4, future comparison URL. @rustbot label: +S-waiting-on-perf |
|
Finished benchmarking try commit (e63d87c7d985a3b28c39a68e1772b35a5cc24e72): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
|
@bors r+ |
|
📌 Commit 7b36408 has been approved by |
|
☀️ Test successful - checks-actions |
Reverts PR rust-lang#80830 Fixes taiki-e/pin-project#312 We can have an arbitrary number of `None`-delimited group frames pushed on the stack due to proc-macro invocations, which can legally be exited. Attempting to account for this would add a lot of complexity for a tiny performance gain, so let's just use the original strategy.
We will never need to pop past our starting frame during token
capturing. Using an empty stack allows us to avoid pointless heap
allocations/deallocations.