Future-proof the Futures API

[cramertj]

cc #59113, @carllerche, @rust-lang/libs

r? @withoutboats

[rust-highfive]

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:03471c00:start=1552348735192620946,finish=1552348811489474158,duration=76296853212
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
Setting environment variables from .travis.yml
---
[00:03:31]    Compiling build_helper v0.1.0 (/checkout/src/build_helper)
[00:03:35] error[E0432]: unresolved import `task::Context`
[00:03:35]  --> src/libcore/future/future.rs:8:12
[00:03:35]   |
[00:03:35] 8 | use task::{Context, Poll};
[00:03:35]   |            ^^^^^^^ no `Context` in `task`
[00:03:37]    Compiling compiler_builtins v0.1.5
[00:03:37]    Compiling cmake v0.1.33
[00:03:37]    Compiling backtrace-sys v0.1.27
[00:03:40]    Compiling std v0.0.0 (/checkout/src/libstd)
[00:03:40]    Compiling std v0.0.0 (/checkout/src/libstd)
[00:03:40]    Compiling rustc_msan v0.0.0 (/checkout/src/librustc_msan)
[00:03:40]    Compiling rustc_tsan v0.0.0 (/checkout/src/librustc_tsan)
[00:03:41]    Compiling rustc_lsan v0.0.0 (/checkout/src/librustc_lsan)
[00:03:41]    Compiling rustc_asan v0.0.0 (/checkout/src/librustc_asan)
[00:03:47] error[E0308]: mismatched types
[00:03:47]    --> src/libcore/task/wake.rs:117:9
[00:03:47]     |
[00:03:47] 116 |       ) -> RawWaker {
[00:03:47]     |            -------- expected `task::wake::RawWaker` because of return type
[00:03:47] 117 | /         RawWakerVTable {
[00:03:47] 119 | |             wake,
[00:03:47] 120 | |             drop,
[00:03:47] 121 | |         }
[00:03:47] 121 | |         }
[00:03:47]     | |_________^ expected struct `task::wake::RawWaker`, found struct `task::wake::RawWakerVTable`
[00:03:47]     |
[00:03:47]     = note: expected type `task::wake::RawWaker`
[00:03:47]                found type `task::wake::RawWakerVTable`
[00:03:49] error: aborting due to 2 previous errors
[00:03:49] 
[00:03:49] Some errors occurred: E0308, E0432.
[00:03:49] For more information about an error, try `rustc --explain E0308`.
---
travis_time:end:0e2ece00:start=1552349050582176853,finish=1552349050587060466,duration=4883613
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:01aad72e
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:1f3d35a7
travis_time:start:1f3d35a7
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:0b2028f0
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[withoutboats]

In terms of the list of possible extensions this is intended to be forward compatible with, I would divide them into two groups:

• Things related to the executor (e.g. task locals)
• Things unrelated to the executor but instead related to sources of events (e.g. exposing a global timer or reactor)

I'd like to be confident our API is sufficient for supporting the former, and rule out the idea that the argument passed to future is the correct way to pass the latter (I see this argument, currently called waker, as strictly a way to interact with the executor this future is being executed on).

So I would like to see task locals properly explored to see what would need to change about the current API. I am not really in favor of adding this indirection, because I think we should not pass context unrelated to the executor through this interface.

In terms of compatibility I'm much more concerned about ending up with a very unwieldly construction API for RawWaker because we add a bunch of optional fields than I am about having the argument called Waker. Almost so that I'd consider holding off on stabilizing rawwaker's constructor(s) for a cycle or two while we explore ways of interacting with the executor beyond waking.

[yoshuawuyts]

Meta-question: why is this a PR rather than an RFC? It seems to be a significant departure of the Futures API design accepted in rust-lang/rfcs#2592.

There isn't consensus yet on this API modification. And maybe it's just me, but by opening a PR directly on stdlib instead of going through the RFC process I feel unnecessary urgency (and tension) is added to the decision making process.

[seanmonstar]

I'd like to be confident our API is sufficient for supporting the former, and rule out the idea that the argument passed to future is the correct way to pass the latter.

I don't agree. I'd like that we didn't rule it out so early. Other languages have shown it to be useful, and we don't have experience to the contrary in Rust. Forwards-compatibility is not something libstd should rule out quickly.

In comparison, ergonomics of creating a waker is not something I would optimize for. Regular users will never have to create one. Only a couple executor libraries will.

why is this a PR rather than an RFC?

It was a question brought up multiple times in the RFC, but never really addressed. The tracking issue mentioned it as an unresolved question. As for why it's a PR already, it might be slightly early. 🤷

