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.
Update docs to include an example of running `rustfmt` built from src,
and show how users can set the `RUSTFMT` environment variable to test
`cargo-fmt` using the `rustfmt` they built from src.
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()
There was an issue with the script when passing optional rustfmt configs
without specifying a commit hash. Because these optional values are
passed via positional arguments the configs ($4) would be used in place
of the commit hash ($3). Now that we set a default value for the
optional commit hash we avoid this problem.
The `set -e` option is used to immediately exit if any command exits
with a non zero exit status. This will help us catch errors in the
script, for example, needing the `LD_LIBRARY_PATH` to be set.
There were some upstream changes made a while back that requires this to
be set when building rustfmt from source like we do in the
`check_diff.sh` script.
See issue 5675 for more details.
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.
These test cases try to cover various edge cases. For example, comments
around the else keyword and long, unbreakable, single-line initializer
expressions, and long patterns.
`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.
