Formatting the rust-lang/rust repository about compiler-team

[estebank]

Please make it a self contained comment annotation to opt out in tests, not a centralized opt out file.

[estebank]

This feels like it would only be a problem when we start using a feature in the compiler itself, not for the tests, and I would argue that having rustfmt support for features that we feel are useful/safe enough for the compiler should be a priority.

[eddyb]

@nikomatsakis meta question: should the last two sections of the template be left off?

[nikomatsakis]

We discussed this in our planning meeting today and decided that we do not need to have a meeting for this. We believe there is general agreement to the plan. However, @Mark-Simulacrum wanted to make sure we uncovered anybody who might have a strong objection, therefore I'm doing a poll:

@rfcbot poll Do you generally approve of this plan to format the repository?

[rfcbot]

Team member @nikomatsakis has asked teams: T-compiler, for consensus on:

Do you generally approve of this plan to format the repository?

• @Zoxc
• @cramertj
• @eddyb
• @estebank
• @michaelwoerister
• @nagisa
• @nikomatsakis
• @oli-obk
• @petrochenkov
• @pnkfelix
• @varkor

[nikomatsakis]

I'm going to close this issue -- we didn't feel this needed to be a meeting.

[cramertj]

I actually had a minor question in the meantime: how should we handle the formatting of tests which are testing new syntax that is being introduced in the change, but not yet supported by rustfmt?

[Centril]

@cramertj We can exclude those directories explicitly in some manner (either by not having .enforcefmt in there or by listing paths explicitly).

[Centril]

That actually might be a problem when we use unstable features in the compiler itself... I hope rustfmt handles those gracefully.

[cramertj]

It does not-- it currently fails to format anything if your code doesn't parse as a valid rust file.

[Centril]

@cramertj ah; but does rustfmt handle nightly features at least for some selection of features?

[cramertj]

@Centril it handles some things, but obviously if you've just implemented a feature it wouldn't yet support it.

[Centril]

@cramertj Makes sense; this might be a problem in some instances -- which I guess we can fix with opt-outs in case of emergency -- on the other hand, this might also push us to be better at introducing things to rustfmt quicker, which might be a welcome outcome.

[cramertj]

Are we not planning to require that tests also be formatted?

[Centril]

@cramertj Sure, but we can do opt-outs for specific folders and files for newly introduced features so as to not let development of new features be hindered by lack of initial rustfmt support. It's sort of a catch-22. Rustfmt can't easily add support without the feature implemented and we couldn't test if we didn't opt out without rustfmt support.

[varkor]

I would like to see some discussion about the settings we use for rustfmt in rustc, but I definitely think formatting the repository is a good idea overall.

[Zoxc]

I would like a tool which can format a branch based on say the last commit before the repo is formatted, injecting a commit which formats the repo. So the procedure for updating a branch would be:

• rebase to the last commit which is unformatted
• run the tool
• rebase to master, but skip the commit formatting the repo