rust 1.28.0 build fails - test failure

[daym]

The Rust 1.28.0 build fails in the Guix distribution. We are using quite similar build processes (using ./x.py) for each of the Rust versions, and the versions 1.23.0, 1.24.1, 1.25.0, 1.26.2, 1.27.0, 1.27.2 work fine with it, but Rust 1.28.0 fails while testing (right after rustdoc).

The build process is:

$ export CFG_DISABLE_CROSS_TESTS="1"
$ export SHELL=$(which "sh")
$ export CONFIG_SHELL=$(which "sh")
$ export CC=/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/gcc
$ export LLVM_LINK_SHARED="1"
$ ./x.py build
$ ./x.py build src/tools/cargo
$ ./x.py -j1 test -vv  # fails here
$ ./x.py -j1 test src/tools/cargo 

(See also https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/rust.scm )

Our config.toml is:

[llvm]
[build]
cargo = "/gnu/store/kwpdxgwh6ki13gikhbb4rhxrr36fzcij-rust-1.27.2-cargo/bin/cargo"
rustc = "/gnu/store/nzk7g7l7hizg4p3kp239x9acg939d18f-rust-1.27.2/bin/rustc"
docs = true
python = "/gnu/store/axfhalb1syyhayn6j873z4l8s5d68i3v-python2-2.7.14/bin/python2"
gdb = "/gnu/store/vmfyql60lbji2ca50r2xd3sq1m41qrrl-gdb-8.2/bin/gdb"
vendor = true
submodules = false
[install]
prefix = "/gnu/store/k0432vkqdxxbv7p4swvgc2b8wds0akmg-rust-1.28.0"
docdir = "/gnu/store/p15l3xash8fymraf8gkdwdwajlk495q8-rust-1.28.0-doc/share/doc/rust"
sysconfdir = "etc"
localstatedir = "var/lib"
[rust]
default-linker = "/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/gcc"
channel = "stable"
rpath = true

[target.x86_64-unknown-linux-gnu]
llvm-config = "/gnu/store/pfs7b46rav4mrrayzccwpipmqxa38p1i-llvm-6.0.1/bin/llvm-config"
cc = "/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/gcc"
cxx = "/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/g++"
ar = "/gnu/store/srmqh29dpm50j8kj1pbqg2rgh053wgyp-binutils-2.30/bin/ar"
jemalloc = "/gnu/store/rrzbl659j0vzxvp5ilc1zm601f0pf46j-jemalloc-4.5.0/lib/libjemalloc_pic.a"
[dist]

[daym]

I've got extensive log files (15 MiB). If you want, I can put them up somewhere.

The last few lines of the failed build are:

$ ./x.py -j1 test
...
rustdoc: [theme-checker] Starting tests!
 - Checking "/tmp/guix-build-rust-1.28.0.drv-0/rustc-1.28.0-src/src/librustdoc/h
tml/static/themes/dark.css"... OK
< RustdocTheme { compiler: Compiler { stage: 2, host: "x86_64-unknown-linux-gnu"
 } }
> Bootstrap
running: "/gnu/store/vkh0akdppdj1ddqwprx0czm6i8p158xx-rust-1.27.0-cargo/bin/carg
o" "test" "--" "--test-threads=1"
   Compiling difference v2.0.0
   Compiling ansi_term v0.11.0
   Compiling pretty_assertions v0.5.1
   Compiling bootstrap v0.0.0 (file:///tmp/guix-build-rust-1.28.0.drv-0/rustc-1.
28.0-src/src/bootstrap)
    Finished dev [unoptimized] target(s) in 32.37s
     Running /tmp/guix-build-rust-1.28.0.drv-0/rustc-1.28.0-src/build/bootstrap/
debug/deps/bootstrap-8fbbec03a03ae676

running 9 tests
test builder::__test::build_default ... error: test failed, to rerun pass '--lib
'
command did not execute successfully: "/gnu/store/vkh0akdppdj1ddqwprx0czm6i8p158xx-rust-1.27.0-cargo/bin/cargo" "test" "--" "--test-threads=1"
expected success, got: exit code: 1

Traceback (most recent call last):
  File "./x.py", line 20, in <module>
    bootstrap.main()
...

I'm not sure why it's trying to bootstrap that late in the build - it didn't do that in 1.27.2.

This problem is reproducible every time.

Note that we install files ourselves - which means we only install the files "rustc", "cargo" and "rustdoc" for each package. Could that be a problem?

[daym]

In order to isolate the problem, I tried to run "/gnu/store/vkh0akdppdj1ddqwprx0czm6i8p158xx-rust-1.27.0-cargo/bin/cargo" "test" "--" "--test-threads=1" myself - but apparently I'm missing lots of environment variables whose values I do not know.

[ipetkov]

@daym you might be missing the RUSTC_BOOTSTRAP=1 environment variable (which gets set somewhere by the build system). This should get past any errors about using unstable features.

Is the build issue with 1.28 still relevant, given that we've already bootstrapped later rustc version within Guix?

[daym]

Nikolai Merinov backported a patch from #51977 in order to work around the problem. It's very much still present in the original 1.28.0 release otherwise.

For the sake of others I respectfully suggest you to release 1.28.1 with just the patch above applied.

[jyn514]

I'm going to close this, we're not going to backport patches to 1.28 at this late date.