-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Sync from rustfmt #130593
Sync from rustfmt #130593
Conversation
This paves the way for tracking more state (e.g. error tainting) in the diagnostic context handle
Merge `PatParam`/`PatWithOr`, and `Expr`/`Expr2021`, for a few reasons. - It's conceptually nice, because the two pattern kinds and the two expression kinds are very similar. - With expressions in particular, there are several places where both expression kinds get the same treatment. - It removes one unreachable match arm. - Most importantly, for rust-lang#124141 I will need to introduce a new type `MetaVarKind` that is very similar to `NonterminalKind`, but records a couple of extra fields for expression metavars. It's nicer to have a single `MetaVarKind::Expr` expression variant to hold those extra fields instead of duplicating them across two variants `MetaVarKind::{Expr,Expr2021}`. And then it makes sense for patterns to be treated the same way, and for `NonterminalKind` to also be treated the same way. I also clarified the comments, because I have long found them a little hard to understand.
…r=compiler-errors Rework pattern and expression nonterminal kinds. Some tweaks to `NonterminalKind` that will assist with rust-lang#124141. Details in the individual commits. r? compiler-errors cc ```@eholk```
…ebcartwright Implement `use<>` formatting in rustfmt This PR implements formatting for precise-capturing `use<>` syntax as proposed in rust-lang#126753. The syntax is implemented as-if the `use<>` bound were a trait bound but with the `use` keyword as its path segment identifier. I opted to develop this in the rust-lang/rust tree since I'm not certain when the next rustfmt subtree sync is going to be, and I'd rather not block landing nightly support for `use<>` on something I have no control over. If ``@rust-lang/rustfmt`` would rather I move this PR over to that repository, then I would at least like to know when the next rustfmt->rust subtree sync is going to be, since stabilizing `precise_capturing` without formatting will be disruptive. This implementation is otherwise rather straightforward. Tracking: - rust-lang#123432
…g, r=dtolnay Remove stray println from rustfmt's `rewrite_static` r? `@calebcartwright` `@ytmimi` -- though anyone should probably r+ this so it gets into nightly sooner than later, since it's obviously wrong. This can just be fixed in-tree, since I don't think we want to wait until the next sync to fix this. Fix rust-lang/rustfmt#6210 Fix rust-lang#126887
…-2024-06-24 subtree-push 2024-06-24
impl rewrite_result for ast::Local, ast::FieldDef, ast::Param, ast::FnRetTy
…-lang#6232) This adds a test case to validate behavior when using `format_code_in_doc_comments=true`
Makes internal changes to define each configuration in terms of the `StyleEditionDefault` trait, and hard codes `StyleEdition::Edition2015` anywhere the new `style_edition` is needed. **Note** users are still unable to configure `style edition`.
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt |
There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged. You can start a rebase with the following commands:
The following commits are merge commits: |
@bors delegate+ |
✌️ @ytmimi, you can now approve this pull request! If @compiler-errors told you to " |
@bors r+ p=1 rollup=never |
☀️ Test successful - checks-actions |
Finished benchmarking commit (2e45ec3): 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)This benchmark run did not return any relevant results for this metric. CyclesResults (secondary -4.4%)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 sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 768.735s -> 768.024s (-0.09%) |
Changes required due to: - rust-lang/rust#130593 Sync from rustfmt With the exception of changes to `rust-toolchain.toml` and `rustfmt.toml` all changes were automatically created by running `scripts/kani-fmt.sh`.
Changes required due to: - rust-lang/rust#130593 Sync from rustfmt - rust-lang/rust#124895 Disallow hidden references to mutable static With the exception of changes to `rust-toolchain.toml`, `rustfmt.toml`, and `library/kani/src/futures.rs` all changes were automatically created by running `scripts/kani-fmt.sh`. By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.
r? @ghost