Rust: `rustfmt` no longer builds after rust-lang/rust#74073

Created on 6 Jul 2020  路  12Comments  路  Source: rust-lang/rust

Hello, this is your friendly neighborhood mergebot.
After merging PR rust-lang/rust#74073, I observed that the tool rustfmt no longer builds.
A follow-up PR to the repository https://github.com/rust-lang/rustfmt is needed to fix the fallout.

cc @Manishearth, do you think you would have time to do the follow-up work?
If so, that would be great!

And nominating for compiler team prioritization.

C-bug

Most helpful comment

The original cause for this issue was #74236 which AIUI was indeed resolve by #74240 (and thus #74080 as well as rls was broken since it has rustfmt in its dep tree). However, a separate issue relative to the rustc-ap crates in rustfmt's dep tree popped up the same day #74240 was merged so we didn't discover the other issue til the next day and the bot didn't open a new issue.

We're on the last leg of updating the rustc-ap crates to fix that alternative issue, but just wanted to clarify the current broken toolstate is indeed a separate issue from the one discussed in this thread.

All 12 comments

@topecongiro @Xanewok not sure if either have you had a chance to look at this latest broken toolstate, but I'm a bit puzzled :thinking:

I have not been able to reproduce the compile errors like I've always been able to do with previous broken toolstate issues for rustfmt, and have tested with the below toolchains and can successfully compile the same version of rustfmt successfully with each:

  • nightly-2020-07-09-x86_64-unknown-linux-gnu
  • nightly-2020-07-08-x86_64-unknown-linux-gnu
  • nightly-2020-07-07-x86_64-unknown-linux-gnu
  • nightly-2020-07-06-x86_64-unknown-linux-gnu
  • nightly-2020-07-05-x86_64-unknown-linux-gnu

Also checked on Windows (x86_64-pc-windows-msvc)

And AFAICT both rustfmt and rls components are available via rustup
https://rust-lang.github.io/rustup-components-history/
image

Am I missing something?

@calebcartwright I could not reproduce the build error either.

@Manishearth Is there a link to the entire build log?

Yes, https://github.com/rust-lang-ci/rust/runs/839815076, pick one of the builds that says "tools"

Thanks @Manishearth that was helpful

@topecongiro you've probably found it already, but here's some direct links to where the rustfmt build starts

https://github.com/rust-lang-ci/rust/runs/839579965#step:22:7922 (linux)
https://github.com/rust-lang-ci/rust/runs/839580000#step:22:7214 (windows)

One thing that jumps out to me is the different commit from the logs vs. what I'm seeing with the toolchain from rustup

note: rustc 1.46.0-nightly (0c03aee8b 2020-07-05) running on x86_64-unknown-linux-gnu
$ rustc --version
rustc 1.46.0-nightly (2753fab7c 2020-07-05)

Maybe we're lucky and it got fixed before the nightly publish that day :laughing: (it didn't)

Here's a more recent run where the build is still failing
https://github.com/rust-lang-ci/rust/runs/852886590?check_suite_focus=true#step:22:7214

This only reproduces with debug assertions enabled while building rustc.

x.py build tools/rustfmt works after I apply https://github.com/da-x/rust/pull/new/fix-74081 . Should send a PR?

Reopening: rustfmt still appears to be broken

The original cause for this issue was #74236 which AIUI was indeed resolve by #74240 (and thus #74080 as well as rls was broken since it has rustfmt in its dep tree). However, a separate issue relative to the rustc-ap crates in rustfmt's dep tree popped up the same day #74240 was merged so we didn't discover the other issue til the next day and the bot didn't open a new issue.

We're on the last leg of updating the rustc-ap crates to fix that alternative issue, but just wanted to clarify the current broken toolstate is indeed a separate issue from the one discussed in this thread.

Thanks for working on that and for clarifying! I figured there was probably a secondary issue here.

I guess the toolstate site only sees nightlies so that's why it thinks it's been red since the 5th and never opened a new issue 馃

Don't think the close keyword from #74760 applied here, but would be good to get this closed too :+1:

Was this page helpful?
0 / 5 - 0 ratings