Skip to content

Fix formatting of comments in empty structs #4875

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

Szymongib
Copy link
Contributor

Currently comments in empty structs are formatted weirdly. This PR attempts to fix it by indenting all one line comments to the same one depth indentation.

Example can be found in the issue and tests.

Fixes: #4854

@Szymongib Szymongib marked this pull request as ready for review June 18, 2021 14:55
@calebcartwright
Copy link
Member

👋 thanks so much for the PR! will take a closer look at this soon and get back to you with any feedback

Alexander Melentyev and others added 3 commits June 21, 2021 12:11
…rk-Simulacrum

rustfmt: load nested out-of-line mods correctly

This should address rust-lang#4874

r? `@Mark-Simulacrum`

Decided to make the change directly in tree here for expediency/to minimize any potential backporting issues, and because there's some subtree sync items I need to get resolved before pulling from r-l/rustfmt
@calebcartwright
Copy link
Member

Thanks again and sorry for the delay! I think we'd need a different fix to really address the issue vs trying to work around a couple of the symptoms. For example, the issue isn't exclusive to line style comments:

struct Struct {
    /*
     * fsdfsdfsdf
     * sdfsdf
     */
}

The issue is really that a struct with no fields and a multiline comment/multiple comments doesn't get formatted with the correct shape. It might be worth seeing if another one of the comment recovery helper functions (like combine_strs_with_missing_comments) could be used instead

The recursion_limit attribute avoids the following error:

```
error[E0275]: overflow evaluating the requirement `std::ptr::Unique<rustc_ast::Pat>: std::marker::Send`
  |
  = help: consider adding a `#![recursion_limit="256"]` attribute to your crate (`rustfmt_nightly`)
```
@Szymongib
Copy link
Contributor Author

Szymongib commented Jul 7, 2021

Thanks for taking the time to look at it @calebcartwright!

That is a good point that the other comments types are broken too.

Sorry for delay but it took me a while to figure it out.
The combine_strs_with_missing_comments does not seem to do any better job so I ended up using FmtVisitor::format_missing_no_indent.
It seems that now both single line comments as well as multiple/multiline comments work fine.

Thanks again for feedback and let me know if new changes make sense!

PatchMixolydic and others added 10 commits July 25, 2021 22:53
This was added to Configurations.md in rust-lang#4618, but the option wasn't
actually made available. This should let people who are using Rust 2021
on nightly rustc run `cargo fmt` again.
Add double quotes around `Crate` so that it can be copied directly into a `Cargo.toml` file
On stable, running with `--help|-h` shows information about `file-lines`
which is a nightly-only option. This commit removes all mention of
`file-lines` from the help message on stable.

There is room for improvement here; perhaps a new struct called, e.g.,
`StableOptions` could be added to complement the existing
`GetOptsOptions` struct. `StableOptions` could have a field for each
field in `GetOptsOptions`, with each field's value being a `bool` that
specifies whether or not the option exists on stable. Or is this adding
too much complexity?
* Updating outdated links

Updating the links to the docs and source code for `ast.rs`. Seems like it was moved to a new crate at some point.

* Updating more outdated links

This time, the links to the `fmt-rfcs` repository, which is now owned by
`rust-dev-tools` (although GitHub was redirecting anyway).

* Update Contributing.md

Co-authored-by: Caleb Cartwright <[email protected]>

Co-authored-by: Caleb Cartwright <[email protected]>
In the event a pattern starts with a leading pipe
the pattern span will contain, and begin with, the pipe.

This updates the process to see if a match arm contains
a leading pipe by leveraging this recent(ish) change to
the patterns in the AST, and avoids an indexing bug that
occurs when a pattern starts with a non-ascii char in the
old implementation.
clippy::bind_instead_of_map
clippy::branches_sharing_code
clippy::collapsible_match
clippy::inconsistent_struct_constructor
clippy::int_plus_one
clippy::iter_count
clippy::iter_nth_zero
clippy::manual_range_contains
clippy::match_like_matches_macro
clippy::needless::collect
clippy::needless_question_mark
clippy::needless_return
clippy::op_ref
clippy::option_as_ref_deref
clippy::ptr_arg
clippy::redundant_clone
clippy::redundant_closure
clippy::redundant_static_lifetimes
clippy::search_is_some
clippy::#single_char_add_str
clippy::single_char_pattern
clippy::single_component_path_imports
clippy::single_match
clippy::skip_while_next
clippy::unnecessary_lazy_evaluations
clippy::unnecessary_unwrap
clippy::useless_conversion
clippy::useless_format
calebcartwright and others added 22 commits December 19, 2021 15:22
Fixes 5151

Details about the qualified path are now passed along so that rustfmt
can include them when formatting struct literals.
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``.
* Fix some possible panics when using `--check` with stdin.

One case which doesn't work is when there are only line ending fixes;
with stdin rustfmt is unable to detect the difference as it stores
the input with Unix line endings.

* Add test for `rustfmt --check -l` with stdin.
* 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 rust-lang#4259

* Update tests
# Conflicts:
#	tests/writemode/target/output.json
# Conflicts:
#	src/config/file_lines.rs
#	src/rustfmt/main.rs
#	src/test/mod.rs
@ytmimi
Copy link
Contributor

ytmimi commented Jan 11, 2022

Hey, I know it's been a while since you asked me to review. The fix is actually a lot simpler. The issue is items::format_empty_struct_or_tuple is calling rewrite_missing_comment with the right shape. The shape needs to be block indented so that each comment after the first is properly offset.

@Szymongib could you make this change to items::format_empty_struct_or_tuple instead.

-    match rewrite_missing_comment(span, Shape::indented(offset, context.config), context) {
+    // indented shape for proper indenting of multi-line comments
+    let shape = Shape::indented(offset.block_indent(context.config), context.config);
+    match rewrite_missing_comment(span, shape, context) {

This change breaks some test, but as far as I can tell each test that is broken explicitly states that the test can be reformatted once 4854 is fixed. For example:

Mismatch at tests/source\comments-in-lists\wrap-comments-true.rs:43:

 pub struct S2 {
     // This can be changed once https://github.com/rust-lang/rustfmt/issues/4854 is fixed
-// Expand as needed, numbers should be ascending according to the stage
-// through the inclusion pipeline, or according to the descriptions
+    // Expand as needed, numbers should be ascending according to the stage
+    // through the inclusion pipeline, or according to the descriptions
 }

@Szymongib Szymongib force-pushed the fix/fix-formating-of-comments-in-empty-structs branch from e821b9c to a1e4f8e Compare January 14, 2022 09:08
@Szymongib
Copy link
Contributor Author

Thanks @ytmimi it is indeed a much simpler fix, I see tho that branches changed so I will open another PR against master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Comments after the first one in empty struct are not formatted nicely