[cramertj]

@withoutboats

I'd like to be confident our API is sufficient for supporting the former, and rule out the idea that the argument passed to future is the correct way to pass the latter (I see this argument, currently called waker, as strictly a way to interact with the executor this future is being executed on).

I consider the task-locals discussion to have been settled on the RFC thread.

As for whether or not to provide executors this way, adding any additional data like this to the Context type would require an additional RFC thread, and I'd be happy to argue this point there. I'm not interested in discussing it here, as a decision there is not a blocker for stabilizing the Future trait.

[carllerche]

@cramertj

I'm not interested in discussing it here, as a decision there is not a blocker for stabilizing the Future trait.

Only if the Future trait is forwards-compatible to that change :). I agree with you entirely that Future should be stabilized sooner than later and discussing any possible additions can be punted until later. This is why I am hoping we can agree to a forwards-compatible API and punt any further discussion until the ecosystem catches up.

[cramertj]

@yoshuawuyts

The future-proofing was left as an open-question during FCP. We will still require an FCP for stabilization which cover all final amendments that have been made to the API.

I don't personally view this as a significant digression from the API suggested there, as the only functional change is to move &Waker into a wrapper type with a constructor.

[nikomatsakis]

(From a procedural point-of-view, I think that discussing this point in a PR is reasonable. As @cramertj says, we often make amendments to details from the RFC during the implementation period, particularly when addressing unresolved questions.)

[cramertj]

@carllerche

Only if the Future trait is forwards-compatible to that change :). I agree with you entirely that Future should be stabilized sooner than later and discussing any possible additions can be punted until later. This is why I am hoping we can agree to a forwards-compatible API and punt any further discussion until the ecosystem catches up.

Yup! I agree.

[ghost]

I'll try reiterating the core arguments of both sides. Please correct me if my understanding is wrong.

The argument in favor of Context

We need to make all components of the runtime (waker, spawner, reactor, timer, task locals) available to the polled Future one way or another. We'll either make them available through TLS or through Context passed as an argument to poll().

Passing only Waker as an argument means only one component of the runtime (waker) is made available so everything else will have to be threaded through TLS. This doesn't make sense - either everything should go through TLS or everything should go through the Context argument.

Since we've already decided in a previous RFC that Waker should be passed as an argument, then it makes sense to pass everything else that way, too!

The argument against Context

In order to have fully working async/await, we need three things: the Future trait, Pin for self-references, and Waker for notification. That's it. Everything else (spawner, reactor, timer, task locals) are completely orthogonal features and irrelevant to async/await. As such, they do not belong to the core API!

Futhermore, we want to make all components of runtimes decoupled as much as possible. Passing a Context to every Future would de facto make it the central configuration for the whole runtime. There are potential compatibility hazards among runtime components in such design so we'd rather avoid it altogether.

---

My feeling is we should not have Context because passing the whole runtime configuration to poll() simply seems like an inappropriate thing to do. It would burden the API with something it doesn't really need and I think the API should be the minimal set of features that makes fully working async/await possible. No more, no less.

[carllerche]

@stjepang that does not reflect my argument. My argument is that we should not block stabilizing Future on exploring all possibilities of the future api to an extent that we can comfortably say “this is it, we will never have to change this ever again”.

My examples are simply illustrations of thibgs that could be possible. The fact is that hardly any of the ecosystem has switched to using explicit waker. Once there is more usage who is to say what other use cases will come up. I came up with possibilities as a straw man.

Of course the ecosystem won’t start moving until the api is stable, so it is a chicken / egg problem.

The proposal for context is to allow changes to the api in the future as cases come up instead of locking the api down now to potential future changes.

Focusing on the specific example is missing the point.

[ghost]

@carllerche Thanks for clarifying!

Do you think it is possible a use case will come up which cannot be satisfied through other means like TLS or global statics? It seems spawners, reactors, timers, and task locals can be accessed through TLS just fine. (Even wakers could be accessed through TLS but there are valid reasons to pass them as arguments instead.)

Or did you mean we might want Waker to be able to do more than wake, be cloned, and be dropped? By that I mean to do something unrelated to other components of the runtime (spawner, reactor, timer, task locals).

[carllerche]

@stjepang I cannot say for sure as I have not spent the time investigating. This is my point.

One issue is going to be FuturesUnordered. This type alters the waker. How would this interact with any task local state set via thread locals? Also, I have had cases where I wanted a fresh task context while polling (using Spawn in 0.1). I don’t know how this would apply.

Regardless of this, I’m pretty sure they using the context argument would be noticeably faster than thread locals. So, not future proofing would give up these potential improvements.

