Merged
Conversation
…s by using minicore
As it happens, lookahead values of 0, 1, and 2 all work fine here, due to the structure of the code. (Values or 3 or greater cause test failures.) This commit changes the lookahead to zero because that will facilitate cleanups in subsequent commits.
It's only ever used with a lookahead of 0, so this commit removes the lookahead and renames it `peek`.
Because `TokenStreamIter` is a much better name for a `TokenStream` iterator. Also rename the `TokenStream::trees` method as `TokenStream::iter`, and some local variables.
Currently there are two ways to peek at a `TokenStreamIter`. - Wrap it in a `Peekable` and use that traits `peek` method. - Use `TokenStreamIter`'s inherent `peek` method. Some code uses one, some use the other. This commit converts all places to the inherent method. This eliminates mixing of `TokenStreamIter` and `Peekable<TokenStreamIter>` and some use of `impl Iterator` and `dyn Iterator`.
…ckend Before, cg_cranelift would ICE when trying to lower f16 and f128. The library/ crates had all the infrastructure to omit using them, it just wasn't hooked up to bootstrap.
- Move it to `rustc_parse`, which is the only crate that uses it. This lets us remove all the `pub` markers from it. - Change `next_ref` and `look_ahead` to `get` and `bump`, which work better for the `rustc_parse` uses. - This requires adding a `TokenStream::get` method, which is simple. - In `TokenCursor`, we currently duplicate the `DelimSpan`/`DelimSpacing`/`Delimiter` from the surrounding `TokenTree::Delimited` in the stack. This isn't necessary so long as we don't prematurely move past the `Delimited`, and is a small perf win on a very hot code path. - In `parse_token_tree`, we clone the relevant `TokenTree::Delimited` instead of constructing an identical one from pieces.
- `LazyCell::get`: said it was returning a **mutable** reference. - `LazyCell::get_mut`: said it was returning a reference (the mutable was missing).
It's a verbose reinvention of a range type, and can be cut down a lot.
`rustc_symbol` is the source of truth for keywords. rustdoc has its own implicit definition of keywords, via the `is_doc_keyword`. It (presumably) intends to include all keywords, but it omits `yeet`. rustfmt has its own explicit list of Rust keywords. It also (presumably) intends to include all keywords, but it omits `await`, `builtin`, `gen`, `macro_rules`, `raw`, `reuse`, `safe`, and `yeet`. Also, it does linear searches through this list, which is inefficient. This commit fixes all of the above problems by introducing a new predicate `is_any_keyword` in rustc and using it in rustdoc and rustfmt. It documents that it's not the right predicate in most cases.
`gen` is an edition-specific keyword used in unstable Rust, and so belongs with `try` (as `is_unused_keyword_conditional` indicates). Also, the cases in `is_unused_keyword_conditional` should be in alphabetical order, to match the keyword list. These changes don't affect the behaviour of any of the `Symbol::is_*` functions.
In particular, clarify which predicates apply to which keywords.
…ch_scalar, r=cjgillot" This reverts commit 16a0266.
…nup, r=oli-obk mir-opt: a sub-BB of a cleanup BB must also be a cleanup BB in `EarlyOtherwiseBranch` Fixes rust-lang#130769. r? `@cjgillot` or mir-opt
…r=lcnr Fix const conditions for RPITITs Fixes rust-lang#133918 r? lcnr
…, r=spastorino Overhaul token cursors Some nice cleanups here. r? `````@davidtwco`````
…etrochenkov Overhaul keyword handling The compiler's list of keywords has some problems. - It contains several items that aren't keywords. - The order isn't quite right in a couple of places. - Some of the names of predicates relating to keywords are confusing. - rustdoc and rustfmt have their own (incorrect) versions of the keyword list. - `AllKeywords` is unnecessarily complex. r? ```@jieyouxu```
Fix `x build --stage 1 std` when using cg_cranelift as the default backend Before, cg_cranelift would ICE when trying to lower f16 and f128. The library/ crates had all the infrastructure to omit using them, it just wasn't hooked up to bootstrap. r? `````@bjorn3`````
…=tgross35 fix(LazyCell): documentation of get[_mut] was wrong - `LazyCell::get`: said it was returning a **mutable** reference. - `LazyCell::get_mut`: said it was returning a reference (the mutable was missing). Related to rust-lang#129333 (`lazy_get`). `LazyLock`'s documentation was correct.
Merge some patterns together just something I noticed while browsing code. No change in functionality, deduplicates the 100% equal match arms by creating one big or pattern
rustbot
added
A-compiletest
Member
Author
|
@bors r+ rollup=never p=5 |
Collaborator
bors
added
S-waiting-on-bors
Collaborator
Collaborator
|
☀️ Test successful - checks-actions |
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: 057bdb37ec In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Dec 18, 2024
Collaborator
|
Finished benchmarking commit (a52085d): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -0.1%, secondary 1.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary 1.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResults (secondary 0.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 769.67s -> 769.824s (0.02%) |
Member
|
Regressions seem to be balanced with improvements. @rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
15 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
EarlyOtherwiseBranch#130786 ( mir-opt: a sub-BB of a cleanup BB must also be a cleanup BB inEarlyOtherwiseBranch)x build --stage 1 stdwhen using cg_cranelift as the default backend #134444 (Fixx build --stage 1 stdwhen using cg_cranelift as the default backend)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup