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.
There are some tests in the rustfmt test suite that are ignored by
default. I believe these tests are ignored because they have caused
issues with the the `rust-lang/rust` test suite.
However, we recently experienced an issue (5395) that would have been
avoided had these tests been running.
With the introduction of the new `#[rustfmt_only_ci_test]` attribute
macro we can run these tests when the `RUSTFMT_CI` environment variable
is set, which will presumably only be set during rustfmts CI runs.
When the environment variable is not set the `#[rustfmt_only_ci_test]`
will be replaced with an `#[ignore]`.
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.
Fixes 5167
When ``a.rs`` and ``a/mod.rs`` are both present we would emit an error
message telling the user that the module couldn't be found. However,
this behavior is misleading because we're dealing with an ambiguous
module path, not a "file not found" error.
Is the file ``a.rs`` or is it ``a/mod.rs``? Rustfmt can't decide, and
the user needs to resolve this ambiguity themselves.
Now, the error message displayed to the user is in line with what they
would see if they went to compile their code with these conflicting
module names.
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.
We only want to fall back if two conditions are met:
1) Initial module resolution is performed relative to some nested
directory.
2) Module resolution fails because of a ModError::FileNotFound error.
When these conditions are met we can try to fallback to searching for
the module's file relative to the dir_path instead of the nested
relative directory.
Fixes 5198
As demonstrated by 5198, it's possible that a directory name conflicts
with a rust file name. For example, src/lib/ and src/lib.rs.
If src/lib.rs references an external module like ``mod foo;``, then
module resolution will try to resolve ``foo`` to src/lib/foo.rs or
src/lib/foo/mod.rs. Module resolution would fail with a file not
found error if the ``foo`` module were defined at src/foo.rs.
When encountering these kinds of module resolution issues we now fall
back to the current directory and attempt to resolve the module again.
Given the current example, this means that if we can't find the module
``foo`` at src/lib/foo.rs or src/lib/foo/mod.rs, we'll attempt
to resolve the module to src/foo.rs.
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``.
