Breaking changes in rustfmt with 1.45.0

[Daniel-B-Smith]

This seems to be a re-occurrence of #73078. The rustfmt released with 1.45.0 no longer respects #![cfg_attr(rustfmt, rustfmt_skip)] which breaks our CI for some auto-generated files.

[calebcartwright]

Looks like 1.45.0 shipped with an older version of rustfmt

• rustc 1.45.0 --> rustfmt 1.4.15
• rustc 1.44.1 --> rustfmt 1.4.16
• rustc 1.44.0 --> rustfmt 1.4.14

Not sure how that happened, but rustfmt v1.4.16 is the version that had the fix and both 1.4.14 and 1.4.15 had the bug from #73078

[JohnTitor]

I think we missed a beta backport, as mentioned in https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/rustfmt.20in.201.2E45.2E0.

[Mark-Simulacrum]

"Missed" sort of implies that someone had raised it for beta backport, which I think never happened -- it seems like we just didn't consider a beta backport at all. I would not be opposed to doing a 1.45.1 release personally with the backport, cc @rust-lang/release for opinions.

We should, regardless, make sure that at least rustfmt 1.4.16 is in beta and nightly today.

[jonas-schievink]

👍 for backport + stable patch release

[calebcartwright]

We should, regardless, make sure that at least rustfmt 1.4.16 is in beta and nightly today.

nightly is on rustfmt 1.4.18 (though broken/unavailable ATM) and I believe beta is as well. Let us know if anything is needed from the rustfmt side though.

[miketimofeev]

Is there any chance of a new release with rustfmt 1.4.16 or even 1.4.17 today or tomorrow?

[Mark-Simulacrum]

It won't be that quick, for sure, but I am currently thinking Tuesday or Thursday next week. I'm hoping to prepare artifacts and such today or tomorrow.

[Mark-Simulacrum]

Okay I looked at which rustfmt release to promote to 1.45.1 and wasn't able to find a good candidate. I think we'll want the rustc-ap crates to be at version 659 -- but no rustfmt release has that. @calebcartwright @topecongiro -- could one of you take a look? If you'd like, you can also post a PR against rust-lang/rust stable branch which bumps rustfmt to whatever commit you think is the right one to release.

[calebcartwright]

IIRC rustfmt v1.4.17 has v659 of the rustc-ap crates, though may need to find the right pairing of rustfmt and rls that'll work there

[Mark-Simulacrum]

Initial draft is up at #74574, still has a few things left but I'm hoping to get that landed in the next few days so we can have artifacts ready for testing.

[calebcartwright]

@Mark-Simulacrum - the same thing appears to have happened with rls, as 1.45.0 has an older version of rls than 1.44.1

• rustc 1.44.0 --> rls 1.41.0 (2659cbf 2020-04-14)
• rustc 1.44.1 --> rls 1.41.0 (7d3aba2 2020-06-17)
• rustc 1.45.0 --> rls 1.41.0 (085f24b 2020-05-28)

I'm thinking the same combination of rls/rustfmt from 1.44.1 should be fine together: rls 1.41.0 (7d3aba2 2020-06-17) and rustfmt v1.4.16.

rustfmt v1.4.16 was released specifically for the 1.44.1 patch, whereas rustfmt v1.4.17 was intended to to do the same for nightly but was never actually merged to master because there was a broken toolstate issue that occurred around the same time (refs #73113). The only difference between these two rustfmt versions is rustc-ap v654 for rustfmt v1.4.16 and rustc-ap v659 for rustfmt v1.4.17

There may be some other combinations of rls/rustfmt that could work but I'd think the same ones from 1.44.1 would be safest.