Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stabilize `async_await` in Rust 1.39.0 #63209

Open
wants to merge 4 commits into
base: master
from

Conversation

@Centril
Copy link
Member

commented Aug 2, 2019

Blocked on:

r? @cramertj


The PR will need to be rebased as new tests are added which use the #![feature(async_await)] gate.

@rust-highfive

This comment was marked as spam.

Copy link
Collaborator

commented Aug 2, 2019

Some changes occurred in diagnostic error codes

cc @GuillaumeGomez

@Centril Centril referenced this pull request Aug 2, 2019

Open

[Stabilization] async/await MVP #62149

2 of 4 tasks complete
@cramertj

This comment was marked as resolved.

Copy link
Member

commented Aug 2, 2019

return in async closures

Just to clarify, async closures are not being stabilized here. Did you mean async blocks?

@Centril

This comment was marked as resolved.

Copy link
Member Author

commented Aug 2, 2019

return in async closures

Just to clarify, async closures are not being stabilized here. Did you mean async blocks?

Yeah, oops.

@bors

This comment was marked as resolved.

Copy link
Contributor

commented Aug 3, 2019

☔️ The latest upstream changes (presumably #63180) made this pull request unmergeable. Please resolve the merge conflicts.

@Centril Centril force-pushed the Centril:stabilize-async-await branch from 16df48a to c8dd6e7 Aug 3, 2019

@bors

This comment has been minimized.

Copy link
Contributor

commented Aug 7, 2019

☔️ The latest upstream changes (presumably #63341) made this pull request unmergeable. Please resolve the merge conflicts.

Centril added a commit to Centril/rust that referenced this pull request Aug 8, 2019

Rollup merge of rust-lang#63387 - Centril:async-block-control-flow-te…
…sts, r=cramertj

Test interaction between `async { ... }` and `?`, `return`, and `break`

Per the second checkbox in rust-lang#62121 (comment), test that `async { .. }` blocks:
1. do not allow `break` expressions.
2. get targeted by `return` and not the parent function.
3. get targeted by `?` and not the parent function.

Works towards resolving blockers in rust-lang#63209.

r? @cramertj
@est31

This comment was marked as resolved.

Copy link
Contributor

commented Aug 9, 2019

So 1.38 is currently in beta. I presume this stabilization PR will be backported. What's the plan on beta backporting the linked blocker PRs? Will that happen too? I don't see any labels about them being nominated.

@jonas-schievink

This comment was marked as resolved.

Copy link
Member

commented Aug 9, 2019

1.38 is still in nightly, beta is at 1.37. I hope we won't backport stabilizations, that seems like an unnecessary risk compared to just waiting 6 weeks.

@Centril

This comment was marked as resolved.

Copy link
Member Author

commented Aug 9, 2019

@est31 Stabilization PRs are never backported per release team consensus.

@est31

This comment was marked as resolved.

Copy link
Contributor

commented Aug 9, 2019

1.38 is still in nightly, beta is at 1.37.

Oops my bad. Nevermind then. Sorry!

Stabilization PRs are never backported per release team consensus.

I wasn't aware of that. Backporting of stabilization PRs used to be the case so thanks for the information :).

Centril added a commit to Centril/rust that referenced this pull request Aug 12, 2019

Rollup merge of rust-lang#63383 - Centril:async-lifetime-elision-test…
…s, r=nikomatsakis

`async fn` lifetime elision tests

Add `async fn` version of the tests in rust-lang#61207 per the first checkbox in rust-lang#62121 (comment).
Works towards resolving blockers in rust-lang#63209.

r? @nikomatsakis
cc @cramertj
@pietroalbini

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

Rust 1.38 is scheduled to branch off today, but this PR didn't land yet and there are a bunch of blockers still open. If we still want to stabilize async_await in 1.38 we need to land this stabilization PR right now and then backport the blockers.

I'd prefer to stabilize async_await in Rust 1.39 though, to give the compiler and language team more time to properly iron the feature out. I'm aware lots of people would like to use async_await as soon as possible, but I'm not happy rushing things out.

cc @rust-lang/lang @rust-lang/release

Centril added a commit to Centril/rust that referenced this pull request Aug 13, 2019

Rollup merge of rust-lang#63383 - Centril:async-lifetime-elision-test…
…s, r=nikomatsakis

`async fn` lifetime elision tests

Add `async fn` version of the tests in rust-lang#61207 per the first checkbox in rust-lang#62121 (comment).
Works towards resolving blockers in rust-lang#63209.

r? @nikomatsakis
cc @cramertj

Centril added a commit to Centril/rust that referenced this pull request Aug 13, 2019

Rollup merge of rust-lang#63383 - Centril:async-lifetime-elision-test…
…s, r=nikomatsakis

`async fn` lifetime elision tests

Add `async fn` version of the tests in rust-lang#61207 per the first checkbox in rust-lang#62121 (comment).
Works towards resolving blockers in rust-lang#63209.

r? @nikomatsakis
cc @cramertj
@crlf0710

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

While i respect any decisions made by lang and release team, personally i think this feature is worth its own special point release (1.38.1) if it missed this train.

@XAMPPRocky

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

@crlf0710 Thank you for your feedback, however we would definitely not make a point release for such a large feature, as that would be confusing for end users, and make a lot more work for the release and infra teams. It would also break the semver rule of "PATCH version when you make backwards compatible bug fixes.".

This feature is very important both to the Rust team and the community, however we shouldn't bend over backwards and put more pressure on the Rust teams (most of whom are volunteers) just to make a arbitrary date. People want async/await, they don't want async/await that is half baked.

@skade

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

@pietroalbini I'm hesitant there. I also don't agree with @XAMPPRocky that the date is arbitrary.

async/await is already suffering from delays. People are actively using the feature and we have communicated a date before RustConf to stabilise it (as a proposal, but many people are aware of that date). It's the prime chance to get a beta version of it into the hands of people and encourage people to use beta more. We have already communicated it as MVP. And we have already pushed it out of edition 2018.

I'm not saying we should push it into Beta at all cost, but I also want to say that the cost of pushing another release is higher then most others.

@nicoburns

This comment has been minimized.

Copy link

commented Aug 13, 2019

It's the prime chance to get a beta version of it into the hands of people and encourage people to use beta more.

Is there an option of doing a double-length beta period. I believe this was done for another feature in the past (NLL?).

I'm definitely in the "don't release it until it's ready camp" (despite really looking forward to this feature). The purpose of Rust's 6-week release trains is that 6 weeks isn't too long to wait if a feature slips a release, and I think it works pretty well.

Another 6 weeks for library authors to get std::future supporting releases out would be pretty wouldn't hurt either. Tokio has a release out, but pretty much nothing that depends on it does yet (notably including Hyper)...

@skade

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

@nicoburns I'm not sure, but if there is, it sounds like an idea to consider.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

I believe we did that for the 2018 edition?

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

It is indeed true that the edition was stabilized in beta for two cycles. I don't personally think it makes much sense to do that for async/await, based on the blocking issues and other parts of it, but we certainly could do that. However, the train model is explicitly intended to avoid us doing "last minute stabilization" and such. At this point, master->beta promotion is scheduled for today, and simply just hasn't happened yet. It seems wrong to delay that for any one feature.

The release team has also settled on a policy of never backporting stabilization PRs; in this case the PR appears to not be ready yet (merge conflicts, there are open blockers....).

I fully acknowledge that all of us want async/await yesterday, but the reality is we simply haven't gotten it ready in time for the 1.38 beta cutoff; if that means it slips to 1.39, then I think we should accept that. One thing to keep in mind is that once we stabilize it on nightly, it'll be "just as" usable as on beta -- no need to add feature flags, etc.

@BatmanAoD

This comment has been minimized.

Copy link

commented Aug 13, 2019

@skade

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

I'm not sure if cutting a beta early makes sense, because that means a lot more hassle down the road for features targeted for 1.39. People schedule their lives and work around the releases.

I agree though that the bugs being hit so late either means that we don't have enough users (which I consider unlikely), but also that the usage of the patterns triggering those bugs are rather fringe (which means we need to ramp up on the testers).

@BatmanAoD

This comment has been minimized.

Copy link

commented Aug 13, 2019

@pietroalbini

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

One possibility that hasn't come up yet is just cutting the 1.39 beta
early, as soon as this stabilization PR merges. That would either give us
more time on beta or, if we wanted, the opportunity to cut the actual 1.39
release early, with async/await as the only new feature.

Pretty sure that's not worth the hassle: 1.38 is planned to be release on 2019-09-26, and we need to keep it in beta until then since we need people to test the release and us to run Crater on it. What would happen with this "early beta" until then? Would we need to create another channel like beta2?

Messing up our release infra for an highly anticipated release sounds like a recipe for disaster.

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

At this point, I'm going to make the call that the beta promotion is going ahead within the next hour or so, not blocking on async/await being ready. If we, over the next cycle, come to a conclusion that async/await needs to ship in 1.38 for whatever reason, we can backport into beta as necessary, with sign-off from T-lang/T-compiler. We don't want to hold off on shipping a beta for the time being though.

@Mark-Simulacrum Mark-Simulacrum changed the title Stabilize `async_await` in Rust 1.38.0 Stabilize `async_await` in Rust 1.39.0 Aug 13, 2019

@Mark-Simulacrum Mark-Simulacrum modified the milestones: 1.38, 1.39 Aug 13, 2019

@BatmanAoD

This comment has been minimized.

Copy link

commented Aug 13, 2019

@skade

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

That can be as official as it must be, I'm sure next weeks hackfest is a good moment to.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

I agree with @Mark-Simulacrum that we should go ahead and make the beta release. I also think we should prioritize getting this stabilization PR landed: having a stable async-await, even if only on nightly, would be a really great achievement and is well within reach. The most important thing seems to be having a known date when it will be stable.

I don't yet have an opinion about backporting the release to beta -- in general, I agree with the policy of "don't backport stabilizations". Most stabilizations just aren't important enough to deal with the hassle. This may be an exception, but I'm not sure. I think what I would want to do is to consider (a) the complexity of the PRs in question; (b) what further bugs get filed while things are stable on nightly; and (c) review the test suite.

One thing I noticed is that a lot of the bugs in question were filed relatively recently (within the last week or two, and, in the case of #63388, just a few days ago). This makes me a bit nervous that we may see some more bugs getting filed once things become stable and we get more attention. I would be very happy if we only have to fix those bugs on nightly, without the added pressure of beta backports.

Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request Aug 14, 2019

Rollup merge of rust-lang#63383 - Centril:async-lifetime-elision-test…
…s, r=nikomatsakis

`async fn` lifetime elision tests

Add `async fn` version of the tests in rust-lang#61207 per the first checkbox in rust-lang#62121 (comment).
Works towards resolving blockers in rust-lang#63209.

r? @nikomatsakis
cc @cramertj

Centril added a commit to Centril/rust that referenced this pull request Aug 14, 2019

Rollup merge of rust-lang#63383 - Centril:async-lifetime-elision-test…
…s, r=nikomatsakis

`async fn` lifetime elision tests

Add `async fn` version of the tests in rust-lang#61207 per the first checkbox in rust-lang#62121 (comment).
Works towards resolving blockers in rust-lang#63209.

r? @nikomatsakis
cc @cramertj

Centril added a commit to Centril/rust that referenced this pull request Aug 14, 2019

Rollup merge of rust-lang#63383 - Centril:async-lifetime-elision-test…
…s, r=nikomatsakis

`async fn` lifetime elision tests

Add `async fn` version of the tests in rust-lang#61207 per the first checkbox in rust-lang#62121 (comment).
Works towards resolving blockers in rust-lang#63209.

r? @nikomatsakis
cc @cramertj
@leaxoy

This comment has been minimized.

Copy link

commented Aug 14, 2019

It seems that it has been postponed again and again 😂

@RalfJung

This comment has been minimized.

Copy link
Member

commented Aug 14, 2019

Interesting new findings in the UCG: @comex managed to violate noalias with just async/await. There are currently no known miscompilations, likely because the use of thread-local storage confuses LLVM enough that it cannot analyze the code well enough to exploit this UB.

But I agree with @comex that, with -Z mutable-noalias=yes, the generated IR does have UB. (That -Z flag exists because of LLVM bugs that keep coming up for noalias mutable references, but the IR Rust generates should still be UB-free even with that flag set.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.