Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Running rustfmt on rust-lang/rust codebase #66688

Closed
dtolnay opened this issue Nov 24, 2019 · 2 comments
Closed

Running rustfmt on rust-lang/rust codebase #66688

dtolnay opened this issue Nov 24, 2019 · 2 comments
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@dtolnay
Copy link
Member

dtolnay commented Nov 24, 2019 •
edited
Loading

Filing this to track https://internals.rust-lang.org/t/running-rustfmt-on-rust-lang-rust-and-other-rust-lang-repositories/8732 in a way that doesn't get locked every 90 days, since I believe we all still want this to happen.

Using rustfmt would have several wins:

  • Adopt a uniform style, of course
  • But also resolve problems that contributors have either:
    • trying to figure out our style (heh, good luck)
    • accidentally running rustfmt on stuff that drags in a lot of auxiliary diffs

There are obviously two main approaches:

  • Flag day
  • Gradual transition

I am partial to “flag day” myself, but I could go either way.

There is another question too: how to keep things formatted? In my ideal world, this would be fairly painless, but I’m not sure how best to achieve that (one idea I had was a rustfmtbot that runs rustfmt on people’s PRs and pushes commits automatically, but that does not exist afaik).
@dtolnay dtolnay added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. labels Nov 24, 2019
@dtolnay dtolnay mentioned this issue Nov 24, 2019
Merged
@JohnTitor JohnTitor added the C-cleanup Category: PRs that clean code up or issues documenting cleanup. label Nov 24, 2019
@Centril
Copy link
Contributor

Centril commented Nov 25, 2019 •
edited
Loading

The compiler team decided to move forward with enforcing formatting in the repo in rust-lang/compiler-team#80 and the plan is being implemented in #65939.

@Centril Centril added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Nov 25, 2019
bors added a commit that referenced this issue Nov 27, 2019
@bors
Auto merge of #66691 - dtolnay:fmt0, r=sfackler
04e69e4 
Format libcore with rustfmt

I am interested in whether we can begin cautious incremental progress on #66688 and assess along the way whether we can keep the disruption sufficiently small.

This PR applies rustfmt with default settings to files in src/libcore *that are not involved in any currently open PR* to minimize merge conflicts. The list of files involved in open PRs was determined by querying GitHub's GraphQL API  [with this script](https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8).

With the list of files from the script in `outstanding_files`, the relevant commands were:

```console
$ find src/libcore -name '*.rs' | xargs rustfmt --edition=2018
$ rg libcore outstanding_files | xargs git checkout --
```

Repeating this process several months apart should get us coverage of most of the rest of libcore.
@Centril
Copy link
Contributor

Centril commented Jan 1, 2020

Closing as done.

@Centril Centril closed this as completed Jan 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Centril @dtolnay @JohnTitor