1337153 - Require rust 1.15

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

Then we can throw syntex in the trash \o/

Comment 1

[Ralph Giles (:rillian)]

Attachment: Bug 1337153 - Require rust 1.15.1.

Bump the minimum version of the rust toolchain we require to
build. The 1.15 release includes support for custom #[derive]
directives, letting us use the serde serialization crate without
checking in a lot of generated code.

This is primarily motivated by webrender and the audio remoting
work, and lets us drop the heavy syntex dependency.

Review commit: https://reviewboard.mozilla.org/r/111372/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/111372/

Comment 2

[(no longer active)]

Comment on attachment 8835749 [details]
Bug 1337153 - Require rust 1.15.1.

https://reviewboard.mozilla.org/r/111372/#review112888

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6a97271a798e
Require rust 1.15.1. r=Ehsan

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/6a97271a798e

Comment 5

[Landry Breuil (:gaston)]

Okay, i'm again the guy who's going to rant but.... you seriously thought it was a good idea to have a hard-requirement on the very latest version of rust two days or so after its release ? 

Reminder: some people are trying to build the trunk on their own CI, and on those poor Tier 3 architectures, some can't update to the very latest rust right away, because it's a volunteer task, we struggle to get rust working on our OS, we have no support for rustup, i have to wait for the rust maintainer to find time to update it on my OS, etc, etc.

So i'm struggling to have my buildbot green, and suddenly everything turns red (http://buildbot.rhaalovely.net/builders/mozilla-central-amd64/builds/1993) because *now* we need rust 1.15.1. Now, If ppl throw more shitty code in the tree breaking further Tier 3 archs in the meantime, those failures will stay 'hidden' until i get to update to the very latest rust, and then kittens die.

Please, think of the kittens. At some point, they might just give up running ahead of the domo-kun.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Sorry, about this. Rust 1.15 (w/ custom derive) is a pretty important release because of the new functionality it exposes so I was eager to be able to depend on it.

Is there something that can be done to help OpenBSD have current Rust releases? I see that OpenBSD is currently a Rust Tier 3 platform instead of a Tier 2 one. Do you know what's preventing it from being Tier 2?

Anyways, good luck and thanks for the work you do.

Comment 7

[Landry Breuil (:gaston)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #6)
> 
> Is there something that can be done to help OpenBSD have current Rust
> releases? I see that OpenBSD is currently a Rust Tier 3 platform instead of
> a Tier 2 one. Do you know what's preventing it from being Tier 2?

I don't work on rust on OpenBSD, i have enough on my plate with mozilla alone.. The rust maintainer (semarie at openbsd.org) told me that with 1.15 he was having issues with the bundled LLVM which had a huge performance impact and way longer build times.. as for being a Tier 2, i guess that's also volunteer time. We all try to have lives :)

Comment 8

