Release 1.13.1 with arm code generation fix

[rillian]

I'd like to propose doing a stable point release to fix issue #37630.

The release notes for 1.13.0 say this didn't block release because arm is a tier-2 platform. However, armv7-android is tier-1 for gecko, so I've blocked updating gecko's build requirements on this.

Having an updated stable release would really help us out with Firefox. We're anxious to move to 1.13 for all of no-inline drop flags, the ? operator, and faster build times.

[steveklabnik]

/cc @rust-lang/core

[brson]

I think it is reasonable to do a 1.13.1, but it's fairly high effort.

@rillian since Gecko doesn't have a hard requirement to use Rust for the build, you could have gecko use the 1.14 betas for the next 5 weeks. Why is that undesirable?

[alexcrichton]

Note that #37691 (which I believe is the fix @rillian wants) has not been backported to beta yet, but I will do so right now.

[rillian]

Starting with Firefox 52 (currently on alpha/Aurora/Dev-Edition) we're using Rust code for official builds on all of Gecko's tier-1 platforms, including arm-android. I also hope to require rust by default for individual developer builds in the next few weeks.

I'm unclear how serious #37630 is; I can actually build Firefox for android with 1.13.0, but haven't run tests. I figured it if was important enough to mention in the release notes, we should probably avoid it for Firefox nightly.

@brson We in fact plan to move Firefox nightly to the 1.14 beta to test the std debuginfo with our crash reporting, but that is riskier, and as Alex mentioned, the fix isn't available in 1.14 beta yet, so I asked for this in parallel as a safer fallback. Requiring a beta is also extra hassle for every Gecko developer doing their own build targeting arm.

[alexcrichton]

A new beta is now being built, so with any luck tomorrow morning we'll have a fresh beta for you to test out as well.

Out of curiosity, where do most Gecko developers get the Rust toolchain from? If it's from rustup then in theory it's quite easy to switch to beta, but if it's through other solutions it may not be so easy.

[rillian]

I don't really know. We recommend rustup.rs, but I've heard people mention homebrew, or running the installer linked from rust-lang.org.

Still, we try to keep things as simple as possible, so people don't have to know the details until they they want to.

[brson]

Thanks for the clarifications @rillian

We need to decide soon if we are going to do this. The next few weeks are going to be difficult to chain much work together.

cc @rust-lang/core @rust-lang/compiler we need to decide whether we are going to do 1.13.1 to fix arm code generation #37630. @rillian wants it for Firefox, though it seems like they may be able to get by without it because they have reasons for wanting unrelated fixes in 1.14. I think we would expect to require at least 3 days to get a release out, and some more cleanup post-release.

Even though I'm reluctant to do yet another release right now, I'm leaning toward it since it's a bad bug and fixing it demonstrates that we care.

[alexcrichton]

If using beta is unacceptable for Gecko, then I'm in favor of a point release for 1.13.1

[aturon]

I think my preference is to hold off on a 1.13.1 unless the beta is unworkable for Gecko, given the work involved.

Separately, given the importance of arm-android for Gecko, we should discuss what it would take to make that a tier 1 platform for Rust as well (which is of course desirable for other reasons).

[rillian]

I raised the tier-1 issue in rust-lang/rfcs#1795.

[rillian]

My patch to build Firefox for Android with 1.14.0-beta.2 was accepted so the immediate blocker for Firefox is resolved.

There's still the issue of bad code generation on local developer builds, which could be an unpleasant surprise. Ultimately that comes down the difference in support levels between Rust and Firefox for arm.

If the issue is only with floating point intrinsics, we might be ok anyway; I don't believe we have any floating-point Rust code in Firefox at the moment. I'm wary of the race between that and the release of 1.14 stable. I'll try adding a configure warning to our code in the meantime.

[rillian]

This particular issue was resolved for us by the release of 1.14.0 stable.