Closed Bug 1337153 Opened 3 years ago Closed 3 years ago

Require rust 1.15

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(firefox54 fixed)

RESOLVED FIXED
mozilla54
Tracking Status
firefox54 --- fixed

People

(Reporter: jrmuizel, Assigned: rillian)

References

Details

Attachments

(1 file)

Then we can throw syntex in the trash \o/
Depends on: 1336155
Depends on: 1338311
Assignee: nobody → giles
Comment on attachment 8835749 [details]
Bug 1337153 - Require rust 1.15.1.

https://reviewboard.mozilla.org/r/111372/#review112888
Attachment #8835749 - Flags: review?(ehsan) → review+
https://hg.mozilla.org/mozilla-central/rev/6a97271a798e
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
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.
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.
(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 :)
(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).
(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?
Flags: needinfo?(jmuizelaar)
> 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.
(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.
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....
(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.
(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.
(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.
Flags: needinfo?(jmuizelaar)
(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.
(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.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.