diff options
| author | bors <bors@rust-lang.org> | 2019-04-20 09:30:51 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2019-04-20 09:30:51 +0000 |
| commit | 647a951b084e5718b37bb97cd36760918e37c2f0 (patch) | |
| tree | f4a1f589c7e1fd6dab52380d21076ecf56f88441 /src/libsyntax | |
| parent | 775486589279430b4c9ebe7c1aac6017563c853a (diff) | |
| parent | f8f02debbb9a163420c86689b13cf144207381aa (diff) | |
| download | rust-647a951b084e5718b37bb97cd36760918e37c2f0.tar.gz rust-647a951b084e5718b37bb97cd36760918e37c2f0.zip | |
Auto merge of #60128 - jimblandy:futures-doc-fix, r=withoutboats
Doc fixes for core::future::Future. Fixed outdated reference to `waker` argument; now futures are passed a `Context`, from which one can obtain a `waker`. Cleaned up explanation of what happens when you call `poll` on a completed future. It doesn't make sense to say that `poll` implementations can't cause memory unsafety; no safe function is ever allowed to cause memory unsafety, so why mention it here? It seems like the intent is to say that the `Future` trait doesn't say what the consequences of excess polls will be, and they might be bad; but that the usual constraints that Rust imposes on any non-`unsafe` function still apply. It's also oddly specific to say 'memory corruption' instead of just 'undefined behavior'; UB is a bit jargony, so the text should provide examples.
Diffstat (limited to 'src/libsyntax')
0 files changed, 0 insertions, 0 deletions
