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.
Previously we were only building rustfmt with default features in CI. We
recently received a report that rustfmt was unable to compile with the
`generic-simd` feature, which is not enabled by default. To prevent a
similar situation in the future we'll start build nightly rustfmt with
all features enabled.
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`.
