- Rename them both `as_str`, which is the typical name for a function
that returns a `&str`. (`to_string` is appropriate for functions
returning `String` or maybe `Cow<'a, str>`.)
- Change `UnOp::as_str` from an associated function (weird!) to a
method.
- Avoid needless `self` dereferences.
Fixes 5912
When `control_brace_style = "AlwaysNextLine"`, the code seems to always assume that `body_prefix` is `{`. This is however not the case when `match_arm_blocks = false`. This causes `block_sep` to introduce extra white space that causes the error.
The fix was to check if `body_prefix` is empty before matching on `ControlBraceStyle::AlwaysNextLine`.
report `unused_import` for empty reexports even it is pub
Fixes#116032
An easy fix. r? `@petrochenkov`
(Discovered this issue while reviewing #115993.)
for now, let-chains can only be formatted on a single line if the chain
consits of 2 expressions where the first is an identifier proceeded by
any number of unary operators and the second is a let-expr.
Fixes 5835
Ordered markdown lists start with 0-9 digits followed by a `.` or a `)`.
Now, rustfmt ensure that the `.` or `)` is only preceded by numeric
characters before deciding that it's reached an `ItemizedBlock`
Anonymous structs or unions are only allowed in struct field
definitions.
Co-authored-by: carbotaniuman <41451839+carbotaniuman@users.noreply.github.com>
Anonymous structs or unions are only allowed in struct field
definitions.
Co-authored-by: carbotaniuman <41451839+carbotaniuman@users.noreply.github.com>
* Prevent ICE when formatting item-only `vec!{}`
Fixes 5735
Attempting to format invocations of macros which are considered "forced
bracket macros" (currently only `vec!`), but are invoked with braces
instead of brackets, and contain only items in their token trees,
currently triggers an ICE in rustfmt. This is because the function that
handles formatting macro invocations containing only items,
`rewrite_macro_with_items`, assumes that the forced delimiter style of
the macro being formatted is the same as the delimiter style in the
macro's source text when attempting to locate the span after the macro's
opening delimiter. This leads to the construction of an invalid span,
triggering the ICE.
The fix here is to pass the old delimiter style to
`rewrite_macro_with_items` as well, so that it can successfully locate
the span.
fixes 5701
Whenever we see an `extern "Rust"` on a function, we don't strip it from the function.
If there's any future desire to have rustfmt remove an explicit "Rust" ABI, as it historically did prior to this change, then we can consider updating the rustfmt config surface to support that scenario
* Inline format arguments for easier reading
Code becomes shorter and often easier to read when format args are inlined. Note that I skipped the mixed cases to make it more straightforward (could be done separatelly).
Also, there are two FIXME comments - for some reasons inlining makes format string exceed 100 char line width and crash.
```
cargo clippy --workspace --allow-dirty --fix --benches --tests --bins -- -A clippy::all -W clippy::uninlined_format_args
```
* address feedback
Previously we alwasy assumed the match arm pattern would have
`shape.width` - 5 characters of space to work with.
Now if we're formatting a block expression with a label we'll take the
label into account.
Improve spans for indexing expressions
fixes#114388
Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location.
This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR.
r? compiler-errors
Improve spans for indexing expressions
fixes#114388
Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location.
This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR.
r? compiler-errors
Lots of tiny incremental simplifications of `EmitterWriter` internals
ignore the first commit, it's https://github.com/rust-lang/rust/pull/114088 squashed and rebased, but it's needed to use to use `derive_setters`, as they need a newer `syn` version.
Then this PR starts out with removing many arguments that are almost always defaulted to `None` or `false` and replace them with builder methods that can set these fields in the few cases that want to set them.
After that it's one commit after the other that removes or merges things until everything becomes some very simple trait objects
Lots of tiny incremental simplifications of `EmitterWriter` internals
ignore the first commit, it's https://github.com/rust-lang/rust/pull/114088 squashed and rebased, but it's needed to use to use `derive_setters`, as they need a newer `syn` version.
Then this PR starts out with removing many arguments that are almost always defaulted to `None` or `false` and replace them with builder methods that can set these fields in the few cases that want to set them.
After that it's one commit after the other that removes or merges things until everything becomes some very simple trait objects
Indexing is similar to method calls in having an arbitrary
left-hand-side and then something on the right, which is the main part
of the expression. Method calls already have a span for that right part,
but indexing does not. This means that long method chains that use
indexing have really bad spans, especially when the indexing panics and
that span in coverted into a panic location.
This does the same thing as method calls for the AST and HIR, storing an
extra span which is then put into the `fn_span` field in THIR.
Indexing is similar to method calls in having an arbitrary
left-hand-side and then something on the right, which is the main part
of the expression. Method calls already have a span for that right part,
but indexing does not. This means that long method chains that use
indexing have really bad spans, especially when the indexing panics and
that span in coverted into a panic location.
This does the same thing as method calls for the AST and HIR, storing an
extra span which is then put into the `fn_span` field in THIR.
It's the same as `Delimiter`, minus the `Invisible` variant. I'm
generally in favour of using types to make impossible states
unrepresentable, but this one feels very low-value, and the conversions
between the two types are annoying and confusing.
Look at the change in `src/tools/rustfmt/src/expr.rs` for an example:
the old code converted from `MacDelimiter` to `Delimiter` and back
again, for no good reason. This suggests the author was confused about
the types.
It's the same as `Delimiter`, minus the `Invisible` variant. I'm
generally in favour of using types to make impossible states
unrepresentable, but this one feels very low-value, and the conversions
between the two types are annoying and confusing.
Look at the change in `src/tools/rustfmt/src/expr.rs` for an example:
the old code converted from `MacDelimiter` to `Delimiter` and back
again, for no good reason. This suggests the author was confused about
the types.
Less `TokenTree` cloning
`TokenTreeCursor` has this comment on it:
```
// FIXME: Many uses of this can be replaced with by-reference iterator to avoid clones.
```
This PR completes that FIXME. It doesn't have much perf effect, but at least we now know that.
r? `@petrochenkov`
Resolves 5542
Prior to rust-lang/rust#101212 the `ast::TraitObjectSyntax` enum only
had two variants `Dyn` and `None`. The PR that introduced the `dyn*`
syntax added a new variant `DynStar`, but did not update the formatting
rules to account for the new variant.
Now the new `DynStar` variant is properly handled and is no longer
removed by rustfmt.
Currently, Clippy, Miri, Rustfmt, and rustc all use an environment variable to
indicate that output should be blessed, but they use different variable names.
In order to improve consistency, this patch applies the following changes:
- Emit `RUSTC_BLESS` within `prepare_cargo_test` so it is always
available
- Change usage of `MIRI_BLESS` in the Miri subtree to use `RUSTC_BLESS`
- Change usage of `BLESS` in the Clippy subtree to `RUSTC_BLESS`
- Change usage of `BLESS` in the Rustfmt subtree to `RUSTC_BLESS`
- Adjust the blessable test in `rustc_errors` to use this same
convention
- Update documentation where applicable
Any tools that uses `RUSTC_BLESS` should check that it is set to any value
other than `"0"`.
Implement rust-lang/compiler-team#578.
When an ICE is encountered on nightly releases, the new rustc panic
handler will also write the contents of the backtrace to disk. If any
`delay_span_bug`s are encountered, their backtrace is also added to the
file. The platform and rustc version will also be collected.
Fixes 5730
Previously rustfmt was attempting to slice a string with an invalid
range (`start > end`), leading to the ICE.
When formatting a macro transcriber snippet consisting of a lone
semicolon, the snippet was being formatted into the empty string,
leading the enclosing `fn main() {\n}` added by `format_code_block` to
be formatted into `fn main() {}`. However, rustfmt was assuming that the
enclosing function string's length had been left unchanged. This was
leading to an invalid range being constructed when attempting to trim
off the enclosing function.
The fix is to just clamp the range's start to be less than or equal
to the range's end, since if `end < start` there's nothing to iterate
over anyway.
* Use matches!() macro to improve readability
1. Use `matches!()` macro in `is_line_comment` and `is_block_comment` to
improve readability.
2. Very sightly improve the wording of the doc comment for these two functions.
* Update wording on doc comment on is_line_comment()
By reversing the logic I felt that the code became a clearer. Also,
added a comment to make it clear that we need to take the trailing
semicolon for the `let-else` statement into account.
This allows users to configure the maximum length of a single line
`let-else` statements. `let-else` statements that otherwise meet the
requirements to be formatted on a single line will have their divergent
`else` block formatted over multiple lines if they exceed this length.
**Note**: `single_line_let_else_max_widt` will be introduced as a stable
configuration option.
Syntactically accept `become` expressions (explicit tail calls experiment)
This adds `ast::ExprKind::Become`, implements parsing and properly gates the feature.
cc `@scottmcm`
`rewrite_let_else_block` gives us more control over allowing the `else`
block to be formatted on a single line than
`<ast::Block as Rewrite>::rewrite`.
This will make it easier to format the divergent blocks of `let-else`
statements since it'll be easier to prevent the block from being
formatted on a single line if the preconditions aren't met.
The function properly handles recovering comments before and after the
`else` keyword, and properly handles how to write the else when users
configure `control_brace_style`.
Fixes 5686
For reference, explicit discriminants were proposed in [RFC-2363].
`ast::Variant` spans extend to include explicit discriminants when they
are present.
Now we'll adjust the span of enum variants to exclude any explicit
discriminant.
[RFC-2363]: https://rust-lang.github.io/rfcs/2363-arbitrary-enum-discriminant.html
Fixes 5729
`parse_attribute` will panic if the first token is not a `#`. To prevent
this we return early instead of trying to parse an invalid attribute.
Make the BUG_REPORT_URL configurable by tools
This greatly simplifies how hard it is to set a custom bug report url; previously tools had to copy
the entire hook implementation.
I haven't changed clippy in case they want to make the change upstream instead of the subtree, but
I'm happy to do so here if the maintainers want - cc ````@rust-lang/clippy````
Fixes https://github.com/rust-lang/rust/issues/109486.