[sagebind]

• Unknown unknowns are always unknown. Unless it significantly hurts the API today, forwards compatibility is always a welcome property.
• I'd avoid stuffing things into thread-local storage if we can. They're like global variables; they should be used with care and only if necessary, and can come with a performance cost. This PR makes them not necessary if we discover new things that could be added down the road. Of course we don't know what those are now, see my previous point.
• Most code will never touch neither poll nor wakers, especially when async/await lands, so I wouldn't too much weight on the immediate ergonomics.

[ghost]

@carllerche

One issue is going to be FuturesUnordered. This type alters the waker. How would this interact with any task local state set via thread locals?

I see the problem with task local state, but don't see how putting additional data into Context fundamentally changes the situation. Isn't it that whatever can be done with Contexts can also be done equally well with TLS?

Also, I have had cases where I wanted a fresh task context while polling (using Spawn in 0.1). I don’t know how this would apply.

Sorry, I don't follow. The futures 0.1 crate doesn't have Context and yet can do this through futures::executor::spawn? Why couldn't we access the executor through TLS to spawn a fresh task?

Regardless of this, I’m pretty sure they using the context argument would be noticeably faster than thread locals. So, not future proofing would give up these potential improvements.

That is true, but is similar to the argument against the RFC proposing to merge LocalWaker and Waker. In that RFC, the question was whether the performance gains of avoiding atomics and TLS in some cases were worth the ergonomic losses and increased API surface. In the end, we decided to sacrifice performance. Introducing Context is almost a reversal of that decision because now &mut Context is sort of like a beefed up &LocalWaker.

That is not to say you're not raising fair points - I appreciate the concerns around stabilizing Waker and acknowledge the downsides! But still feel pretty confident it's the right way forward.

[nikomatsakis]

Hello, async world. This thread seems to be have slowed down, which is good. I wanted to add a link to an experiment that I am trying here. Below is a Dropbox paper document containing my best effort at a summary of the pros/cons for this change:

Summary Document

This is based on me skimming the thread here as well as some of the other threads, along with some conversation with @cramertj, @yoshuawuyts, and @withoutboats. I am posting it here because I would like to encourage others to take a look and offer suggestions -- especially @carllerche, as a strong advocate of this PR.

I included some directions in the document, but the idea is that this to be a collaboratively produced summary that captures the major points. To that end, my hope is that -- if you leave a comment -- you can offer alternate wording that takes an existing point and makes it more precise (or perhaps adds details). I will either adopt that wording or try to incorporate it into the main text. I do plan to use editorial discretion to keep this concise, but I don't honestly have a very strong opinion about this particular PR, so I aim to be unbiased. Please let me know if you feel I am not (ideally over privmsg, so we can chat). ❤️

I know we are all eager to see the Future trait stabilized. To that end, since this particular PR seems to be largely a @rust-lang/libs question to me -- it is a question of "best practices" around API design -- I've also asked the @rust-lang/libs team to take a look at the summary and weigh in on the questions at the end. I believe they have this on their agenda for this coming Wednesday.

[nikomatsakis]

To clarify, I think that the decisions re: Future are ultimately both a T-lang and a T-libs concern, but I am particularly interested to get T-libs feedback here because of the intersection with API design. For example, the future proofing section of the Rust API guidelines covers a number of important points, but doesn't recommend anything clearly related to this PR, so I was curious if this had come up before in prior discussions. (Also, if others have examples they can point at that seem relevant, leave comments in the doc, maybe I'll make a "prior art" section or something like this.)

[Thomasdezeeuw]

I just wanted to add to the discussion that using async functions it is possible to provide a context (or any argument) without changing the Future trait.

async fn my_future(ctx: Context) -> () {
    println!("Context field: {}", ctx.field);
    ()
}

(playground link)

This leave the Future trait to the bare minimum, but allows for extendability as well as framework/crate specific contexts.

[seanmonstar]

@Thomasdezeeuw that'd be more like call context. This PR is about execution context. Things that you may not know at the call site (similar to how we don't know what the waker is yet).

[carllerche]

@nikomatsakis My primary argument is stronger than "In short, we cannot know the future." It is: "There are things we know about now that are worth exploring, but lets not hold up stabilization to do so."

I have explicitly avoided to argue for any of these potential improvements so far in an effort to focus on stabilization. To be honest, I did not expect the forwards compatibility proposal to be controversial. If it is rejected, then we will need to front load evaluating these changes.

[nikomatsakis]

@carllerche

