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`.
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 https://github.com/rust-lang/rustfmt/issues/6210
Fix https://github.com/rust-lang/rust/issues/126887
Implement `use<>` formatting in rustfmt
This PR implements formatting for precise-capturing `use<>` syntax as proposed in https://github.com/rust-lang/rust/pull/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:
- https://github.com/rust-lang/rust/issues/123432
Rework pattern and expression nonterminal kinds.
Some tweaks to `NonterminalKind` that will assist with #124141. Details in the individual commits.
r? compiler-errors
cc ```@eholk```
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 #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.
This includes both `ast::StaticItem` and `ast::StaticForeignItem`.
`safety` was added to both `ast::StaticItem` and `ast::SaticForeignItem`
in https://github.com/rust-lang/rust/pull/124482.
Our diff-check job was failing in part due to removing `unsafe` from any
`#[unsafe(attributes)]`. To prevent that I added a quick implementation
for this.