rustfmt subtree update#153145
Conversation
Avoid "width" since it can get confused with the width field.
URL is pronounced by spelling out each letter, therefore, it doesn't start with a vowel sound.
Replaces `char::is_numeric()` with `char::is_ascii_digit()` in `VersionChunkIter::parse_str_chunk()`. The text in the Style Guide explicitly mentions that a numeric chunk is a sequence of ASCII digits.
* Use RewriteResult in rewrite_reorderable_or_regroupable_items * Use RewriteResult in visit_item
I want to make it clearer that these tests are associated with the unstable `unsafe_fields` feature.
And pass this to the individual emitters when necessary.
…r=fee1-dead Parse guard patterns This implements the parsing of [RFC3637 Guard Patterns](https://rust-lang.github.io/rfcs/3637-guard-patterns.html) (see also [tracking issue](rust-lang#129967)). This PR is extracted from rust-lang#129996 with minor modifications. cc `@max-niederman`
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#133567 (A bunch of cleanups) - rust-lang#133789 (Add doc alias 'then_with' for `then` method on `bool`) - rust-lang#133880 (Expand home_dir docs) - rust-lang#134036 (crash tests: use individual mir opts instead of mir-opt-level where easily possible) - rust-lang#134045 (Fix some triagebot mentions paths) - rust-lang#134046 (Remove ignored tests for hangs w/ new solver) - rust-lang#134050 (Miri subtree update) r? `@ghost` `@rustbot` modify labels: rollup
…r paths involving them When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for. When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by `mod` expansion. Fix rust-lang#97734.
…24-12-02 subtree-push nightly-2024-12-02
…, r=oli-obk Add AST support for unsafe binders I'm splitting up rust-lang#130514 into pieces. It's impossible for me to keep up with a huge PR like that. I'll land type system support for this next, probably w/o MIR lowering, which will come later. r? `@oli-obk` cc `@BoxyUwU` and `@lcnr` who also may want to look at this, though this PR doesn't do too much yet
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.
`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.
…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```
The parser pushes a `TokenType` to `Parser::expected_token_types` on every call to the various `check`/`eat` methods, and clears it on every call to `bump`. Some of those `TokenType` values are full tokens that require cloning and dropping. This is a *lot* of work for something that is only used in error messages and it accounts for a significant fraction of parsing execution time. This commit overhauls `TokenType` so that `Parser::expected_token_types` can be implemented as a bitset. This requires changing `TokenType` to a C-style parameterless enum, and adding `TokenTypeSet` which uses a `u128` for the bits. (The new `TokenType` has 105 variants.) The new types `ExpTokenPair` and `ExpKeywordPair` are now arguments to the `check`/`eat` methods. This is for maximum speed. The elements in the pairs are always statically known; e.g. a `token::BinOp(token::Star)` is always paired with a `TokenType::Star`. So we now compute `TokenType`s in advance and pass them in to `check`/`eat` rather than the current approach of constructing them on insertion into `expected_token_types`. Values of these pair types can be produced by the new `exp!` macro, which is used at every `check`/`eat` call site. The macro is for convenience, allowing any pair to be generated from a single identifier. The ident/keyword filtering in `expected_one_of_not_found` is no longer necessary. It was there to account for some sloppiness in `TokenKind`/`TokenType` comparisons. The existing `TokenType` is moved to a new file `token_type.rs`, and all its new infrastructure is added to that file. There is more boilerplate code than I would like, but I can't see how to make it shorter.
|
Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt |
|
This comment has been minimized.
This comment has been minimized.
|
@bors r+ p=1 rollup=never |
This comment has been minimized.
This comment has been minimized.
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 6a979b3 (parent) -> 0ee5907 (this PR) Test differencesShow 57 test diffsStage 1
Additionally, 6 doctest diffs were found. These are ignored, as they are noisy. Job group index Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 0ee5907d597b02afadb5daa26a60fedb72f098d1 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (0ee5907): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (secondary -2.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.4%, secondary 3.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 484.473s -> 481.376s (-0.64%) |
|
CI time is |
…sions
Cloning the rust repo on case-insensitive filesystems (e.g. Windows,
macOS) produces warnings because the following paths collide:
src/tools/rustfmt/tests/{source,target}/reorder_modules/ABCD/mod.rs
src/tools/rustfmt/tests/{source,target}/reorder_modules/abcd/mod.rs
src/tools/rustfmt/tests/{source,target}/reorder_modules/ZYXW/mod.rs
src/tools/rustfmt/tests/{source,target}/reorder_modules/zyxw/mod.rs
These were introduced in the rustfmt subtree update (PR rust-lang#153145).
Rename the lowercase variants:
abcd -> abcde
zyxw -> zyxwv
This preserves the test intent (verifying case-sensitive module sorting)
while eliminating the case collision on case-insensitive filesystems.
Fixes #1
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
r? @ghost