Rust 1.33 stable fails to compile itself

[thomasjfox]

Compiling Rust 1.33 with Rust 1.32 on Fedora 29 was fine.
When using the newly created 1.33 compiler to compile Rust 1.33 again, it fails:

..
Generating unstable book md files (i686-unknown-linux-gnu)
Building stage0 tool unstable-book-gen (i686-unknown-linux-gnu)
   Compiling proc-macro2 v0.4.24
   Compiling unicode-xid v0.1.0
   Compiling serde v1.0.82
   Compiling ryu v0.2.7
   Compiling itoa v0.4.3
   Compiling num-traits v0.2.6
   Compiling quote v0.6.10
   Compiling syn v0.15.22
   Compiling serde_json v1.0.33
   Compiling serde_derive v1.0.81
   Compiling tidy v0.1.0 (/datastore/rpmbuild/BUILD/rustc-1.33.0-src/src/tools/tidy)
error: use of deprecated item 'core::str::<impl str>::trim_left_matches': superseded by `trim_start_matches`
   --> src/tools/tidy/src/features.rs:191:61
    |
191 |             let level = match parts.next().map(|l| l.trim().trim_left_matches('(')) {
    |                                                             ^^^^^^^^^^^^^^^^^
    |
    = note: `-D deprecated` implied by `-D warnings`

error: aborting due to previous error

error: Could not compile `tidy`.

The code in question has been fixed by
b7f030e#diff-e7f0adcf2688b6a55b1f70d117ed7e17
but I don't know why that fix never made it into the official 1.33 release.

Related issue: #57262

[cuviper]

#57990 backported the fixes in src/bootstrap, but missed those in linkchecker and tidy.

[Mark-Simulacrum]

I'm going to close this -- we don't currently guarantee that the stable compiler can fully bootstrap itself as-is. If this is a significant problem for distros a heads up before the release (i.e., on the beta branch) would be appreciated -- we can fix this much easier there.

(I've also tagged as stable-nominated/accepted so that if there's a point release we can sneak the relevant patch in).

[cuviper]

FWIW, here's the extra patch I've added to Fedora:
https://src.fedoraproject.org/rpms/rust/blob/f712684d1b1a4cb46dc963a049920981afc3c9ea/f/0001-Backport-deprecation-fixes-from-commit-b7f030e.patch

[joshtriplett]

@Mark-Simulacrum This is a problem for distributions, which may well want to build a new release of the compiler package with the previous version of the compiler package (e.g. 1.33-distro2 with 1.33-distro1).

What would it take for us to get appropriate CI in place that ensures that stable compilers build with themselves?

This doesn't make a great first impression for someone trying to build their own copy of rustc.

cc @fenrus75

[Mark-Simulacrum]

Building your own copy of rustc should not be a problem - we download appropriate beta compilers.

The problem is not - currently - CI, it's rather that we have no real way of supporting different bootstrap compilers. However, we've discussed that we should implement and enforce a policy that no crate should be using unstable things from the bootstrap compiler, which should fix this more permanently; I'm not sure how much work that'll be and don't currently have the bandwidth to investigate.

[cuviper]

Maybe we could add something like dist-check to CI, using the just-built compiler as a new stage0? It wouldn't need a full build, just enough to see that it basically works, like ./x.py build --stage 0 for the compiler, and then build tools like compiletest that always use stage0.

[Mark-Simulacrum]

We already have a dist check builder that could do this (and perhaps should); it currently doesn't change the bootstrap compiler I guess?

[cuviper]

Right, I think the current dist check is about making sure the rustc-src tarball is complete. It still downloads stage0 etc. A "rebuild check" would use the local rustc to bootstrap, and it could also share the LLVM build to save time and space.

[joshtriplett]

@Mark-Simulacrum

Building your own copy of rustc should not be a problem - we download appropriate beta compilers.

Not on any system with a policy of "no network access during builds" you don't. :)

Distros will build rustc using the previous package of rustc, and that might be version N-1 or it might be version N.

@cuviper Sounds reasonable to me.

[Mark-Simulacrum]

Not on any system with a policy of "no network access during builds" you don't. :)

Maybe I misunderstood - I specifically meant the use case of downloading a source tarball and building. I fully agree that distros want the support for self-building (and that if we can take relatively easy steps to provide it for them, we should).

[fenrus75]

as a distro, we cache the tarbals on a local server, and when the actual package builds, the system that builds (well the vm/container) does not have network access outside the local mirror of the tarbal... we'll start the bootstrap with the system rustc... which after the first build is the same version as the tarbal ... not being able to build yourself is... quaint.

…

On Mon, Apr 8, 2019 at 6:43 PM Mark Rousskov ***@***.***> wrote: Not on any system with a policy of "no network access during builds" you don't. :) Maybe I misunderstood - I specifically meant the use case of downloading a source tarball and building. I fully agree that distros want the support for self-building (and that if we can take relatively easy steps to provide it for them, we should). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#58845 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPeFZGDieKD7KA2XdsrA1OHx-iypb74ks5ve_BOgaJpZM4bZLEn> .