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``.
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.
Fixes 5125
Previously, a newline was always added, even if the parameter name was
not preceded by any param attrs.
Now a newline is only added if there were param attrs.
* Fix newlines in JSON output
This changes the JSON output to be more consistent about where newlines are included. Previously it only included them between lines in a multiline diff. That meant single line changes were treated a bit weirdly. This changes it to append a newline to every line.
When feeding the results into `arc lint` this behaves correctly. I have only done limited testing though, in particular there's a possibility it might not work with files with `\r\n` endings (though that would have been the case before too).
Fixes#4259
* Update tests
# Conflicts:
# tests/writemode/target/output.json
Fixes 5119
When the directory structure was laid out as follows:
```
dir
|---mod_a
| |---sub_mod_1.rs
| |---sub_mod_2.rs
|---mod_a.rs
```
And ``mod_a.rs`` contains the following content:
```rust
mod mod_a {
mod sub_mod_1;
mod sub_mod_2;
}
```
rustfmt previously tried to find ``sub_mod_1.rs`` and ``sub_mod_2.rs``
in ``./mod_a/mod_a/``. This directory does not exist and this caused
rustfmt to fail with the error message:
Error writing files: failed to resolve mod
Now, both ``sub_mod_1.rs`` and ``sub_mod_2.rs`` are resolved correctly
and found at ``mod_a/sub_mod_1.rs`` and ``mod_a/sub_mod_2.rs``.
Fixes 5066
When a struct pattern that contained a ".." was formatted, it was
assumed that a trailing comma should always be added if the struct
fields weren't formatted vertically.
Now, a trailing comma is only added if not already included in the
reformatted struct fields.
Although the implementation is slightly different than the original PR,
the general idea is the same. After collecting all modules we want to
exclude formatting those that contain the #![rustfmt::skip] attribute.
Fixes 5088
Previously, rustfmt would add a new comment line anytime it reformatted
an itemized block within a comment when ``wrap_comments=true``. This
would lead to rustfmt adding empty comments with trailing whitespace.
Now, new comment lines are only added if the original comment spanned
multiple lines, if the comment needs to be wrapped, or if the comment
originally started with an empty comment line.
resolves 5012
resolves 4850
This behavior was noticed when using the ``trailing_comma = "Never"``
configuration option (5012).
This behavior was also noticed when using default configurations (4850).
rustfmt would add a trailing space to where clause bounds that had an
empty right hand side.
Now no trailing space is added to the end of these where clause bounds.
Resolves 5033
Trailing comments at the end of the root Module were removed because the
module span did not extend until the end of the file.
The root Module's span now encompasses the entire file, which ensures
that no comments are lost when using ``#![rustfmt::skip]``
Resolves 4615
Previously only Vertical and Mixed enum variants of DefinitiveListTactic
were considered when rewriting pre-comments for inner items in
lists::write_list.
Because we failed to considering the SpecialMacro variant we ended up in
a scenario where a ListItem with a pre_comment and a pre_comment_style
of ListItemCommentStyle::DifferentLine was written on the same line as the
list item itself.
Now we apply the same pre-comment formatting to SpecialMacro, Vertical,
and Mixed variants of DefinitiveListTactic.
Resolves 5009
For loops represented by a ControlFlow object use " in" as their connector.
rustfmt searches for the first uncommented occurrence of the word "in" within the
current span and adjusts it's starting point to look for comments right after that.
visually this looks like this:
rustfmt starts looking for comments here
|
V
for x in /* ... */ 0..1 {}
This works well in most cases, however when the pattern also contains
the word "in", this leads to issues.
rustfmt starts looking for comments here
|
V
for in_here in /* ... */ 0..1 {}
-------
pattern
In order to correctly identify the connector, the new approach first
updates the span to start after the pattern and then searches for the
first uncommented occurrence of "in".
Resolves 5011
Tuple structs with visibility modifiers and comments before the first
field were incorrectly formatted. Comments would duplicate part of the
visibility modifier and struct name.
When trying to parse the tuple fields the ``items::Context`` searches
for the opening '(', but because the visibility modifier introduces
another '(' -- for example ``pub(crate)`` -- the parsing gets messed up.
Now the span is adjusted to start after the struct identifier, or after
any generics. Adjusting the span in this way ensures that the
``items::Contex`` will correctly find the tuple fields.
rustfmt should only support rewriting a struct in an expression
position with alignment (non-default behavior) when there is no rest
(with or without a base) and all of the fields are non-shorthand.
Fixes 4984
When parsing derive attributes we're only concerned about the traits
and comments listed between the opening and closing parentheses.
Derive attribute spans currently start at the '#'.
Span starts here
|
v
#[derive(...)]
After this update the derive spans start after the opening '('.
Span starts here
|
V
#[derive(...)]
