Update the future/task API #57992

Matthias247 · 2019-01-30T09:37:35Z

This change updates the future and task API as discussed in the stabilization RFC at rust-lang/rfcs#2592.

Changes:

Replacing UnsafeWake with RawWaker and RawWakerVtable
Removal of LocalWaker
Removal of Arc-based Wake trait

Centril · 2019-01-30T09:38:16Z

Matthias247 · 2019-01-30T09:38:45Z

@cramertj I also started updating future-rs. However I currently had some build problems there, and it's a lot of stuff to change. Will look again tomorrow evening.

Centril · 2019-01-30T09:49:27Z

src/libcore/future/future.rs

@@ -42,16 +42,16 @@ pub trait Future {
    /// Once a future has finished, clients should not `poll` it again.


As discussed in https://github.com/rust-lang/rfcs/pull/2592/files#r232498609, clarify that it isn't guaranteed that clients won't poll again, that it isn't guaranteed that panics will occur if they do, and that this assumption shouldn't be used for memory safety.

This has identical behaviour/requirements to Iterator::next, which has even less docs around behaviour after completion. Should this clarity be required there as well?

(EDIT: lol, looking back I was the one saying this should have more clarity. I guess I'm on the side that the iterator docs should probably be improved as well.)

Returns None when iteration is finished. Individual iterator implementations may choose to resume iteration, and so calling next() again may or may not eventually start returning Some(Item) again at some point.

The difference here is that Iterator::next doesn't imply in any way (in fact, the opposite) that None + None isn't a valid sequence. Meanwhile, "should not poll it again" is emphatic about what should not happen, so a reader may assume this is always true.

A non-intrusive change to the language here would just be to weaken "should not poll again" to something like "is recommended to not poll again".

I'm torn on this one. In the section that @Centril commented about lower, I think no guarantees are made at all for clients polling again after Ready was returned. Incl. memory safety guarantees.
As far as I remember some future implementations might have exploited this for performance reasons.

We can obviously change and enforce this, but I wouldn't like to change the semantics inside this CR.

It must be memory safe since this function isn't unsafe. Other than that, there are no guarantees, most futures will panic, but some may just implicitly reset and run again, or get stuck returning Poll::Pending without scheduling a wakeup, or anything else that doesn't break memory safety. So, an executor or wrapping future calling poll again after Ready is returned is a very bad logic bug that has a high chance of causing subsequent errors elsewhere in the system (so panicking is the best option to minimise those subsequent errors), but can't be allowed to compromise memory safety.

I think part of the difference from Iterator is what implementations are likely to do. With Iterator you have an easy option of just returning None again, so while polling it again is a bug you have less chance of bringing your system down. With Future you can't easily return Ready again (unless the value is trivial), so it's mostly guaranteed that polling again will either panic or do something unexpected which will cause later issues.

I added the comment about memory safety to the other section (which refers to polling after Ready).

Centril · 2019-01-30T09:51:03Z

src/libcore/future/future.rs

    /// Once a task has been woken up, it should attempt to `poll` the future
    /// again, which may or may not produce a final value.
    ///
    /// Note that on multiple calls to `poll`, only the most recent
-    /// [`LocalWaker`] passed to `poll` should be scheduled to receive a
+    /// [`Waker`] passed to `poll` should be scheduled to receive a
    /// wakeup.
    ///
    /// # Runtime characteristics


Below it reads:

An implementation of poll should strive to return quickly, and must never block.

Per https://github.com/rust-lang/rfcs/pull/2592/files#r250460257, clarify that callers of poll for an arbitrary F: Future may not assume this to be true for memory safety purposes.

I think that information is provided implicitly. I think this together with the next sentences clarifies to the reader that this is purely about performance. I'm having a hard time to interpret anything about memory safety into it. We don't document for other methods either that they need to be memory safe, even if they are slow.

I would again make the language weaker here and say "is recommended to never block" instead of framing it in a way that suggests a guarantee. It is true that the function is not unsafe, but reinforcing the non-guarantee seems helpfully non-misleading to me.

Centril · 2019-01-30T09:51:41Z

src/libcore/future/future.rs

-    /// [`LocalWaker::wake`] implementations have the ability to be more
-    /// efficient, however, so when thread safety is not necessary,
-    /// [`LocalWaker`] should be preferred.
-    ///
    /// # Panics
    ///
    /// Once a future has completed (returned `Ready` from `poll`),


Per https://github.com/rust-lang/rfcs/pull/2592/files#r250460358, clarify that "bad behavior" isn't violating soundness / memory unsafety.

See comment above.

src/libcore/task/wake.rs

Centril · 2019-01-30T10:28:15Z

src/libcore/task/wake.rs

-}
-
-impl fmt::Debug for LocalWaker {
+impl fmt::Debug for Waker {


This would also be more useful by just #[derive(Debug)]

I thought about it, but it fear this will end up super noisy. I think lots of user-structs will store Waker in them and #[derive(Debug)]. Those would then all the show 5 different pointers that have no meaning for the average user.

The main reason why I think it might be useful is that users don't have access to RawWaker, so they can't get the inner information.

Maybe we should then only print the data and vtable pointer for RawWaker, and not the inner function pointers. I think if I would need to ever debug those things, the main thing I would be if if Wakers refer to the same task or not, and with a lower probability of they use the same vtable. The function pointers are are mostly worthless without names.

In general those things might also be more ones that one would investigate with a real in-memory-debugger than with print debugging.

I assume adding something like debug_fmt: Option<unsafe fn(*const (), f: &mut fmt::Formatter) -> fmt::Result> to RawWakerVTable wouldn't be worth it? (and if RawWakerVTable is made non_exhaustive could be added later anyway).

IMO printing the address of the data and vtable pointers seems helpful, but I would leave the substructure out.

@cramertj's suggestion seems like a good have-your-🍰-eat-it approach.

I added pointer printing for Waker. And yes, I don't think the fmt method is worth it.

src/libcore/task/wake.rs

rust-highfive · 2019-01-30T10:55:37Z

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:09f39ace:start=1548841178820246614,finish=1548841180273601068,duration=1453354454
$ 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
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-6.0
---
Check compiletest suite=run-pass mode=run-pass (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:08:58] 
[01:08:58] running 2946 tests
[01:09:11] .................................................................................................... 100/2946
[01:09:22] ..................................................F..............................i.................. 200/2946
[01:09:43] .................................................................................................... 400/2946
[01:09:52] .................................................................................................... 500/2946
[01:10:04] .................................................................................................... 600/2946
[01:10:20] .................................................................................................... 700/2946
[01:10:20] .................................................................................................... 700/2946
[01:10:32] .................................................................................................... 800/2946
[01:10:41] ........................................F........................................................... 900/2946
[01:11:10] .................................................................................................... 1100/2946
[01:11:19] .................................................................................................... 1200/2946
[01:11:29] .................................................................................................... 1300/2946
[01:11:42] .................................................................................................... 1400/2946
---
[01:15:39] failures:
[01:15:39] 
[01:15:39] ---- [run-pass] run-pass/async-await.rs stdout ----
[01:15:39] 
[01:15:39] error: test compilation failed although it shouldn't!
[01:15:39] status: exit code: 1
[01:15:39] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/run-pass/async-await.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/async-await/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--edition=2018" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/async-await/auxiliary"
[01:15:39] ------------------------------------------
[01:15:39] 
[01:15:39] ------------------------------------------
[01:15:39] stderr:
[01:15:39] stderr:
[01:15:39] ------------------------------------------
[01:15:39] {"message":"unresolved imports `std::task::LocalWaker`, `std::task::Wake`, `std::task::local_waker_from_nonlocal`","code":{"code":"E0432","explanation":"\nAn import was unresolved.\n\nErroneous code example:\n\n```compile_fail,E0432\nuse something::Foo; // error: unresolved import `something::Foo`.\n```\n\nPaths in `use` statements are relative to the crate root. To import items\nrelative to the current and parent modules, use the `self::` and `super::`\nprefixes, respectively. Also verify that you didn't misspell the import\nname and that the import exists in the module from where you tried to\nimport it. Example:\n\n```\nuse self::something::Foo; // ok!\n\nmod something {\n    pub struct Foo;\n}\n# fn main() {}\n```\n\nOr, if you tried to use a module from an external crate, you may have missed\nthe `extern crate` declaration (which is usually placed in the crate root):\n\n```\nextern crate core; // Required to use the `core` crate\n\nuse core::any;\n# fn main() {}\n```\n"},"level":"error","spans":[{"file_name":"/checkout/src/test/run-pass/async-await.rs","byte_start":218,"byte_end":228,"line_start":12,"line_end":12,"column_start":5,"column_end":15,"is_primary":true,"text":[{"text":"    LocalWaker, Poll, Wake,","highlight_start":5,"highlight_end":15}],"label":"no `LocalWaker` in `task`","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"/checkout/src/test/run-pass/async-await.rs","byte_start":236,"byte_end":240,"line_start":12,"line_end":12,"column_start":23,"column_end":27,"is_primary":true,"text":[{"text":"    LocalWaker, Poll, Wake,","highlight_start":23,"highlight_end":27}],"label":"no `Wake` in `task`. Did you mean to use `Waker`?","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"/checkout/src/test/run-pass/async-await.rs","byte_start":246,"byte_end":271,"line_start":13,"line_end":13,"column_start":5,"column_end":30,"is_primary":true,"text":[{"text":"    local_waker_from_nonlocal,","highlight_start":5,"highlight_end":30}],"label":"no `local_waker_from_nonlocal` in `task`","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[],"rendered":"error[E0432]: unresolved imports `std::task::LocalWaker`, `std::task::Wake`, `std::task::local_waker_from_nonlocal`\n  --> /checkout/src/test/run-pass/async-await.rs:12:5\n   |\nLL |     LocalWaker, Poll, Wake,\n   |     ^^^^^^^^^^        ^^^^ no `Wake` in `task`. Did you mean to use `Waker`?\n   |     |\n   |     no `LocalWaker` in `task`\nLL |     local_waker_from_nonlocal,\n   |     ^^^^^^^^^^^^^^^^^^^^^^^^^ no `local_waker_from_nonlocal` in `task`\n\n"}
[01:15:39] {"message":"For more information about this error, try `rustc --explain E0432`.","code":null,"level":"","spans":[],"children":[],"rendered":"For more information about this error, try `rustc --explain E0432`.\n"}
[01:15:39] 
[01:15:39] ------------------------------------------
[01:15:39] 
[01:15:39] 
[01:15:39] thread '[run-pass] run-pass/async-await.rs' panicked at 'explicit panic', src/tools/compiletest/src/runtest.rs:3291:9
[01:15:39] note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[01:15:39] 
[01:15:39] ---- [run-pass] run-pass/futures-api.rs stdout ----
[01:15:39] 
[01:15:39] error: test compilation failed although it shouldn't!
[01:15:39] status: exit code: 1
[01:15:39] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/run-pass/futures-api.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/futures-api/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/futures-api/auxiliary"
[01:15:39] ------------------------------------------
[01:15:39] 
[01:15:39] ------------------------------------------
[01:15:39] stderr:
[01:15:39] stderr:
[01:15:39] ------------------------------------------
[01:15:39] {"message":"unresolved imports `std::task::Wake`, `std::task::LocalWaker`, `std::task::local_waker`, `std::task::local_waker_from_nonlocal`","code":{"code":"E0432","explanation":"\nAn import was unresolved.\n\nErroneous code example:\n\n```compile_fail,E0432\nuse something::Foo; // error: unresolved import `something::Foo`.\n```\n\nPaths in `use` statements are relative to the crate root. To import items\nrelative to the current and parent modules, use the `self::` and `super::`\nprefixes, respectively. Also verify that you didn't misspell the import\nname and that the import exists in the module from where you tried to\nimport it. Example:\n\n```\nuse self::something::Foo; // ok!\n\nmod something {\n    pub struct Foo;\n}\n# fn main() {}\n```\n\nOr, if you tried to use a module from an external crate, you may have missed\nthe `extern crate` declaration (which is usually placed in the crate root):\n\n```\nextern crate core; // Required to use the `core` crate\n\nuse core::any;\n# fn main() {}\n```\n"},"level":"error","spans":[{"file_name":"/checkout/src/test/run-pass/futures-api.rs","byte_start":216,"byte_end":220,"line_start":12,"line_end":12,"column_start":11,"column_end":15,"is_primary":true,"text":[{"text":"    Poll, Wake, Waker, LocalWaker,","highlight_start":11,"highlight_end":15}],"label":"no `Wake` in `task`. Did you mean to use `Waker`?","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"/checkout/src/test/run-pass/futures-api.rs","byte_start":229,"byte_end":239,"line_start":12,"line_end":12,"column_start":24,"column_end":34,"is_primary":true,"text":[{"text":"    Poll, Wake, Waker, LocalWaker,","highlight_start":24,"highlight_end":34}],"label":"no `LocalWaker` in `task`","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"/checkout/src/test/run-pass/futures-api.rs","byte_start":245,"byte_end":256,"line_start":13,"line_end":13,"column_start":5,"column_end":16,"is_primary":true,"text":[{"text":"    local_waker, local_waker_from_nonlocal,","highlight_start":5,"highlight_end":16}],"label":"no `local_waker` in `task`","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"/checkout/src/test/run-pass/futures-api.rs","byte_start":258,"byte_end":283,"line_start":13,"line_end":13,"column_start":18,"column_end":43,"is_primary":true,"text":[{"text":"    local_waker, local_waker_from_nonlocal,","highlight_start":18,"highlight_end":43}],"label":"no `local_waker_from_nonlocal` in `task`","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[],"rendered":"error[E0432]: unresolved imports `std::task::Wake`, `std::task::LocalWaker`, `std::task::local_waker`, `std::task::local_waker_from_nonlocal`\n  --> /checkout/src/test/run-pass/futures-api.rs:12:11\n   |\nLL |     Poll, Wake, Waker, LocalWaker,\n   |           ^^^^         ^^^^^^^^^^ no `LocalWaker` in `task`\n   |           |\n   |           no `Wake` in `task`. Did you mean to use `Waker`?\nLL |     local_waker, local_waker_from_nonlocal,\n   |     ^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^ no `local_waker_from_nonlocal` in `task`\n   |     |\n   |     no `local_waker` in `task`\n\n"}
[01:15:39] {"message":"For more information about this error, try `rustc --explain E0432`.","code":null,"level":"","spans":[],"children":[],"rendered":"For more information about this error, try `rustc --explain E0432`.\n"}
[01:15:39] 
[01:15:39] ------------------------------------------
[01:15:39] 
---
[01:15:39] 
[01:15:39] thread 'main' panicked at 'Some tests failed', src/tools/compiletest/src/main.rs:495:22
[01:15:39] 
[01:15:39] 
[01:15:39] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/run-pass" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "run-pass" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-6.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "6.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[01:15:39] 
[01:15:39] 
[01:15:39] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:15:39] Build completed unsuccessfully in 0:11:02
[01:15:39] Build completed unsuccessfully in 0:11:02
[01:15:39] make: *** [check] Error 1
[01:15:39] Makefile:48: recipe for target 'check' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:00870028
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Wed Jan 30 10:55:31 UTC 2019
---
travis_time:end:173df634:start=1548845733247831665,finish=1548845733252722135,duration=4890470
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0ea2231b
$ 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

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)

bors · 2019-02-03T21:28:32Z

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

This change updates the future and task API as discussed in the stabilization RFC at rust-lang/rfcs#2592. Changes: - Replacing UnsafeWake with RawWaker and RawWakerVtable - Removal of LocalWaker - Removal of Arc-based Wake trait

Co-Authored-By: Matthias247 <matthias.einwag@live.com>

rust-highfive · 2019-02-03T22:55:16Z

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:01837f16:start=1549230507215870171,finish=1549230509419569502,duration=2203699331
$ 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
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-6.0
---
[01:00:56] .................................................................................................... 500/2946
[01:01:07] .................................................................................................... 600/2946
[01:01:22] .................................................................................................... 700/2946
[01:01:33] .................................................................................................... 800/2946
[01:01:42] ........................................F........................................................... 900/2946
[01:02:11] .................................................................................................... 1100/2946
[01:02:20] .................................................................................................... 1200/2946
[01:02:30] .................................................................................................... 1300/2946
[01:02:42] .................................................................................................... 1400/2946
---
[01:06:32] failures:
[01:06:32] 
[01:06:32] ---- [run-pass] run-pass/futures-api.rs stdout ----
[01:06:32] 
[01:06:32] error: test compilation failed although it shouldn't!
[01:06:32] status: exit code: 1
[01:06:32] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/run-pass/futures-api.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/futures-api/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/futures-api/auxiliary"
[01:06:32] ------------------------------------------
[01:06:32] 
[01:06:32] ------------------------------------------
[01:06:32] stderr:
[01:06:32] stderr:
[01:06:32] ------------------------------------------
[01:06:32] {"message":"cannot find trait `Wake` in this scope","code":{"code":"E0405","explanation":"\nThe code refers to a trait that is not in scope.\n\nErroneous code example:\n\n```compile_fail,E0405\nstruct Foo;\n\nimpl SomeTrait for Foo {} // error: trait `SomeTrait` is not in scope\n```\n\nPlease verify that the name of the trait wasn't misspelled and ensure that it\nwas imported. Example:\n\n```\n# #[cfg(for_demonstration_only)]\n// solution 1:\nuse some_file::SomeTrait;\n\n// solution 2:\ntrait SomeTrait {\n    // some functions\n}\n\nstruct Foo;\n\nimpl SomeTrait for Foo { // ok!\n    // implements functions\n}\n```\n"},"level":"error","spans":[{"file_name":"/checkout/src/test/run-pass/futures-api.rs","byte_start":1634,"byte_end":1638,"line_start":72,"line_end":72,"column_start":6,"column_end":10,"is_primary":true,"text":[{"text":"impl Wake for Counter {","highlight_start":6,"highlight_end":10}],"label":"not found in this scope","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[],"rendered":"error[E0405]: cannot find trait `Wake` in this scope\n  --> /checkout/src/test/run-pass/futures-api.rs:72:6\n   |\nLL | impl Wake for Counter {\n   |      ^^^^ not found in this scope\n\n"}
[01:06:32] {"message":"For more information about this error, try `rustc --explain E0405`.","code":null,"level":"","spans":[],"children":[],"rendered":"For more information about this error, try `rustc --explain E0405`.\n"}
[01:06:32] 
[01:06:32] ------------------------------------------
[01:06:32] 
---
[01:06:32] 
[01:06:32] thread 'main' panicked at 'Some tests failed', src/tools/compiletest/src/main.rs:502:22
[01:06:32] 
[01:06:32] 
[01:06:32] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/run-pass" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "run-pass" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-6.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "6.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[01:06:32] 
[01:06:32] 
[01:06:32] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:06:32] Build completed unsuccessfully in 0:10:45
[01:06:32] Build completed unsuccessfully in 0:10:45
[01:06:32] Makefile:48: recipe for target 'check' failed
[01:06:32] make: *** [check] Error 1
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:062f4139
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Sun Feb  3 22:55:11 UTC 2019

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)

src/libcore/task/wake.rs

cramertj · 2019-02-05T08:50:46Z

src/test/run-pass/async-await.rs

+unsafe fn increase_refcount<T: ArcWake>(data: *const()) {
+    // Retain Arc by creating a copy
+    let arc: Arc<T> = Arc::from_raw(data as *const T);
+    let arc_clone = arc.clone();


nit: if cloning the arc panics, the arc will be dropped, decreasing the refcount.

cramertj · 2019-02-05T08:52:08Z

src/test/run-pass/futures-api.rs

-struct Counter {
-    local_wakes: AtomicUsize,
-    nonlocal_wakes: AtomicUsize,
+macro_rules! waker_vtable {


Rather than redefining Wake and this waker_vtable macro in every separate test, i'd have one file define it and path-include that file.

I know, not happy with it either. However I only have no idea how the build and the conventions in this folder work. And since it takes 2 hours to get here, I couldn't really the spend time investigating it.
If anyone wants to push a commit which changes that part it would be great.

#[path = "./path/to/waker_api.rs"] mod waker; should work

I moved it to the auxilary directory which seems to be used by other tests. But maybe that's wrong. If noone can tell where exactly it should go I will revert that.

cramertj · 2019-02-05T08:52:43Z

This looks great! left a few small nits, but I'm excited to get this in :)

cramertj · 2019-02-05T13:13:56Z

After talking to @Centril I realized we could also keep the RawWaker fields private by adding a const fn constructor (this wasn't possible before because const fn wasn't stable).

Matthias247 · 2019-02-06T04:49:59Z

@cramertj , @Centril I like that idea, since it means we could extend RawWaker in the future if we find it insufficient. E.g. I'm still unsure whether a second pointer inside it wouldn't be helpful for some executors. Should I add const fn RawWaker::new(data: *const(), vtable: &'static RawWakerVTable)?

cramertj · 2019-02-06T09:42:59Z

@Matthias247 sounds good to me!

Matthias247 · 2019-02-07T07:00:00Z

@cramertj Updated. I was wondering if the function should be unsafe or not. I decided not, since the a user can't really do something unsafe with this RawWaker as long as it isn't converted into a Waker yet. And the Waker conversion function is already unsafe. However I'm also open to make this one unsafe too, which might leave more room for backward compatibility if we add functions directly to RawWaker later on.

Matthias247 · 2019-02-09T17:16:59Z

@GuillaumeGomez Sorry, I just it might save some work, and felt bad about removing tests. Let me know briefly if you still prefer the removal, then I will go for it.

GuillaumeGomez · 2019-02-09T19:49:42Z

I'd prefer that you removed the test (and please open an issue). I just opened #58330 so that we can test it without depending on the std.

Matthias247 · 2019-02-09T20:16:48Z

@cramertj , @Centril Please retry the merge

@GuillaumeGomez Alright, done. I opened the issue at #58331

GuillaumeGomez · 2019-02-09T23:39:57Z

@Matthias247 Thanks a lot!

cramertj · 2019-02-12T18:26:29Z

@bors r+

bors · 2019-02-12T18:26:30Z

📌 Commit 1ef34a5 has been approved by cramertj

bors · 2019-02-12T22:17:39Z

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

Matthias247 · 2019-02-13T17:06:07Z

@cramertj: can you please try again?

cramertj · 2019-02-13T17:55:48Z

@bors r+

bors · 2019-02-13T17:55:49Z

📌 Commit 871338c has been approved by cramertj

Update the future/task API This change updates the future and task API as discussed in the stabilization RFC at rust-lang/rfcs#2592. Changes: - Replacing UnsafeWake with RawWaker and RawWakerVtable - Removal of LocalWaker - Removal of Arc-based Wake trait

@ghost

Rollup of 8 pull requests Successful merges: - #57451 (suggestion-diagnostics: as_ref improve snippet) - #57856 (Convert old first edition links to current edition one) - #57992 (Update the future/task API) - #58258 (Reduce the size of `hir::Expr`.) - #58267 (Tweak "incompatible match arms" error) - #58296 (Hidden suggestion support) - #58301 (Enable comparing fat pointers) - #58308 (Extract block to insert an intrinsic into its own function) Failed merges: r? @ghost

rust-highfive assigned joshtriplett Jan 30, 2019

This comment has been minimized.

Sign in to view

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 30, 2019

rust-highfive assigned cramertj and unassigned joshtriplett Jan 30, 2019

Matthias247 mentioned this pull request Jan 30, 2019

Implements the waker changes for task API stabilization. rust-lang/futures-rs#1445

Merged

Centril reviewed Jan 30, 2019

View reviewed changes

josephg mentioned this pull request Jan 31, 2019

Support stablization track futures API Clikengo/foundationdb-rs#111

Closed

Matthias247 and others added 3 commits February 3, 2019 13:46

Update the future/task API

d9a4b22

This change updates the future and task API as discussed in the stabilization RFC at rust-lang/rfcs#2592. Changes: - Replacing UnsafeWake with RawWaker and RawWakerVtable - Removal of LocalWaker - Removal of Arc-based Wake trait

Apply suggestions from code review

01a704c

Co-Authored-By: Matthias247 <matthias.einwag@live.com>

Apply review suggestions and fix tests

9e6bc3c

Fix test

f005e1c

cramertj reviewed Feb 5, 2019

View reviewed changes

src/libcore/task/wake.rs Show resolved Hide resolved

cramertj reviewed Feb 5, 2019

View reviewed changes

src/libcore/task/wake.rs Show resolved Hide resolved

cramertj reviewed Feb 5, 2019

View reviewed changes

Matthias247 added 2 commits February 5, 2019 01:14

Apply more review suggestions

e1ec814

review suggestions

363e992

Move ArcWake in common test file.

8e7ef03

Change RawWaker constructor to const fn

a1c4cf6

Remove rustdoc test which referenced unstable API

1ef34a5

Matthias247 mentioned this pull request Feb 9, 2019

Fix rustdoc-js unit-test for substring after removal of unstable API #58331

Closed

Thomasdezeeuw mentioned this pull request Feb 10, 2019

Implement thread-local Waker Thomasdezeeuw/heph#51

Closed

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 12, 2019

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 12, 2019

Merging master

871338c

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 13, 2019

Centril mentioned this pull request Feb 14, 2019

Rollup of 8 pull requests #58446

Merged

bors merged commit 871338c into rust-lang:master Feb 14, 2019

yoshuawuyts mentioned this pull request Feb 19, 2019

nightly std library change breaks romio withoutboats/romio#65

Closed

fmckeogh mentioned this pull request Feb 20, 2019

Can't install tokio async await ( LocalWaker ) tokio-rs/tokio#908

Closed

taiki-e mentioned this pull request Feb 22, 2019

async-await: update to new future/task API tokio-rs/tokio#919

Merged

phil-opp mentioned this pull request Feb 22, 2019

Build currently fails due to invalid smoltcp branch embed-rs/stm32f7-discovery#79

Closed

cramertj mentioned this pull request Mar 11, 2019

Tracking issue for RFC 2592, futures_api #59113

Closed

5 tasks

tinco mentioned this pull request Mar 31, 2019

Update to latest nightly, removing LocalWaker and introducing ArcWake de-vri-es/back-to-the-future#1

Merged

		@@ -42,16 +42,16 @@ pub trait Future {
		/// Once a future has finished, clients should not `poll` it again.

Update the future/task API #57992

Update the future/task API #57992

Conversation

Matthias247 commented Jan 30, 2019

This comment has been minimized.

Centril commented Jan 30, 2019

Matthias247 commented Jan 30, 2019

Choose a reason for hiding this comment

Nemo157 Jan 30, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nemo157 Feb 4, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rust-highfive commented Jan 30, 2019

bors commented Feb 3, 2019

rust-highfive commented Feb 3, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cramertj commented Feb 5, 2019

cramertj commented Feb 5, 2019

Matthias247 commented Feb 6, 2019

cramertj commented Feb 6, 2019

Matthias247 commented Feb 7, 2019

Matthias247 commented Feb 9, 2019

GuillaumeGomez commented Feb 9, 2019

Matthias247 commented Feb 9, 2019

GuillaumeGomez commented Feb 9, 2019

cramertj commented Feb 12, 2019

bors commented Feb 12, 2019

bors commented Feb 12, 2019

Matthias247 commented Feb 13, 2019

cramertj commented Feb 13, 2019

bors commented Feb 13, 2019

Nemo157 Jan 30, 2019 •

edited

Loading

Nemo157 Feb 4, 2019 •

edited

Loading