Run `rustfmt` on the emitted bindings

[fitzgen]

Usually, we generate code that is fairly readable.

This is not always the case, and will often not be the case once --impl-debug lands: https://github.com/rust-lang-nursery/rust-bindgen/pull/899/files#diff-a1db39afd224d69f0732cc221a7430b8R32

We should run rustfmt on the code we emit to give it a consistent, pretty, and readable formatting.

While rustfmt does have a programmatic API, it is using libsyntax from the compiler's internals. This means it is nightly only.

So maybe we want to avoid using rustfmt as a library, and just invoke the rustfmt on the $PATH, if any? If we do this, we should pin the version of rustfmt we use with our test expectations, so that our tests don't break when new versions of rustfmt are published, or when contributors are using different versions of rustfmt.

cc @nrc

[bkchr]

Couldn't rustfmt 0.9 be used for stable and rustfmt-nightly for nightly?

[fitzgen]

Couldn't rustfmt 0.9 be used for stable and rustfmt-nightly for nightly?

If they (ever start to) format the code slightly differently, then we would have to maintain double the test expectations, which is 💩

[bkchr]

Yes that would be shitty. Do we really need formatted tests?

Yeah the would be easier to read, but I don't know if the rustfmt output is already that stable between different releases :/

[nrc]

I think rustfmt and rustfmt-nightly already have non-trivial differences in their formatting. I would expect that rustfmt formatting would not be stable enough even in the long run for all tests (because of bug fixes, etc.)

Running system rustfmt would be the best bet I think. And I guess if the user doesn't have rustfmt, you don't format, which is not awful. And if you have the facility to not run formatting in some cases, then you use that for testing too.

[fitzgen]

Do we really need formatted tests?

Certainly it isn't critical that the test expectations be formatted. I think it is more important for every day bindgen users: they should be able to easily read the bindings so that they can use them.

We could (should) make rustfmting an option. I want to say that it should be on-by-default, but maybe we should be conservative and start with it off and then turn it on-by-default later.

Running system rustfmt would be the best bet I think. And I guess if the user doesn't have rustfmt, you don't format, which is not awful.

Sounds like a plan.

[emilio]

Sorry for running late to the party, but I don't get why this is needed. What's the use case for this?

Seems like if you use bindgen as a build dependency, then you basically don't care about how the output looks. If you don't, and you check-in the generated bindings, then I can't see why can't you format the bindings yourself, and why is support on bindgen itself required.

This makes us pull a new dependency in mozilla-central, which is probably not a huge issue, but I still don't know why the support in bindgen is helpful.

[fitzgen]

What's the use case for this?

Occasionally, during development, one needs to read the generated bindings. Generally, this hasn't been problematic because the emitted bindings tended to be well formatted. This is no longer always the case after we we started emitted Debug implementations for things that couldn't derive Debug automatically.

Seems like if you use bindgen as a build dependency, then you basically don't care about how the output looks

Even when I do this, I still find myself needing to read the bindings to figure out what the exact name for some anonymous type is or whatever. It just comes up during development and debugging sometimes.

This makes us pull a new dependency in mozilla-central

This is a real problem, and I should have caught this in review. Apologies. We should put rustfmting and the new dependency behind a new feature. I think it should OK for this new feature to be on by default, and m-c can turn it off manually. Does that work for you, @emilio?