Edition 2018 programs not compiling

[andradei]

When running cargo build | check inside a container based with this image, the crates get downloaded but don't compile. This is the error I get:

    (Omitting big list of crates being downloaded and checked)

    Checking trust-dns-resolver v0.10.0
    Checking actix v0.7.8
    Checking hyper-tls v0.3.1
    Checking reqwest v0.9.5
    Checking actix-net v0.2.4
    Checking sparkpost v0.4.1
    Checking actix-web v0.7.15
    Checking simple-auth-server v0.1.0 (/app)
error: Edition 2018 is unstable and only available for nightly builds of rustc.

error: Could not compile `my-rust-program`.

To learn more, run the command again with --verbose.

[andradei]

rustup is on version 1.15.0 inside the container.
The latest version is 1.16.0 which has the newest toolchains for Edition 2018.

[andradei]

The work-around I found is to run the following in the container or put it in my Dockerfile:

    rustup self update \
    && rustup toolchain uninstall stable \
    && rustup toolchain install stable \
    && rustup default stable

[sfackler]

Are you sure you're using the 1.31 image?

[sfackler]

It seems to behave as expected to me:

$ docker run -it --rm rust:1.31.0
Unable to find image 'rust:1.31.0' locally
Trying to pull repository docker.io/library/rust ... 
sha256:38e8d968efca2d041933ad22ff4d9587378cc82a37c30772f483a70d37ec2a3d: Pulling from docker.io/library/rust
54f7e8ac135a: Pull complete 
d6341e30912f: Pull complete 
087a57faf949: Pull complete 
5d71636fb824: Pull complete 
0c1db9598990: Pull complete 
734ee16af2dd: Pull complete 
Digest: sha256:38e8d968efca2d041933ad22ff4d9587378cc82a37c30772f483a70d37ec2a3d
Status: Downloaded newer image for docker.io/rust:1.31.0
root@afba971466a8:/# USER=root cargo new --edition 2018 foo
     Created binary (application) `foo` package
root@afba971466a8:/# cd foo
root@afba971466a8:/foo# cat Cargo.toml
[package]
name = "foo"
version = "0.1.0"
authors = ["root"]
edition = "2018"

[dependencies]
root@afba971466a8:/foo# cargo build
   Compiling foo v0.1.0 (/foo)                                                                                                                                          
    Finished dev [unoptimized + debuginfo] target(s) in 0.25s                                                                                                           
root@afba971466a8:/foo# rustc --version
rustc 1.31.0 (abe02cefd 2018-12-04)

[andradei]

Are you sure you're using the 1.31 image?

Yes. But I'll remove the image and pull it again just to be sure.

Have you checked the rustup version? There was a bug in the toolchain of the newest version that was fixed after 1.31.0 was released.

[sfackler]

The version of rustc on the 1.31.0 image is 1.31.0.

[andradei]

Let me highlight that I am talking about rustup, not rustc.

The latest versions are:

• rustup 1.16.0
• rustc 1.31.0

Image 1.31.0 has rustc 1.31.0 indeed. But it isn't running rustup 1.15.0, which probably has the older toolchain.

Maybe that isn't the problem, but given that it was reported rustup 1.16.0 fixed a toolchain issue on rust 1.31.0, it would be good the rebuild this image with rustup 1.16.0.

[sfackler]

That is not the problem.

[jthelin]

If rustup v1.16.0 is needed for 2018 code, then the problem is in the Dockerfile, which is still using v1.15.0 of rustup-init

docker-rust/1.31.0/stretch/Dockerfile

Line 17 in e7703b2

url="https://static.rust-lang.org/rustup/archive/1.15.0/${rustArch}/rustup-init"; \

$ docker run --rm -it rust:latest bash -c "rustc --version ; cargo --version ; rustup --version"
rustc 1.31.0 (abe02cefd 2018-12-04)
cargo 1.31.0 (339d9f9c8 2018-11-16)
rustup 1.15.0 (f0a3d9a84 2018-11-27)

[sfackler]

Rustup 1.16.0 is not needed for 2018 code.

[andradei]

@sfackler You're right. The issue might have been just timing. Unfortunately, I can't find where I read the toolchain had to be updated shortly after Rust 2018 was released in order for this problem to go away.

I wrongly assumed rustup 1.15.0 was the problem, but 1.16.0 didn't change any of its behavior. Sorry about that.

So the problem was outside this image.