This improves == for VecDeque by using the slice representation.
This will also improve further if codegen for slice comparison improves.
Benchmark run of 1000 u64 elements, comparing for equality (all equal).
Cpu time to compare the vecdeques is reduced to less than 50% of what it
was before.
```
test test_eq_u64 ... bench: 1,885 ns/iter (+/- 163) = 4244 MB/s
test test_eq_new_u64 ... bench: 802 ns/iter (+/- 100) = 9975 MB/s
```
Use .as_slices() for a more efficient code path in VecDeque's Hash impl.
This still hashes the elements in the same order.
Before/after timing of VecDeque hashing 1024 elements of u8 and
u64 shows that the vecdeque now can match the Vec
(test_hashing_vec_of_u64 is the Vec run).
before
test test_hashing_u64 ... bench: 14,031 ns/iter (+/- 236) = 583 MB/s
test test_hashing_u8 ... bench: 7,887 ns/iter (+/- 65) = 129 MB/s
test test_hashing_vec_of_u64 ... bench: 6,578 ns/iter (+/- 76) = 1245 MB/s
after
running 5 tests
test test_hashing_u64 ... bench: 6,495 ns/iter (+/- 52) = 1261 MB/s
test test_hashing_u8 ... bench: 851 ns/iter (+/- 16) = 1203 MB/s
test test_hashing_vec_of_u64 ... bench: 6,499 ns/iter (+/- 59) = 1260 MB/s
Use raw pointers to avoid aliasing in str::split_at_mut
Introduce private function from_raw_parts_mut for str to factor out the logic.
We want to use raw pointers here instead of duplicating a &mut str, to
be on safer ground w.r.t rust aliasing rules.
This has already been fixed for slices in PR #27358, issue #27357
Introduce private function from_raw_parts_mut for str to factor out the logic.
We want to use raw pointers here instead of duplicating a &mut str, to
be on safer ground w.r.t rust aliasing rules.
Use the fallback impl for memrchr on non-linux
The memrchr code was never used(!). This brings the memrchr improvements to
non-linux platforms (LineWriter / buffered stdout benefits).
Previous PR #30381
All structs and their constructors are defined as `DefStruct`.
`DefTy` is splitted into `DefEnum` and `DefTyAlias`.
Ad hoc flag `bool is_structure` is removed from `DefVariant`, it was required in one place in resolve and could be obtained by other means.
Flag `bool is_ctor` is removed from `DefFn`, it wasn't really used for constructors outside of metadata decoding.
Observable effects:
More specific error messages are selected in some cases.
Two name resolution bugs fixed (https://github.com/rust-lang/rust/issues/30992 and FIXME in compile-fail/empty-struct-braces-expr.rs).
Fixes https://github.com/rust-lang/rust/issues/30992
Closes https://github.com/rust-lang/rust/issues/30361
As an attempt to make loop body destination be optional, author implemented a pretty self contained
change and deemed it to be (much) uglier than the alternative of just keeping the unit temporary.
Having the temporary created lazily also has a nice property of not figuring in the MIR of
functions which do not use loops of any sort.
r? @nikomatsakis
We've been seeing a lot of timeouts in tests on the bots and investigation ended
pointing to jemalloc/jemalloc#315 as the culprit. Unfortunately it looks like
that doesn't seem to have a fix on the way soon, so let's temporarily downgrade
back to the previous version of jemalloc we were using (where #30434 was the
most recent upgrade)
The protocol for `serialize::{En,De}code` doesn't allow for two
integers to be serialized next to each other. This switches the
protocol to serializing `Span`s as a struct. rbml structs don't
have any overhead, so the metadata shouldn't increase in size,
but it allows the json format to be properly generated, albeit
slightly more heavy than when it was just serializing a span as
a u64.
Closes#31025.
s
We've been seeing a lot of timeouts in tests on the bots and investigation ended
pointing to jemalloc/jemalloc#315 as the culprit. Unfortunately it looks like
that doesn't seem to have a fix on the way soon, so let's temporarily downgrade
back to the previous version of jemalloc we were using (where #30434 was the
most recent upgrade)
Tracking issue: #30014
This implements the RFC and makes a few other changes.
I have added a few extra tests, and made the Windows and
Unix code as similar as possible.
Part of the RFC mentions the unstable OpenOptionsExt trait
on Windows (see #27720). I have added a few extra methods
to future-proof it for CreateFile2.
Minimal fix for https://github.com/rust-lang/rust/issues/30563
This covers all the public structs I think; except for Iter and
IntoIter, which I don't know if or how they should be handled.
An attempt to make loop body destination be optional, author implemented a pretty self contained
change and deemed it to be (much) uglier than the alternative of just keeping the unit temporary.
Having the temporary created lazily also has a nice property of not figuring in the MIR of
functions which do not use loops of any sort.