[Sebastien Marie [:semarie]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #6)
> Is there something that can be done to help OpenBSD have current Rust
> releases? I see that OpenBSD is currently a Rust Tier 3 platform instead of
> a Tier 2 one. Do you know what's preventing it from being Tier 2?

In order to be Rust Tier 2, we would have to provide a Linux crossbuild environment targeting OpenBSD. It isn't a trivial task for now. I expect it to be possible in mid-term, as we imported LLVM in base some time ago.

Additionally, it doesn't solve all problems: rustup is a binary distribution. At OpenBSD, system libraries has proper and strict versioning schema (see http://marc.info/?l=openbsd-ports&m=147126367728933 for some rationale). A crossbuild environment would targeting one particular OpenBSD version but development occurs in -current which is a moving target regarding libraries versions. So it could resulting rustup to provide unusable binaries (due to version mismatch on libraries).

Comment 9

[Nathan Froyd [:froydnj]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #6)
> Sorry, about this. Rust 1.15 (w/ custom derive) is a pretty important
> release because of the new functionality it exposes so I was eager to be
> able to depend on it.

Depend on it for WebRender, or something else?  If it's just for the former, maybe we could just make the WR builds use Rust 1.15 (or whatever version), rather than requiring standard m-c builds to use the latest and greatest.  That probably gets a bit tricky with vendoring code, since vendored code is less likely to care about older Rust versions, but maybe with careful specifications in Cargo.tomls, we could get around that?

Comment 10

[Simon Sapin (:SimonSapin)]

> Depend on it for WebRender, or something else?

WebRender and Stylo, at least. And possibly more Rust code in Gecko will start using this new feature too, if try servers lets it.

Comment 11

[Nathan Froyd [:froydnj]]

(In reply to Simon Sapin (:SimonSapin) from comment #10)
> > Depend on it for WebRender, or something else?
> 
> WebRender and Stylo, at least. And possibly more Rust code in Gecko will
> start using this new feature too, if try servers lets it.

The point still stands: neither one of these things are shipping features (yet), so it seems peculiar to force the rest of the tree to upgrade.  An upgrade will have to come, of course, but we can do that in due course.

Comment 12

[Landry Breuil (:gaston)]

And given bug #1339033, it would be nice to wait a bit before making stylo/rust components mandatory options for all targets. I get it that mozilla wants to move fast, but maintained tier3 architectures are always the first to break in those cases....

Comment 13

[(no longer active)]

(In reply to Nathan Froyd [:froydnj] from comment #11)
> (In reply to Simon Sapin (:SimonSapin) from comment #10)
> > > Depend on it for WebRender, or something else?
> > 
> > WebRender and Stylo, at least. And possibly more Rust code in Gecko will
> > start using this new feature too, if try servers lets it.
> 
> The point still stands: neither one of these things are shipping features
> (yet), so it seems peculiar to force the rest of the tree to upgrade.  An
> upgrade will have to come, of course, but we can do that in due course.

If it's possible to keep the dependencies on 1.15 outside of m-c (or hidden behind a build time flag or some such) then this sounds like a good idea for downstream ports.

I do expect us to run into some growing pain around rust usage and ports such as OpenBSD for a while, so a second best option would be a patch that disables the code relying on the new rust features for OpenBSD that allows the downstream builds to keep working during the transition period.

Comment 14

[Simon Sapin (:SimonSapin)]

(In reply to :Ehsan Akhgari from comment #13)
> a patch that disables the code relying on the new rust features


I think that’s --disable-rust? My understanding is that it was removed earlier than strictly necessary to nudge people to report (and hopefully start fixing) issues like this instead of simply using --disable-rust and moving on, only to panic when it’s too late.

Currently it may be possible to locally revert the patch that removed --disable-rust. Though of course at some point we’ll start shipping some non-optional Rust code and that won’t be possible anymore.

Comment 15

[Jeff Muizelaar [:jrmuizel]]

(In reply to Nathan Froyd [:froydnj] from comment #9)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #6)
> > Sorry, about this. Rust 1.15 (w/ custom derive) is a pretty important
> > release because of the new functionality it exposes so I was eager to be
> > able to depend on it.
> 
> Depend on it for WebRender, or something else? 

For WebRender.

Comment 16

[(no longer active)]

(In reply to Simon Sapin (:SimonSapin) from comment #14)
> (In reply to :Ehsan Akhgari from comment #13)
> > a patch that disables the code relying on the new rust features
> 
> 
> I think that’s --disable-rust?

I meant the WebRender code Jeff is mentioning, not all rust coe.

Comment 17

[Simon Sapin (:SimonSapin)]

(In reply to :Ehsan Akhgari from comment #16)
> (In reply to Simon Sapin (:SimonSapin) from comment #14)
> > (In reply to :Ehsan Akhgari from comment #13)
> > > a patch that disables the code relying on the new rust features
> > 
> > 
> > I think that’s --disable-rust?
> 
> I meant the WebRender code Jeff is mentioning, not all rust coe.

If Rust is at version 1.15 on both developers' machines and CI, any Rust code might start using features introduced in 1.15 and not even notice. So the only way to reliable not require Rust 1.15 (or whatever version CI uses at the moment) is to not require Rust.

If we do want to make a commitment to support some configuration that can use some older version of Rust, we need to have CI for it.