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
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.
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
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.
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.
Closes 2534
The behavior described in the original issue can no longer be
reproduced. The tests show that to be the case regardless of if
`format_macro_matchers` is `true` or `false`.
* Bugfix: Now slash/start comments aren't duplicated on trait parameters.
* Removing unnecesary comment.
* Improvements: Improving the BytePos offset.
* Improvements: Improving the description of the test cases.
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.
When useing `version=One` rustfmt will treat the leading `r#` as part of
the `UseSegment` used for sorting. When using `version=Two` rustfmt will
ignore the leading `r#` and only consider the name of the identifier
when sorting the `UseSegment`.
Closes 3937
It's unclear which change fixed the `format_code_in_doc_comments=true`
issue brought up in this issue, however I'm unable to reproduce the
error on the current master.
The added test cases should serve to prevent a regression.
It's unclear which PR resolved this issue, however the behavior of
adding inline comments to the next line can't be reproduced.
These test cases should serve to prevent a regression.
* fix(rustfmt): fix struct field formatting with doc comments present
Fixes#5215
* fix review feedbacks
* add unit test without doc comment
* move tests to a seperate file
* add additional test cases
* reintroduce a newline at the of test/souce/structs.rs
Fixes 5270
Previously, rustfmt only checked the `merge_derives` configuration value
to determine if it should merge_derives. This lead to derives being
merged even when annotated with the `rustfmt::skip` attribute.
Now, rustfmt also checks if derives are explicitly being skipped in the
current context via the `rustfmt::skip` attribute.
Fixes 5273
Previously, rustfmt searched for the start of a struct body after the
opening `{`. In most cases this works just fine, but const values can
also be defined between `{ }`, which lead to issues when rewriting the
struct body.
Now, rustfmt will search for the `{` after the generic argument list to
guarantee that the `{` it finds is the start of the struct body.
When struct_field_align_threshold is non-zero and trailing_comma is set to
"Never," struct field separators are omitted between field groups. This issue is
resolved by forcing separators between groups.
Fixes#4791.
A test is included with a minimal reproducible example.
Fixes 5238
A markdown header is defined by a string that starts with `#`.
Previously, rustfmt would wrap long markdown headers when
`wrap_comments=true`. This lead to issues when rendering these headers
in HTML using rustdoc.
Now, rustfmt leaves markdown headers alone when wrapping comments.
Fixes 5157
Doc comments support markdown, but rustfmt didn't previously assign any
semantic value to leading '> ' in comments. This lead to poor formatting
when using ``wrap_comments=true``.
Now, rustfmt treats block quotes as itemized blocks, which greatly
improves how block quotes are formatted when ``wrap_comments=true``.
Fixes 5042
Previously, trailing commas were removed from the last inline comment.
This lead to rustfmt refusing to format code snippets because
the original comment did not match the rewritten comment.
Now, when rustfmt extracts the last inline comment it leaves trailing
separators alone. Rustfmt does not need to remove these separators
because they are commented out.
