rust-lang / rust-lang/rustfmt

Comment affects whether `return expr` fmts to `return expr;`

Open
#6,150 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

A-comments C-bug E-needs-investigation
Dominant language
Rust
Stars
7k
Forks
1.1k
Avg merge
2d 13h
Merged PRs (30d)
24

Description

adding a comment here caused an unrelated diff in a semicolon formatting:

                     ArgValue::Lit(other) => {
+                        // FIXME: add a ui test for this
                         return Err(syn::Error::new(
                             other.span(),
                             "expected boolean, path, or string literal",
-                        ))
+                        ));
                     }

at least it doesn't depend much on the exact position of the comment, just whether it sees one?

             e => {
                 return Err(syn::Error::new(
+                    // FIXME: add a UI test for this
                     input.span(),
                     format!("Invalid option `{e}` inside `{ident} {input}`"),
-                ))
+                ));
            }

This sort of thing should not matter.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the formatting change with the two Rust snippets shown in the issue, comparing versions with and without comments. Trace the formatter behavior responsible for semicolon insertion and add a regression test showing that comments do not change whether return expr is formatted with a semicolon.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
tooling
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.