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.
Responding to [a thread of discussion on the Rust
subreddit](https://www.reddit.com/r/rust/comments/3racik/mutable_lifetimes_are_too_long_when_matching_an/),
it was identified that the presence of the Entry API is not duly
publicised. This commit aims to add some reasonable examples of
common usages of this API to the main example secion of the `HashMap`
documentation.
This is part of issue #29348.
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.
Documentation of `CStr::from_ptr` suggests using `str::from_utf8(slice.to_bytes()).unwrap()`
to obtain a `&str` but `CStr` has `CStr::to_str` that does exactly that.
Fix spacing style of `T: Bound` in docs
The space between `T` and `Bound` is the typical style used in code and
produced by rustdoc's rendering. Fixed first in Reflect's docs and then
I fixed all occurrences in docs I could find.
Sorry for nitpicking, but I think the example of the expanded macro should be wrapped inside a pair of curly braces to match the macro definition. Also the current example triggers a variable redefinition error.
We currently pass generic as the CPU to LLVM. This results in worse
than required code generation. On little endian, which is only POWER8,
we avoid many POWER4 and newer instructions.
Pass ppc64 and ppc64le instead.
Restore indexed formulation of clone_from_slice
For good codegen here, we need a lock step iteration where the loop
bound is only checked once per iteration; .zip() unfortunately does not
optimize this way.
If we use a counted loop, and make sure that llvm sees that the bounds
check condition is the same as the loop bound condition, the bounds
checks are optimized out. For this reason we need to slice `from`
(apparently) redundantly.
This commit restores the old formulation of clone_from_slice. In this
shape, clone_from_slice will again optimize into calling memcpy where possible
(for example for &[u8] or &[i32]).
