1314709 - Require Rust 1.12

Status: RESOLVED DUPLICATE of bug 1321696

(Firefox Build System :: General, defect)

Description

[(not currently active) Ted Mielczarek]

Rust 1.12 was the first release to ship with a Cargo that supports source replacement as well as workspaces.

We're using source replacement for our vendored dependencies, but since we don't require Rust 1.12 that means that anyone using an older toolchain will have their build hit the network (bug 1314477). This isn't great, but they can also just update their toolchain to have things work as intended.

We'd also like to use a cargo workspace (bug 1302704) so that we don't build a bunch of crates multiple times. We will need to require a newer Rust in order to do this, since trying to build a workspace with an older cargo will produce weird results (mostly writing lockfiles in the wrong place).

Comment 1

[Mike Hommey [:glandium]]

All you're describing are requirements for cargo, not rustc. So the version check should be on cargo, not rustc, and cargo has its own version number.

Comment 2

[Simon Sapin (:SimonSapin)]

Cargo can be obtained separately from rustc, but they’re typically distributed together so their version numbers are somewhat tied.

Also, Servo’s CI currently uses 1.12 to build Stylo: https://github.com/servo/servo/blob/master/rust-stable-version
As far as I know it doesn’t yet use features introduced in 1.12, but it’s probably a matter of time until it does. If we want to keep supporting 1.11 or older, CI should match that. (But I’d rather require the more recent version.)

Comment 3

[(not currently active) Ted Mielczarek]

(In reply to Mike Hommey [:glandium] from comment #1)
> All you're describing are requirements for cargo, not rustc. So the version
> check should be on cargo, not rustc, and cargo has its own version number.

Right, but as Simon says, they're shipped together. Cargo's version number is always 0.X where X is the Rust minor version number + 1.

Comment 4

[Mike Hommey [:glandium]]

Well, the current cargo package in Debian is version 0.11, while rustc is 1.12. They're both built from separate sources.

Comment 5

[Nathan Froyd [:froydnj]]

Attachment: require Rust 1.12 to build with --enable-rust

glandium's point about Cargo and Rust being separate things is well taken, but
1.12 matches Stylo, as Simon notes, and I think most people will obtain Cargo
and Rust together anyway.

Comment 6

[Simon Sapin (:SimonSapin)]

More generally (perhaps this should be another bug?), how frequently are willing to require a new Rust version? 1.13 was just released, and include new things like the `?` operator that would be nice to use. (Though at this point nothing critical.)

Comment 7

[Mike Hommey [:glandium]]

(In reply to Simon Sapin (:SimonSapin) from comment #6)
> More generally (perhaps this should be another bug?), how frequently are
> willing to require a new Rust version? 1.13 was just released, and include
> new things like the `?` operator that would be nice to use. (Though at this
> point nothing critical.)

As mentioned in the bug that wants to update to 1.13, 1.13 can't be used on android. So even if we switch to 1.13 now for non-android, we can't use `?`.

Comment 8

[Mike Hommey [:glandium]]

Also, requiring a new rust version when it's not available through non-rust-upstream channels (think distros, homebrew, etc.) is not really the best timing.

Comment 9

[Mike Hommey [:glandium]]

(In reply to Nathan Froyd [:froydnj] from comment #5)
> Created attachment 8808731 [details] [diff] [review]
> require Rust 1.12 to build with --enable-rust
> 
> glandium's point about Cargo and Rust being separate things is well taken,
> but
> 1.12 matches Stylo, as Simon notes, and I think most people will obtain Cargo
> and Rust together anyway.

I, for one, don't. And my current cargo is 0.11 (don't ask me why 0.12 is not in Debian unstable, I don't know). If the build starts requiring 0.12 while assuming checking the rustc version is enough, well, that'd just break the build for me.

Comment 10

[Mike Hommey [:glandium]]

Not that it's totally bad that the build be broken with cargo 0.11. But that it's broken after having actually spent time building stuff instead of during configure is not nice.

Comment 11

[(not currently active) Ted Mielczarek]

We should explicitly require cargo >= 0.13 and rustc >= 1.12 for this, since we're mostly requiring cargo features but most people will get rustc+cargo as one unit and we'll inevitably break older versions anyway.

Comment 12

[Simon Sapin (:SimonSapin)]

(In reply to Mike Hommey [:glandium] from comment #7)
> (In reply to Simon Sapin (:SimonSapin) from comment #6)
> > More generally (perhaps this should be another bug?), how frequently are
> > willing to require a new Rust version? 1.13 was just released, and include
> > new things like the `?` operator that would be nice to use. (Though at this
> > point nothing critical.)
> 
> As mentioned in the bug that wants to update to 1.13, 1.13 can't be used on
> android. So even if we switch to 1.13 now for non-android, we can't use `?`.

Ok. Though I meant this question more generally, with `?` as just an example. Suppose for another example that Rust 1.18 is released some time next year with associated type constructors. How much do we want to wait until requiring it? As soon as it’s stable/released upstream, when it’s packaged in some set of distributions, some other criteria?

Comment 13

[Nathan Froyd [:froydnj]]

We're going to need 1.13 for bug 1316696 anyway.

Do we need to care about the version required before Firefox actually starts requiring Rust to build?

Comment 14

[(not currently active) Ted Mielczarek]

Only inasmuch as we want to not make the lives of existing developers harder. We should definitely figure out a workable policy for the future, since this problem isn't going to go away.

Comment 15

[Nathan Froyd [:froydnj]]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #14)
> Only inasmuch as we want to not make the lives of existing developers
> harder. We should definitely figure out a workable policy for the future,
> since this problem isn't going to go away.

My sense is that existing developers who are depending on --enable-rust are staying on the bleeding edge of Rust development anyway, so requiring the latest versions isn't a problem for them.  I don't know how many people are just incidentally using --enable-rust for their builds, which is where we'd irritate the most people right now.  And of course the equation changes when we start requiring Rust by default.

Comment 16

[(not currently active) Ted Mielczarek]

Comment on attachment 8808731 [details] [diff] [review]
require Rust 1.12 to build with --enable-rust

Review of attachment 8808731 [details] [diff] [review]:
-----------------------------------------------------------------

This is good, but I think adding a version check for cargo wouldn't hurt, and would at least give a useful error in configure for people in glandium's situation (which sounds like it's "everybody using Debian's Rust packages".

Comment 17

[Mike Hommey [:glandium]]

FWIW, Fedora also has different versions of cargo and rust presently, although in a more advantageous way than on Debian (they have cargo 0.14 and rust 1.13). It also means users can update one without updating the other and end up in similar situations as I am.

Comment 18

[Xidorn Quan [:xidorn] UTC+11]

Given now we have been requiring Rust 1.13 (bug 1321696), this bug can be closed.