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.
Can't run `cargo test --all` for `error-chain` anymore. The tests don't
compile because of `#[deny(invalid_doc_attributes)]`. Here's the error
message:
```
error: this attribute can only be applied at the crate level
--> tests/tests.rs:508:7
|
508 | #[doc(test)]
| ^^^^
|
= note: read <https://doc.rust-lang.org/nightly/rustdoc/the-doc-attribute.html#at-the-crate-level> for more information
= note: `#[deny(invalid_doc_attributes)]` on by default
help: to apply to the crate, use an inner attribute
|
508 | #![doc(test)]
| +
```
The `Input::File` and `Input::Text` cases should be very similar.
However, currently the `Input::File` case uses `catch_unwind` because,
until recently (#125815) there was a fallible version of
`new_parser_from_source_str` but only an infallible version of
`new_parser_from_file`. This difference wasn't fundamental, just an
overlooked gap in the API of `rustc_parse`.
Both of those operations are now fallible, so the `Input::File` and
`Input::Text` cases can made more similar, with no need for
`catch_unwind`. This also lets us simplify an `Option<Vec<Diag>>` to
`Vec<Diag>`.
