That the API and formatting will be backwards compatible.
No.
There are some limitations, macros is one of them, that means you might need to fix up your code after formatting, but once you've done it once, you'll never have to do it again.
I intend for there to be a 2.0 and for it not to take too long (six months to one year) and macros is one of the things I want to focus on. However, we can't wait for Rustfmt to be perfect before making a 1.0 release, or we'd never have one. In particular, the stability of rustfmt (or lack thereof) is something that is stopping a lot of people using it on CI, and thus using it consistently. I believe it is not important for tools to stick to the '1.0 forever' policy of Rust itself.
I'm surprised by that, it certainly doesn't always happen. Could you report an issue please?
How many rust-lang projects are using rustfmt? Are we dogfooding it in rust-lang/rust ?
It's been used on Cargo, Rustup, the RLS and Rustfmt itself, plus many other not central projects. It has been used on parts of the Rust repo, but certainly not all of it.
to check that all code is automatically formatted on CI?
The trouble is this is a chicken and egg thing - if rustfmt isn't stable, people don't want to use it in CI.
rustfmt does currently still break their build
To be clear, the 1.0 label is a mark of stability, it is not saying that it is bug free (because it is software), but it saying, if your code formats without bugs then it will continue to do so in the exact same way.
And to be clear again, we're only announcing a 1.0 RC, if it turns out there are lots of bugs and poor formatings, then it can stay a release candidate for a long time (of course I'd rather it didn't.