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`
* 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 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.
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.
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
Closes#5488
Fix for #5488. Before applying shorthand initialization for structs,
check if identifier is a literal (e.g. tuple struct). If yes, then do
not apply short hand initialization.
Added test case to validate the changes for the fix.
* Backport PR #4730 that fix issue #4689
* Test files for each Verion One and Two
* Simplify per review comment - use defer and matches!
* Changes per reviewer comments for reducing indentations
Closes 3245
Closes 3561
These issues were originally linked in issue 3672 and as was mentioned
in PR 3706, it's unclear which commit resolved the issue but the issue
can no longer be reproduced.
fn_args_layout is now deprecated.
This option was renamed to better communicate that it affects the layout
of parameters in function signatures and not the layout of arguments in
function calls.
Because the `fn_args_layout` is a stable option the renamed option is
also stable, however users who set `fn_args_layout` will get a warning
message letting them know that the option has been renamed.
