New issue

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

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

Already on GitHub? Sign in to your account

Update the future/task API #57992

Merged
merged 10 commits into from Feb 14, 2019

Conversation

Projects
None yet
10 participants
@Matthias247
Copy link
Contributor

Matthias247 commented 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

This comment was marked as outdated.

Copy link
Collaborator

rust-highfive commented Jan 30, 2019

r? @joshtriplett

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

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Jan 30, 2019

@Matthias247

This comment has been minimized.

Copy link
Contributor Author

Matthias247 commented 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.

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

This comment has been minimized.

@Centril

Centril Jan 30, 2019

Contributor

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 comment has been minimized.

@Nemo157

Nemo157 Jan 30, 2019

Contributor

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.)

This comment has been minimized.

@Centril

Centril Jan 30, 2019

Contributor

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.

This comment has been minimized.

@Centril

Centril Jan 30, 2019

Contributor

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".

This comment has been minimized.

@Matthias247

Matthias247 Feb 3, 2019

Author Contributor

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.

This comment has been minimized.

@Nemo157

Nemo157 Feb 4, 2019

Contributor

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.

This comment has been minimized.

@Nemo157

Nemo157 Feb 4, 2019

Contributor

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.

This comment has been minimized.

@Matthias247

Matthias247 Feb 5, 2019

Author Contributor

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

/// 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

This comment has been minimized.

@Centril

Centril Jan 30, 2019

Contributor

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.

This comment has been minimized.

@Matthias247

Matthias247 Feb 3, 2019

Author Contributor

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.

This comment has been minimized.

@Centril

Centril Feb 5, 2019

Contributor

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.

This comment has been minimized.

@Matthias247

Matthias247 Feb 5, 2019

Author Contributor

done

/// [`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`),

This comment has been minimized.

@Centril

Centril Jan 30, 2019

Contributor

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

This comment has been minimized.

@Matthias247

Matthias247 Feb 3, 2019

Author Contributor

See comment above.

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

impl fmt::Debug for LocalWaker {
impl fmt::Debug for Waker {

This comment has been minimized.

@Centril

Centril Jan 30, 2019

Contributor

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

This comment has been minimized.

@Matthias247

Matthias247 Feb 3, 2019

Author Contributor

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.

This comment has been minimized.

@Nemo157

Nemo157 Feb 4, 2019

Contributor

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).

This comment has been minimized.

@cramertj

cramertj Feb 5, 2019

Member

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

This comment has been minimized.

@Centril

Centril Feb 5, 2019

Contributor

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

This comment has been minimized.

@Matthias247

Matthias247 Feb 5, 2019

Author Contributor

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

Show resolved Hide resolved src/libcore/task/wake.rs
Show resolved Hide resolved src/libcore/task/wake.rs
Show resolved Hide resolved src/libcore/task/wake.rs Outdated
@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented 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

This comment has been minimized.

Copy link
Contributor

bors commented Feb 3, 2019

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

Matthias247 and others added some commits Jan 30, 2019

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
Apply suggestions from code review
Co-Authored-By: Matthias247 <matthias.einwag@live.com>

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

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented 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)

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();

This comment has been minimized.

@cramertj

cramertj Feb 5, 2019

Member

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

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

This comment has been minimized.

@cramertj

cramertj Feb 5, 2019

Member

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.

This comment has been minimized.

@Matthias247

Matthias247 Feb 5, 2019

Author Contributor

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.

This comment has been minimized.

@cramertj

cramertj Feb 5, 2019

Member

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

This comment has been minimized.

@Matthias247

Matthias247 Feb 6, 2019

Author Contributor

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

This comment has been minimized.

Copy link
Member

cramertj commented Feb 5, 2019

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

Matthias247 added some commits Feb 5, 2019

@cramertj

This comment has been minimized.

Copy link
Member

cramertj commented 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

This comment has been minimized.

Copy link
Contributor Author

Matthias247 commented 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

This comment has been minimized.

Copy link
Member

cramertj commented Feb 6, 2019

@Matthias247 sounds good to me!

@GuillaumeGomez

This comment has been minimized.

Copy link
Member

GuillaumeGomez commented Feb 8, 2019

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

@Matthias247

This comment has been minimized.

Copy link
Contributor Author

Matthias247 commented Feb 9, 2019

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

@GuillaumeGomez

This comment has been minimized.

Copy link
Member

GuillaumeGomez commented Feb 9, 2019

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

@Matthias247

This comment has been minimized.

Copy link
Contributor Author

Matthias247 commented 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

This comment has been minimized.

Copy link
Member

GuillaumeGomez commented 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

This comment has been minimized.

Copy link
Contributor Author

Matthias247 commented Feb 9, 2019

@cramertj , @Centril Please retry the merge

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

@GuillaumeGomez

This comment has been minimized.

Copy link
Member

GuillaumeGomez commented Feb 9, 2019

@Matthias247 Thanks a lot!

@cramertj

This comment has been minimized.

Copy link
Member

cramertj commented Feb 12, 2019

@bors r+

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 12, 2019

📌 Commit 1ef34a5 has been approved by cramertj

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 12, 2019

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

@Matthias247

This comment has been minimized.

Copy link
Contributor Author

Matthias247 commented Feb 13, 2019

@cramertj: can you please try again?

@cramertj

This comment has been minimized.

Copy link
Member

cramertj commented Feb 13, 2019

@bors r+

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 13, 2019

📌 Commit 871338c has been approved by cramertj

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

Rollup merge of rust-lang#57992 - Matthias247:waker4, r=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

bors added a commit that referenced this pull request Feb 14, 2019

Auto merge of #58446 - Centril:rollup, r=Centril
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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment