Rust 1.19 release status

brson · July 8, 2017, 1:58am

Hi there.

I’ve done a round of triage on the status of the 1.19 release, going out on 7/20, and it’s a bit shaky. This cycle was interrupted by the Mozilla all hands, which caused us to skip a release triage session that we did not make up. I’ve also personally been engaged in matters unrelated to release management. There are some big bugs open.

There are 4 open regressions.

The HashSet codegen bug and typechecking bug are expected to be fixed in the next beta, which is being merged presently.

The other two regressions are kind of alarming:

https://github.com/rust-lang/rust/issues/42719

This one is due to a bad interaction between the RLS submodule and vendoring and means that downstream packagers can’t build Rust as expected. I’m pretty uncomfortable about this as those packagers are an important kind of customer, and we break stuff for them pretty often.

https://github.com/rust-lang/rust/issues/42635

This one is due to an interaction with cargo’s new job server support and nmake. It looks to me like the impact of this is quite large, as I have run into this issue, not understanding what it was, many times recently, and each time had to update lockfiles for sys crates to new revisions. In effect I think it is pretty close to breaking Rust on Windows. If it lands it may not go over well and require a sizable mea culpa.

There is also a milestone issue open to disable the RLS packaging in 1.19. It looks like that has been done in a patch on beta, but not sure. We should try to remember to check these installers. I don’t know that RLS is going to be released in 1.20 either, so we may end up needing to remember to do that same disabling again.

There is one final backport PR to land. This backport includes the library stabilizations, which are landing later and later in the cycle. There’s also a pending PR to rename and change the API of RangeArgument, which is slated for stabilization in 1.19. This is pretty uncomfortable so close to release.

Here are the 1.19 release notes. On the plus side, there’s a lot of nice things in this release. On the negative side there are a lot of compatibility notes, and some more noted on thread that haven’t been added to the notes yet.

leonardo · July 8, 2017, 7:15am

Floating point constants in match patterns is now a hard error This was previously a warning.

Isn't it a better idea to make it a hard error only after this issue is solved in some good way?

github.com/rust-lang/rust

Pattern guard problem replacing FP literal pattern

opened 08:53PM - 14 Jun 17 UTC

closed 05:26PM - 18 May 21 UTC

leonardo-m

I-needs-decision T-lang T-compiler C-feature-request

This is an Rust language ergonomy problem regarding pattern matching that contai…ns floating point values. This is a reduction of code that was OK: ``` #![feature(box_patterns, box_syntax)] #![allow(illegal_floating_point_literal_pattern)] #![allow(dead_code)] enum Exp { Const(f64), Sum(Box<Exp>, Box<Exp>) } fn simplify(e: Exp) -> Exp { use Exp::*; match e { Sum(box Const(0.0), box x) | Sum(box x, box Const(0.0)) => simplify(x), Sum(box Const(l), box Const(r)) => Const(l + r), _ => e, } } fn main() {} ``` Those FP patterns will go away, so I've tried to replace them like this: ``` #![feature(box_patterns, box_syntax)] #![allow(dead_code)] enum Exp { Const(f64), Sum(Box<Exp>, Box<Exp>) } fn simplify(e: Exp) -> Exp { use Exp::*; match e { Sum(box Const(z), box x) | Sum(box x, box Const(z)) if z == 0.0 => simplify(x), Sum(box Const(l), box Const(r)) => Const(l + r), _ => e, } } fn main() {} ``` But I get errors: ``` error[E0008]: cannot bind by-move into a pattern guard --> ...\test.rs:12:31 | 12 | Sum(box Const(z), box x) | Sum(box x, box Const(z)) | ^ moves value into pattern guard error[E0008]: cannot bind by-move into a pattern guard --> ...\test.rs:12:44 | 12 | Sum(box Const(z), box x) | Sum(box x, box Const(z)) | ^ moves value into pattern guard ``` The pattern guard is "if z == 0.0" it uses just z and a FP contanst, it doesn't touch the x value. I'd like ergonomy improvements to solve this problem in some nice way at language level (or Prelude level). See also the short thread: https://users.rust-lang.org/t/pattern-guard-problem-replacing-fp-literal-pattern/11207

The link to ops::RangeArgument seems broken.

LilianMoraru · July 8, 2017, 5:54pm

@brson https://github.com/rust-lang/rust/pull/42328 does not seem to have landed(was not backported to Beta) like the notes say: https://github.com/rust-lang/rust/pull/42503/files#diff-5cafcf46bfb947f8e58fa5c16d39018cR13

BatmanAoD · July 8, 2017, 6:58pm

Is there a set of criteria for determining when it’s better to delay the release than release it with regressions?

petrochenkov · July 8, 2017, 8:15pm

You are talking about different issue - floating point literals in patterns - Tracking issue for `illegal_floating_point_literal_pattern` compatibility lint · Issue #41620 · rust-lang/rust · GitHub, it's still a warning.

steveklabnik · July 9, 2017, 5:13pm

The only time we've ever changed a release time was when we moved from Fridays to Thursdays. Generally if there's regressions they just end up shipping. We try to never get to that point in the first place.

BatmanAoD · July 11, 2017, 10:37pm

I completely agree that it would be best not to get to the point of needing to delay a release! That said, since Rust is still young enough (at least as far as I can tell) that compatibility/stability missteps could have pretty drastic consequences for adoption and public image, I think it might be a good idea not to push releases out that are known to break large chunks of the ecosystem.

From a comment by @brson on one of the above-linked issues:

If this one isn't fixed it will need a compat note: #42635

That one I think is particularly alarming. It's basically breaking every project of significant size on Windows.

This is going to be a breaky release....

I feel bad showing up and complaining like this, because I really have not made any real contributions to the community yet, so I'm only pointing out a potential problem that you are already well aware of rather than helping to fix it. But breaking "every project of significant size on Windows" sounds...really really bad, especially since Rust's ease of use on Windows seems like a major selling point.

I just want to suggest that maybe it would be a good idea for the Rust team to draw a line in the sand somewhere to guarantee that the "stable" channel doesn't break too much stuff from update to update by delaying a release if it's not in an acceptable state. Once such a line has been drawn, of course every effort should be made "to never get to that point", as you say, but without drawing such a line, it's unclear to me that Rust will be able to maintain a public image of stability and production-readiness.

It was my impression that the triage team's pre-release meeting essentially served this purpose; that is to say, regressions considered "high priority" immediately prior to a release must be fixed in order to go forward with the release. This would constitute an ad hoc per-release "line in the sand". Is it not the case that failure to resolve these high-priority regressions would force the team to delay the release?

kornel · July 11, 2017, 11:37pm

Please don’t ship known regressions. I’m perfectly fine with the slow-moving channel being a bit slower if needed.

I’m more worried about the 6-week release schedule existing in the first place, because you almost never ship any patch releases in between, which means that all bugs that were released are intentionally left unfixed for the next 6 weeks.

willi_kappler · July 12, 2017, 8:10am

I agree with you about the known regressions, but it depends on the type of bugs I think:

Version 1.12.0 (2016-09-29) -> Version 1.12.1 (2016-10-20)

Version 1.15.0 (2017-02-02) -> Version 1.15.1 (2017-02-09)

See https://github.com/rust-lang/rust/blob/master/RELEASES.md

So urgend point releases between the 6 week schedule have been done and most likely will be done in the future if needed.

brson · July 12, 2017, 8:15pm

WRT shipping known regressions, regressions have different severities and classes, and some regressions are inevitable. For example, every release comes with a set of ‘compatibility notes’ - those are regressions. Every release ships with regressions.

brson · July 13, 2017, 12:58am

https://github.com/rust-lang/rust/issues/42719 is going to be fixed in https://github.com/rust-lang/rust/pull/43199, and https://github.com/rust-lang/rust/issues/42635 reverted.

Assuming those land, that leaves an unconfirmed fix for an ARM codegen bug and this compiletime regression that showed up at the last minute.

Release notes are updated.

brson · July 13, 2017, 2:21am

There’s another last minute regression, and it’s weird:

https://github.com/rust-lang/rust/issues/42851

brson · July 13, 2017, 6:53pm

That one is fixed. There are three pending backports, all linked from here: https://github.com/rust-lang/rust/pull/43223

I’ve got a beta cargobomb running now, and will hope to get in another over the weekend with the final backports.

It looks like we’ll have everything fixed but https://github.com/rust-lang/rust/issues/43141

system · March 25, 2019, 8:13am

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Rust 1.17 release status	1	2453	March 25, 2019
Rust 1.18 release status	6	2527	March 25, 2019
Rust 1.16 release status	6	3137	March 25, 2019
Announcing RLS 1.0 release candidate announcements	6	3180	March 25, 2019
Rust 1.15 release status	12	3270	March 25, 2019

Rust 1.19 release status

Related topics