Update the future/task API #57992

Matthias247 · Jan 30, 2019

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

rust-highfive · Jan 30, 2019

r? @joshtriplett

(rust_highfive has picked a reviewer for you, use r? to override)

Centril · Jan 30, 2019

r? @cramertj

Matthias247 · Jan 30, 2019

@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 · Jan 30, 2019

Centril reviewed Jan 30, 2019

View changes

Centril · Jan 30, 2019

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 · Jan 30, 2019

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 · Jan 30, 2019

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 · Jan 30, 2019

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 · Jan 30, 2019

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 · Feb 3, 2019

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

rust-highfive · Feb 3, 2019

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)

cramertj · Feb 5, 2019

cramertj reviewed Feb 5, 2019

View changes

src/libcore/task/wake.rs

cramertj · Feb 5, 2019

cramertj reviewed Feb 5, 2019

View changes

src/libcore/task/wake.rs

cramertj · Feb 5, 2019

cramertj reviewed Feb 5, 2019

View changes

cramertj · Feb 5, 2019

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 · Feb 5, 2019

cramertj reviewed Feb 5, 2019

View changes

cramertj · Feb 5, 2019

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 · Feb 5, 2019

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

cramertj · Feb 5, 2019

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 · Feb 6, 2019

@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 · Feb 6, 2019

@Matthias247 sounds good to me!

GuillaumeGomez · Feb 8, 2019

Then remove the test and please add an issue about checking substrings in rustdoc search (and assign it to me).

Matthias247 · Feb 9, 2019

@cramertj Can you try running it again. I tried to fix it by using another function

GuillaumeGomez · Feb 9, 2019

@Matthias247 removing the tests and opening the issue so I could prevent further errors would have been better but whatever...

Matthias247 · Feb 9, 2019

@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 · Feb 9, 2019

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 · Feb 9, 2019

@cramertj , @Centril Please retry the merge

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

GuillaumeGomez · Feb 9, 2019

@Matthias247 Thanks a lot!

cramertj · Feb 12, 2019

@bors r+

bors · Feb 12, 2019

📌 Commit 1ef34a5 has been approved by cramertj

bors · Feb 12, 2019

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

Matthias247 · Feb 13, 2019

@cramertj: can you please try again?

cramertj · Feb 13, 2019

@bors r+

bors · Feb 13, 2019

📌 Commit 871338c has been approved by cramertj

rust-highfive assigned joshtriplett Jan 30, 2019

rust-highfive added the S-waiting-on-review label Jan 30, 2019

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

Matthias247 referenced this pull request Jan 30, 2019
Merged
Implements the waker changes for task API stabilization. #1445

josephg referenced this pull request Jan 31, 2019
Open
Support stablization track futures API #111

Matthias247 force-pushed the Matthias247:waker4 branch from 4f7e602 to 9e6bc3c Feb 3, 2019

Fix test

Loading status checks…

f005e1c

Matthias247 added some commits Feb 5, 2019

Apply more review suggestions

Loading status checks…

e1ec814

review suggestions

Loading status checks…

363e992

Move ArcWake in common test file.

Loading status checks…

8e7ef03

Change RawWaker constructor to const fn

Loading status checks…

a1c4cf6

Remove rustdoc test which referenced unstable API

Loading status checks…

1ef34a5

Matthias247 force-pushed the Matthias247:waker4 branch from b5c2660 to 1ef34a5 Feb 9, 2019

Matthias247 referenced this pull request Feb 9, 2019
Open
Fix rustdoc-js unit-test for substring after removal of unstable API #58331

bors added S-waiting-on-bors and removed S-waiting-on-author labels Feb 12, 2019

bors added S-waiting-on-author and removed S-waiting-on-bors labels Feb 12, 2019

Merging master

Loading status checks…

871338c

bors added S-waiting-on-bors and removed S-waiting-on-author labels Feb 13, 2019

Centril referenced this pull request Feb 14, 2019
Merged
Rollup of 8 pull requests #58446

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

yoshuawuyts referenced this pull request Feb 19, 2019
Closed
nightly std library change breaks romio #65

chocol4te referenced this pull request Feb 20, 2019
Open
Can't install tokio async await ( LocalWaker ) #908

taiki-e referenced this pull request Feb 22, 2019
Open
async-await: update to new future/task API #919

rust-lang/rust

Join GitHub today

Update the future/task API #57992

Conversation

Matthias247 commented Jan 30, 2019

rust-highfive assigned joshtriplett Jan 30, 2019

This comment was marked as outdated.

rust-highfive commented Jan 30, 2019

rust-highfive added the S-waiting-on-review label Jan 30, 2019

This comment has been minimized.

Centril commented Jan 30, 2019

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

This comment has been minimized.

Matthias247 commented Jan 30, 2019

Matthias247 referenced this pull request Jan 30, 2019

Centril reviewed Jan 30, 2019 View changes

This comment has been minimized.

This comment has been minimized.

Nemo157 Jan 30, 2019 • edited

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Nemo157 Feb 4, 2019 • edited

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

rust-highfive commented Jan 30, 2019

josephg referenced this pull request Jan 31, 2019

This comment has been minimized.

bors commented Feb 3, 2019

Matthias247 and others added some commits Jan 30, 2019

Matthias247 force-pushed the Matthias247:waker4 branch from 4f7e602 to 9e6bc3c Feb 3, 2019

This comment has been minimized.

rust-highfive commented Feb 3, 2019

cramertj reviewed Feb 5, 2019 View changes

cramertj reviewed Feb 5, 2019 View changes

cramertj reviewed Feb 5, 2019 View changes

This comment has been minimized.

cramertj reviewed Feb 5, 2019 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

cramertj commented Feb 5, 2019

Matthias247 added some commits Feb 5, 2019

This comment has been minimized.

cramertj commented Feb 5, 2019

This comment has been minimized.

Matthias247 commented Feb 6, 2019

This comment has been minimized.

cramertj commented Feb 6, 2019

This comment has been minimized.

GuillaumeGomez commented Feb 8, 2019 • edited

This comment has been minimized.

Matthias247 commented Feb 9, 2019 • edited

This comment has been minimized.

GuillaumeGomez commented Feb 9, 2019

This comment has been minimized.

Matthias247 commented Feb 9, 2019

This comment has been minimized.

GuillaumeGomez commented Feb 9, 2019

Matthias247 force-pushed the Matthias247:waker4 branch from b5c2660 to 1ef34a5 Feb 9, 2019

Matthias247 referenced this pull request Feb 9, 2019

This comment has been minimized.

Matthias247 commented Feb 9, 2019

This comment has been minimized.

Centril reviewed Jan 30, 2019

View changes

Nemo157 Jan 30, 2019 •

edited

Nemo157 Feb 4, 2019 •

edited

Matthias247 force-pushed the Matthias247:waker4 branch from `4f7e602` to `9e6bc3c` Feb 3, 2019

cramertj reviewed Feb 5, 2019

View changes

cramertj reviewed Feb 5, 2019

View changes

cramertj reviewed Feb 5, 2019

View changes

cramertj reviewed Feb 5, 2019

View changes

GuillaumeGomez commented Feb 8, 2019 •

edited

Matthias247 commented Feb 9, 2019 •

edited

Matthias247 force-pushed the Matthias247:waker4 branch from `b5c2660` to `1ef34a5` Feb 9, 2019

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