My primary argument is stronger than "In short, we cannot know the future." It is: "There are things we know about now that are worth exploring, but lets not hold up stabilization to do so."

OK. Thanks for that. I have attempted to rework the introduction in a way that I think captures what you wrote here:

Pro: Clearly, futures need to be given a Waker, but frameworks (like tokio) often want to give the future access to other parts of the runtime (e.g., to spawn new tasks), and we may find other bits of data we want in the future. There is a bit of a catch-22: we won’t see widespread adoption until we stabilize, but if we stabilize we lose the ability to add more parameters. Therefore, we should add a flexible Context struct that we can extend later.

If that's not quite right, please supply an edit that works better. =)

[nikomatsakis]

I spent a good hour yesterday going over the document, trying to resolve comments. There are still a few comments left that I wasn't able to incorporate, but I think overall it's fairly representative. Still, the document is quite long by now. From reading it, I think the crux of the debate comes down to TLS. So let me take a shot at pulling out the "core tradeoff". I'm curious to hear what people think. Let me know if you don't feel represented here =)

---

The tradeoff

• First, on the one hand, adopting Context makes the trait more complex to understand (though how much is subjective). It also imposes an ergonomic cost (detailed in the doc). Let's call this the "ergonomic cost" of the PR.

• On the other hand, unless we introduce Context, TLS is the best option for passing additional implicit state (see * below for a caveat), and TLS has downsides:

  • it is somewhat slower (though how relevant that is in the context of a full application is disputed, see the doc);
  • it is implicit dataflow that can be brittle (so e.g. introducing threads could mess it up);
  • it may not be portable to embedded platforms (though I think I'm convinced by now this is a non-issue, see the doc).

So the core tradeoff here is this:

• By leaving the design as is, we keep it as simple and ergonomic as it can be;
  • but, if we wish to pass implicit parameters to the future when polling, we must use TLS.

Note that I emphasized passing implicit parameters. By this I mean data passed from the caller of poll to the callee. It is also possible to thread additional data explicitly -- e.g., when creating the future, you could instantiate it with the data it will need during poll. If you think of an async fn, this roughly corresponds to passing the data to the async fn as explicit arguments, versus the async fn just 'magically' having access to it. (As noted in the doc, it's not clear how async fns would gain access to these additional implicit arugments without either using TLS or adding new keywords, unless they are used somehow in the desugaring of await. This feels like an important point to me, too.)

The conclusion

So, which way you fall will depend on

• how important you think it is for Future to be ergonomic
  • and naturally how much of an ergonomic hit you believe this to be
• how likely you think it is for us to want to add implicit parameters
• how much of a problem you think it is to use TLS for those implicit parameters

I think a number of people feel that, by now, between Rust and other ecosystems, we have a pretty good handle on what sort of data we want to thread around and what the best way is to do it. Further, they feel that TLS or passing parameters explicitly is the best solution approach for those cases. Therefore, they prefer to leave the design as is, and keep things simple. (More details in the doc, of course.)

Others, however, feel like there is additional data they want to pass implicitly and they do not feel convinced that TLS is the best choice, and that this concern outweights the ergonomic costs. Therefore, they would rather adopt the PR and keep our options open.

Finally, I think there is a third position that says that this controversy just isn't that important. The performance hit of TLS, if you wind up using it, seems to be minimal. Similarly, the clarity/ergonomics of Future are not as criticial, as users who write async fn will not implement it directly, and/or perhaps the effect is not so large. These folks probably could go either way, but would mostly like us to stop debating it and start building stuff. =)

Footnotes

* -- One caveat is that there is another option besides TLS. We could add add'l state to the Waker. The document dives into the tradeoffs there. My opinion is that it seems to be (overall) a less appealing option than TLS, and certainly a less explored one in practice, so I chose to leave it off.

[rust-highfive]

The job x86_64-gnu-tools of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[01:32:53] normalized stderr:
[01:32:53] error[E0308]: mismatched types
[01:32:53]   --> $DIR/async-fn.rs:39:61
[01:32:53]    |
[01:32:53] 39 |     assert_eq!(unsafe { Pin::new_unchecked(&mut fut) }.poll(&waker), Poll::Ready(31));
[01:32:53]    |                                                             ^^^^^^ types differ in mutability
[01:32:53]    = note: expected type `&mut std::task::Context<'_>`
[01:32:53]               found type `&std::task::Waker`
[01:32:53] 
[01:32:53] error: aborting due to previous error
---
[01:32:53] 
[01:32:53] +error[E0308]: mismatched types
[01:32:53] +  --> $DIR/async-fn.rs:39:61
[01:32:53] +   |
[01:32:53] +39 |     assert_eq!(unsafe { Pin::new_unchecked(&mut fut) }.poll(&waker), Poll::Ready(31));
[01:32:53] +   |                                                             ^^^^^^ types differ in mutability
[01:32:53] +   = note: expected type `&mut std::task::Context<'_>`
[01:32:53] +              found type `&std::task::Waker`
[01:32:53] +
[01:32:53] +error: aborting due to previous error
[01:32:53] +error: aborting due to previous error
[01:32:53] +
[01:32:53] +For more information about this error, try `rustc --explain E0308`.
[01:32:53] +
[01:32:53] 
[01:32:53] The actual stderr differed from the expected stderr.
[01:32:53] Actual stderr saved to /tmp/compiletest9ObgYh/async-fn.stderr
[01:32:53] To update references, run this command from build directory:
[01:32:53] tests/run-pass/update-references.sh '/tmp/compiletest9ObgYh' 'async-fn.rs'
[01:32:53] error: 1 errors occurred comparing output.
[01:32:53] status: exit code: 1
[01:32:53] status: exit code: 1
[01:32:53] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools-bin/miri" "tests/run-pass/async-fn.rs" "-L" "/tmp/compiletest9ObgYh" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-C" "prefer-dynamic" "-o" "/tmp/compiletest9ObgYh/async-fn.stage-id" "-Dwarnings" "-Dunused" "--edition" "2018" "-L" "/tmp/compiletest9ObgYh/async-fn.stage-id.aux" "-A" "unused"
[01:32:53] ------------------------------------------
[01:32:53] 
[01:32:53] ------------------------------------------
[01:32:53] stderr:
[01:32:53] stderr:
[01:32:53] ------------------------------------------
[01:32:53] {"message":"mismatched types","code":{"code":"E0308","explanation":"\nThis error occurs when the compiler was unable to infer the concrete type of a\nvariable. It can occur for several cases, the most common of which is a\nmismatch in the expected type that the compiler inferred for a variable's\ninitializing expression, and the actual type explicitly assigned to the\nvariable.\n\nFor example:\n\n```compile_fail,E0308\nlet x: i32 = \"I am not a number!\";\n//     ~~~   ~~~~~~~~~~~~~~~~~~~~\n//      |             |\n//      |    initializing expression;\n//      |    compiler infers type `&str`\n//      |\n//    type `i32` assigned to variable `x`\n```\n"},"level":"error","spans":[{"file_name":"tests/run-pass/async-fn.rs","byte_start":925,"byte_end":931,"line_start":39,"line_end":39,"column_start":61,"column_end":67,"is_primary":true,"text":[{"text":"    assert_eq!(unsafe { Pin::new_unchecked(&mut fut) }.poll(&waker), Poll::Ready(31));","highlight_start":61,"highlight_end":67}],"label":"types differ in mutability","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[{"message":"expected type `&mut std::task::Context<'_>`\n   found type `&std::task::Waker`","code":null,"level":"note","spans":[],"children":[],"rendered":null}],"rendered":"error[E0308]: mismatched types\n  --> tests/run-pass/async-fn.rs:39:61\n   |\n39 |     assert_eq!(unsafe { Pin::new_unchecked(&mut fut) }.poll(&waker), Poll::Ready(31));\n   |                                                             ^^^^^^ types differ in mutability\n   |\n   = note: expected type `&mut std::task::Context<'_>`\n              found type `&std::task::Waker`\n\n"}
[01:32:53] {"message":"For more information about this error, try `rustc --explain E0308`.","code":null,"level":"","spans":[],"children":[],"rendered":"For more information about this error, try `rustc --explain E0308`.\n"}
[01:32:53] 
[01:32:53] ------------------------------------------
[01:32:53] 
---
travis_time:end:0dc798fe:start=1554524000861455596,finish=1554524000871422332,duration=9966736
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1e554f48
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0a884060
travis_time:start:0a884060
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:13814f1c
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[kennytm]

@bors r-

Failed the miri UI test run-pass/async-fn.rs.

[RalfJung]

Should we temporarily ignore that Miri test (maybe as part of #59755 if we are quick enough)? Else we wait until the beta branched and tool breakage is a thing again.

[Centril]

@RalfJung Depends on whether you think the delay is small enough for #58739 to not miss master=>beta promotion on Tuesday.

[matthewjasper]

MIRI has been updated

@bors r=withoutboats

[bors]

📌 Commit 1691e06 has been approved by withoutboats

[bors]

⌛ Testing commit 1691e06 with merge 4fb888b...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: withoutboats
Pushing 4fb888b to master...