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 #95159 having changed
the lifetimes.
The `Lrc` is only relevant within `transcribe()`. There, the `Lrc` is
helpful for the non-`NtTT` cases, because the entire nonterminal is
cloned. But for the `NtTT` cases the inner token tree is cloned (a full
clone) and so the `Lrc` is of no help.
This commit splits the `NtTT` and non-`NtTT` cases, avoiding the useless
`Lrc` in the former case, for the following effect on macro-heavy
crates.
- It reduces the total number of allocations a lot.
- It increases the size of some of the remaining allocations.
- It doesn't affect *peak* memory usage, because the larger allocations
are short-lived.
This overall gives a speed win.
Introduce `TtParser`
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`
As its name suggests, `TokenTreeOrTokenTreeSlice` is either a single
`TokenTree` or a slice of them. It has methods `len` and `get_tt` that
let it be treated much like an ordinary slice. The reason it isn't an
ordinary slice is that for `TokenTree::Delimited` the open and close
delimiters are represented implicitly, and when they are needed they are
constructed on the fly with `Delimited::{open,close}_tt`, rather than
being present in memory.
This commit changes `Delimited` so the open and close delimiters are
represented explicitly. As a result, `TokenTreeOrTokenTreeSlice` is no
longer needed and `MatcherPos` and `MatcherTtFrame` can just use an
ordinary slice. `TokenTree::{len,get_tt}` are also removed, because they
were only needed to support `TokenTreeOrTokenTreeSlice`.
The change makes the code shorter and a little bit faster on benchmarks
that use macro expansion heavily, partly because `MatcherPos` is a lot
smaller (less data to `memcpy`) and partly because ordinary slice
operations are faster than `TokenTreeOrTokenTreeSlice::{len,get_tt}`.
Suggest constraining param for unary ops when missing trait impl
This PR adds a suggestion of constraining param for unary ops `-` and `!` when the corresponding trait implementation
is missing.
Fixs #94543.
BTW, this is my first time to touch rustc, please correct me if I did anything wrong.
rename LocalState::Uninitialized to Unallocated
This is to avoid confusion with `Uninit` as in `ScalarMaybeUninit`, which is very different.
r? `@oli-obk`
Inline some parser functions
Some crates that do a lot of complex declarative macro expansion spend a lot of time parsing (and reparsing) tokens. These commits inline some functions for some minor speed wins.
r? `@ghost`
Disable almost certainly unsound early otherwise branch MIR opt
Originally thought this was just an MIR semantics issue, but it's not.
r? rust-lang/mir-opt
The call site within `Parser::bump` is hot.
Also add an inline annotation to `Parser::next_tok`. It was already
being inlined by the compiler; this just makes sure that continues.
Return err instead of ICE
Having `escaping_bound_vars` results in ICE when trying to create `ty::Binder::dummy`, to avoid it we return err like the line above. I think this requires a more sophisticated fix, I would love to investigate if mentorship is available 🤓Fixes#95023 and #85350
suggest removing type ascription in bad parsing position
Not sure how to test this with the non-nightly suggestion. Didn't add a new UI test because it already manifests in an existing UI test.
Fixes#95014
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.
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.
Give more details in `Display` for `hir::Target`
Made because I was making a code change and got a very confusing "should be applied to a method, not a method" error.
```
error[E0718]: `into_try_type` language item must be applied to a method
--> library\core\src\ops\try_trait.rs:352:32
|
352 | #[cfg_attr(not(bootstrap), lang = "into_try_type")]
| ^^^^^^^^^^^^^^^^^^^^^^ attribute should be applied to a method, not a method
```
With this change the error is more actionable
```
error[E0718]: `into_try_type` language item must be applied to a required trait method
--> library\core\src\ops\try_trait.rs:352:32
|
352 | #[cfg_attr(not(bootstrap), lang = "into_try_type")]
| ^^^^^^^^^^^^^^^^^^^^^^ attribute should be applied to a required trait method, not a provided trait method
```
Made because I was making a code change and got a very confusing "should be applied to a method, not a method" error.
```
error[E0718]: `into_try_type` language item must be applied to a method
--> library\core\src\ops\try_trait.rs:352:32
|
352 | #[cfg_attr(not(bootstrap), lang = "into_try_type")]
| ^^^^^^^^^^^^^^^^^^^^^^ attribute should be applied to a method, not a method
```
Always evaluate all cfg predicate in all() and any()
This pull-request adjust the handling of the `all()` and `any()` to always evaluate every cfg predicate because not doing so result in accepting incorrect `cfg`:
```rust
#[cfg(any(unix, foo::bar))] // Should error on foo::bar, but does not on unix platform (but does on non unix platform)
fn foo1() {}
#[cfg(all(foo, foo::bar))] // Should error on foo::bar, but does not
fn foo2() {}
#[cfg(all(foo::bar, foo))] // Correctly error on foo::bar
fn foo3() {}
#[cfg(any(foo::bar, foo))] // Correctly error on foo::bar
fn foo4() {}
```
This pull-request take the side to directly turn it into a hard error instead of having a future incompatibility lint because the combination to get this incorrect behavior is unusual and highly probable that some code have this without noticing.
A [search](https://cs.github.com/?scopeName=All+repos&scope=&q=lang%3Arust+%2Fany%5C%28%5Ba-zA-Z%5D%2C+%5Ba-zA-Z%5D%2B%3A%3A%5Ba-zA-Z%5D%2B%2F) on Github reveal no such instance nevertheless a Crater run should probably be done before merging this.
This was discover in https://github.com/rust-lang/rust/pull/94175 when trying to lint on the second predicate. Also note that this seems to have being introduce with Rust 1.27.0: https://rust.godbolt.org/z/KnfqKv15f.
r? `@petrochenkov`
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.
