| Age | Commit message (Collapse) | Author | Lines |
|---|
|
std::ops::Try impl for std::task::Poll
I originally left out the `Try` impl for `Poll` because I was curious if we needed it, and @MajorBreakfast and I had discussed the potential for it to introduce confusion about exactly what control-flow was happening at different points. However, after porting a pretty significant chunk of Fuchsia over to futures 0.3, I discovered that I was *constantly* having to do repetitive matching on `Poll<Result<...>>` or `Poll<Option<Result<...>>>` in order to propagate errors correctly. `try_poll` (propagate `Poll::Ready(Err(..))`s) helped in some places, but it was far more common to need some form of conversion between `Result`, `Poll<Result<...>>`, and `Poll<Option<Result<...>>>`. The `Try` trait conveniently provides all of these conversions in addition to a more concise syntax (`?`), so I'd like to experiment with using these instead.
cc @seanmonstar
r? @aturon
Note: this change means that far more futures 0.1 code can work without significant changes since it papers over the fact that `Result` is no longer at the top-level when using `Stream` and `Future` (since it's now `Poll<Result<...>>` or `Poll<Option<Result<...>>>` instead of `Result<Poll<..>>` and `Result<Poll<Option<...>>>`).
|
|
Clarify what a task is
Currently we call two distinct concepts "task":
1. The top-level future that is polled until completion
2. The lightweight "thread" that is responsible for polling the top-level future. What additional data beside the future is stored in this type varies between different `Executor` implementations.
I'd prefer to return to the old formulation by @alexcrichton:
```rust
/// A handle to a "task", which represents a single lightweight "thread" of
/// execution driving a future to completion.
pub struct Task {
```
Source: [`task_impl/mod.rs` in futures-rs 0.1](https://github.com/rust-lang-nursery/futures-rs/blob/1328fc9e8af5737183df477c7501e6ea24ff2053/src/task_impl/mod.rs#L49-L50)
I think that this change will make it much easier to explain everything.
r? @aturon
@cramertj
|
|
|
|
|
|
|
|
|
|
|
|
|
|
clarify pointer offset function safety concerns
|
|
Prefer `Option::map`/etc over `match` wherever it improves clarity
This isn't intended to change behavior anywhere. A lot of times statements like `match x { None => None, Some(y) => [...] }` can be rewritten using `Option::map` or `Option::and_then` in a way that preserves or improves clarity, so that's what I've done here.
I think it's particularly valuable to keep things in `libcore` and `libstd` pretty/idiomatic since it's not uncommon to follow the `[src]` links when browsing the rust-lang.org docs for std/core. If there's any concern about pushing style-based changes though, I'll happily back out the non-std/core commits here.
|
|
impl PartialEq+Eq for BuildHasherDefault
`BuildHasherDefault`is only one way of implementing `BuildHasher`. Clearly, every `BuildHasherDefault` for the same type `H` is identical, since it just uses `Default<H>` to construct `H`. In general, this is not true for every `BuildHasher`, so I think it is helpful to implement `PartialEq` and `Eq`.
|
|
Add unaligned volatile intrinsics
Surprisingly enough, it turns out that unaligned volatile loads are actually useful for certain (very niche) types of lock-free code. I included unaligned volatile stores for completeness, but I currently do not know of any use cases for them.
These are only exposed as intrinsics for now. If they turn out to be useful in practice, we can work towards stabilizing them.
r? @alexcrichton
|
|
|
|
|
|
Forget Waker when cloning LocalWaker
Since NonNull is Copy the inner field of the cloned Waker was copied for
use in the new LocalWaker, however this left Waker to be dropped. Which
means that when cloning LocalWaker would also erroneously call drop_raw.
This change forgets the Waker, rather then dropping it, leaving the
inner field to be used by the returned LocalWaker.
Closes #52629.
|
|
Implement rfc 1789: Conversions from `&mut T` to `&Cell<T>`
I'm surprised that RFC 1789 has not been implemented for several months. Tracking issue: https://github.com/rust-lang/rust/issues/43038
Please note: when I was writing tests for `&Cell<[i32]>`, I found it is not easy to get the length of the contained slice. So I designed a `get_with` method which might be useful for similar cases. This method is not designed in the RFC, and it certainly needs to be reviewed by core team. I think it has some connections with `Cell::update` https://github.com/rust-lang/rust/issues/50186 , which is also in design phase.
|
|
|
|
Since NonNull is Copy the inner field of the cloned Waker was copied for
use in the new LocalWaker, however this left Waker to be dropped. Which
means that when cloning LocalWaker would also erroneously call drop_raw.
This change forgets the Waker, rather then dropping it, leaving the
inner field to be used by the returned LocalWaker.
Closes #52629.
|
|
mem::swap the obvious way for types smaller than the SIMD optimization's block size
LLVM isn't able to remove the alloca for the unaligned block in the post-SIMD tail in some cases, so doing this helps SRoA work in cases where it currently doesn't. Found in the `replace_with` RFC discussion.
Examples of the improvements:
<details>
<summary>swapping `[u16; 3]` takes 1/3 fewer instructions and no stackalloc</summary>
```rust
type Demo = [u16; 3];
pub fn swap_demo(x: &mut Demo, y: &mut Demo) {
std::mem::swap(x, y);
}
```
nightly:
```asm
_ZN4blah9swap_demo17ha1732a9b71393a7eE:
.seh_proc _ZN4blah9swap_demo17ha1732a9b71393a7eE
sub rsp, 32
.seh_stackalloc 32
.seh_endprologue
movzx eax, word ptr [rcx + 4]
mov word ptr [rsp + 4], ax
mov eax, dword ptr [rcx]
mov dword ptr [rsp], eax
movzx eax, word ptr [rdx + 4]
mov word ptr [rcx + 4], ax
mov eax, dword ptr [rdx]
mov dword ptr [rcx], eax
movzx eax, word ptr [rsp + 4]
mov word ptr [rdx + 4], ax
mov eax, dword ptr [rsp]
mov dword ptr [rdx], eax
add rsp, 32
ret
.seh_handlerdata
.section .text,"xr",one_only,_ZN4blah9swap_demo17ha1732a9b71393a7eE
.seh_endproc
```
this PR:
```asm
_ZN4blah9swap_demo17ha1732a9b71393a7eE:
mov r8d, dword ptr [rcx]
movzx r9d, word ptr [rcx + 4]
movzx eax, word ptr [rdx + 4]
mov word ptr [rcx + 4], ax
mov eax, dword ptr [rdx]
mov dword ptr [rcx], eax
mov word ptr [rdx + 4], r9w
mov dword ptr [rdx], r8d
ret
```
</details>
<details>
<summary>`replace_with` optimizes down much better</summary>
Inspired by https://github.com/rust-lang/rfcs/pull/2490,
```rust
fn replace_with<T, F>(x: &mut Option<T>, f: F)
where F: FnOnce(Option<T>) -> Option<T>
{
*x = f(x.take());
}
pub fn inc_opt(mut x: &mut Option<i32>) {
replace_with(&mut x, |i| i.map(|j| j + 1));
}
```
Rust 1.26.0:
```asm
_ZN4blah7inc_opt17heb0acb64c51777cfE:
mov rax, qword ptr [rcx]
movabs r8, 4294967296
add r8, rax
shl rax, 32
movabs rdx, -4294967296
and rdx, r8
xor r8d, r8d
test rax, rax
cmove rdx, rax
setne r8b
or rdx, r8
mov qword ptr [rcx], rdx
ret
```
Nightly (better thanks to ScalarPair, maybe?):
```asm
_ZN4blah7inc_opt17h66df690be0b5899dE:
mov r8, qword ptr [rcx]
mov rdx, r8
shr rdx, 32
xor eax, eax
test r8d, r8d
setne al
add edx, 1
mov dword ptr [rcx], eax
mov dword ptr [rcx + 4], edx
ret
```
This PR:
```asm
_ZN4blah7inc_opt17h1426dc215ecbdb19E:
xor eax, eax
cmp dword ptr [rcx], 0
setne al
mov dword ptr [rcx], eax
add dword ptr [rcx + 4], 1
ret
```
Where that add is beautiful -- using an addressing mode to not even need to explicitly go through a register -- and the remaining imperfection is well-known (https://github.com/rust-lang/rust/pull/49420#issuecomment-376805721).
</details>
|
|
Avoid using `#[macro_export]` for documenting builtin macros
Use a special `rustc_*` attribute instead.
cc https://github.com/rust-lang/rust/pull/52234
|
|
Document that Unique::empty() and NonNull::dangling() aren't sentinel values
The documentation of Unique::empty() and NonNull::dangling() could
potentially suggest that they work as sentinel values indicating a
not-yet-initialized pointer. However, they both declare a non-null
pointer equal to the alignment of the type, which could potentially
reference a valid value of that type (specifically, the first such valid
value in memory). Explicitly document that the return value of these
functions does not work as a sentinel value.
|
|
Deprecation of str::slice_unchecked(_mut)
Closes #51715
I am not sure if 1.28.0 or 1.29.0 should be used for deprecation version, for now it's 1.28.0.
Additionally I've replaced `slice_unchecked` uses with `get_unchecked`. The only places where this method is still used are `src/liballoc/tests/str.rs` and `src/liballoc/tests/str.rs`.
|
|
LLVM isn't able to remove the alloca for the unaligned block in the SIMD tail in some cases, so doing this helps SRoA work in cases where it currently doesn't. Found in the `replace_with` RFC discussion.
|
|
Update stdsimd to undo an accidental stabilization
Closes #52403
|
|
Closes #52403
|
|
|
|
fix unsafety: don't call ptr_rotate for ZST
`rotate::ptr_rotate` has a comment saying
```
/// # Safety
///
/// The specified range must be valid for reading and writing.
/// The type `T` must have non-zero size.
```
So we better make sure we don't call it on ZST...
Cc @scottmcm (author of https://github.com/rust-lang/rust/pull/41670)
|
|
|
|
The documentation of Unique::empty() and NonNull::dangling() could
potentially suggest that they work as sentinel values indicating a
not-yet-initialized pointer. However, they both declare a non-null
pointer equal to the alignment of the type, which could potentially
reference a valid value of that type (specifically, the first such valid
value in memory). Explicitly document that the return value of these
functions does not work as a sentinel value.
|
|
Clarify short-circuiting behvaior of Iterator::zip.
Fixes https://github.com/rust-lang/rust/issues/52279.
|
|
Amend option.take examples
It wasn't abundantly clear to me what `.take` returned. Perhaps this is a slightly frivolous change, but I think it's an improvement. =)
Apologies if I'm not following proper procedures.
|
|
Handle array manually in str case conversion methods
Avoiding the overhead incurred from `String.extend(char.to_lowercase())` showed a notable performance improvement when I benchmarked it.
I tested on these strings:
```rust
ALL_LOWER: "loremipsumdolorsitametduosensibusmnesarchumabcdefgh"
ALL_UPPER: "LOREMIPSUMDOLORSITAMETDUOSENSIBUSMNESARCHUMABCDEFGH"
REALISTIC_UPPER: "LOREM IPSUM DOLOR SIT AMET, DUO SENSIBUS MNESARCHUM"
SIGMAS: "ΣΣΣΣΣ ΣΣΣΣΣ ΣΣΣΣΣ ΣΣΣ ΣΣΣΣ, ΣΣΣ ΣΣΣΣΣΣΣΣ ΣΣΣΣΣΣΣΣΣΣ"
WORD_UPPER: "Lorem Ipsum Dolor Sit Amet, Duo Sensibus Mnesarchum"
```
the performance improvements of `to_lowercase()` were
```
running 10 tests
test tests::all_lower ... bench: 1,752 ns/iter (+/- 49)
test tests::all_lower_new ... bench: 1,266 ns/iter (+/- 15) -28%
test tests::all_upper ... bench: 1,832 ns/iter (+/- 39)
test tests::all_upper_new ... bench: 1,337 ns/iter (+/- 18) -27%
test tests::realistic_upper ... bench: 1,993 ns/iter (+/- 14)
test tests::realistic_upper_new ... bench: 1,445 ns/iter (+/- 22) -27%
test tests::sigmas ... bench: 1,342 ns/iter (+/- 39)
test tests::sigmas_new ... bench: 1,226 ns/iter (+/- 16) -9%
test tests::word_upper ... bench: 1,899 ns/iter (+/- 12)
test tests::word_upper_new ... bench: 1,381 ns/iter (+/- 26) -27%
```
and of `to_uppercase()`
```
running 10 tests
test tests::all_lower ... bench: 1,813 ns/iter (+/- 20)
test tests::all_lower_new ... bench: 1,321 ns/iter (+/- 16) -27%
test tests::all_upper ... bench: 1,629 ns/iter (+/- 22)
test tests::all_upper_new ... bench: 1,241 ns/iter (+/- 9) -24%
test tests::realistic_upper ... bench: 1,670 ns/iter (+/- 24)
test tests::realistic_upper_new ... bench: 1,241 ns/iter (+/- 17) -26%
test tests::sigmas ... bench: 2,053 ns/iter (+/- 20)
test tests::sigmas_new ... bench: 1,753 ns/iter (+/- 23) -15%
test tests::word_upper ... bench: 1,873 ns/iter (+/- 30)
test tests::word_upper_new ... bench: 1,412 ns/iter (+/- 25) -25%
```
I gave up on the more advanced method from #52061 as it wasn't always a clear improvement and would help in even less cases if this PR was merged.
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/52279.
|
|
Fix doc link
Result of first searching via:
find src -type f -exec fgrep -l dynamically-sized-types--sized {} \;
and then replacing all relevant occurrences via:
find src/{libcore,test/ui} -type f -exec sed -i.bak \
s/dynamically-sized-types--sized/dynamically-sized-types-and-sized/g {} \;
find src -type f -name '*.bak' -exec rm {} \;
(Note: Commands run on macOS 10.13 (BSD). `sed -i.bak` should work on
GNU/Linux as well, but not tested.)
EDIT: Did not compile / test Rust for this change at all.
Clickable links for comparison:
https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types--sized (broken)
https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types-and-sized (fixed)
|
|
The link for comparison:
- https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types--sized (broken)
- https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types-and-sized (fixed)
This commit is the result of (first) searching via:
find src -type f -print0 | xargs -0 fgrep -l dynamically-sized-types--sized
and then replacing all relevant occurrences via:
find src/{libcore,test/ui} -type f -print0 | xargs -0 sed -i.bak \
s/dynamically-sized-types--sized/dynamically-sized-types-and-sized/g
find src/{libcore,test/ui} -type f -name '*.bak' -print0 | xargs -0 rm
(Note: Commands run on macOS 10.13 (BSD). `sed -i.bak` should work on
GNU/Linux as well, but not tested.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
AsRef doc wording tweaks
|
|
|
|
|
|
|
|
Now also the documentations of `subsec_millis`, `subsec_micros`, `as_millis` and `as_micros` make clear that the fractional nanosecond component is rounded down to whole units.
|
|
task: remove wrong comments about non-existent LocalWake trait
~~A `LocalWaker` is specifically `!Send `, and the unsafety comment around
`LocalWaker::new` only specifies that it be safe to call `wake_local`.
One could then accidentally promote a `LocalWaker` into a `Waker`, which
is universally `Send`, simply via `Waker::from(local_waker)`. A
`LocalWaker` the was built expecting to not be `Send`, such as using
`Rc`, could be sent to other threads safely.~~
~~Separately, though somewhat related, `Context` holds a `&LocalWaker`
internally, and exposes a `waker() -> &Waker` method. This simply
transmutes the `&LocalWaker` to `&Waker`, which would be unsound, except
that you can't "send" a `&Waker`, you'd need to clone it first. Since
`UnsafeWake::clone_raw` requires that it return a `Waker`, the transmute
is not unsound. The transmuted `LocalWaker` will be promoted to a
`Waker` correctly.~~
~~That would mean that if `UnsafeWake::clone_raw` were to be changed, such
as returning `Self` instead of `Waker`, this would no longer be sound.
Thus, this also adds a comment to `clone_raw` to remember this.~~
r? @cramertj
|
