Added blank lines around example
Added comment to Add example referencing the Output type
Removed whitespace from lines 272 and 273
Removed Debug derivation from Add examples
Added Debug derivation
Make [u8]::reverse() 5x faster
Since LLVM doesn't vectorize the loop for us, do unaligned reads of a larger type and use LLVM's bswap intrinsic to do the reversing of the actual bytes. cfg!-restricted to x86 and x86_64, as I assume it wouldn't help on things like ARMv5.
Also makes [u16]::reverse() a more modest 1.5x faster by loading/storing u32 and swapping the u16s with ROT16.
Thank you ptr::*_unaligned for making this easy :)
Benchmark results (from my i5-2500K):
```text
# Before
test slice::reverse_u8 ... bench: 273,836 ns/iter (+/- 15,592) = 3829 MB/s
test slice::reverse_u16 ... bench: 139,793 ns/iter (+/- 17,748) = 7500 MB/s
test slice::reverse_u32 ... bench: 74,997 ns/iter (+/- 5,130) = 13981 MB/s
test slice::reverse_u64 ... bench: 47,452 ns/iter (+/- 2,213) = 22097 MB/s
# After
test slice::reverse_u8 ... bench: 52,170 ns/iter (+/- 3,962) = 20099 MB/s
test slice::reverse_u16 ... bench: 93,330 ns/iter (+/- 4,412) = 11235 MB/s
test slice::reverse_u32 ... bench: 74,731 ns/iter (+/- 1,425) = 14031 MB/s
test slice::reverse_u64 ... bench: 47,556 ns/iter (+/- 3,025) = 22049 MB/s
```
If you're curious about the assembly, instead of doing this
```
movzx eax, byte ptr [rdi]
movzx ecx, byte ptr [rsi]
mov byte ptr [rdi], cl
mov byte ptr [rsi], al
```
it does this
```
mov rax, qword ptr [rdx]
mov rbx, qword ptr [r11 + rcx - 8]
bswap rbx
mov qword ptr [rdx], rbx
bswap rax
mov qword ptr [r11 + rcx - 8], rax
```
The documentation for flt2dec doesn't match up with the actual
implementation, so fix the documentation to align with reality.
Presumably due to the mismatch, the formatting code for floats in
std::fmt can use correspondingly shorter arrays in some places, so fix
those places up as well.
Fixes#41304.
refactor NonZero, Shared, and Unique APIs
Major difference is that I removed Deref impls, as apparently LLVM has
trouble maintaining metadata with a `&ptr -> &ptr` API. This was cited
as a blocker for ever stabilizing this API. It wasn't that ergonomic
anyway.
* Added `get` to NonZero to replace Deref impl
* Added `ptr` getter to Shared/Unique to replace Deref impl
* Added Unique's `get` and `get_mut` conveniences to Shared
* Deprecated `as_mut_ptr` on Shared in favour of `ptr`
Note that Shared used to primarily expose only `*const` but there isn't
a good justification for that, so I made it `*mut`.
Since LLVM doesn't vectorize the loop for us, do unaligned reads
of a larger type and use LLVM's bswap intrinsic to do the
reversing of the actual bytes. cfg!-restricted to x86 and
x86_64, as I assume it wouldn't help on things like ARMv5.
Also makes [u16]::reverse() a more modest 1.5x faster by
loading/storing u32 and swapping the u16s with ROT16.
Thank you ptr::*_unaligned for making this easy :)
Major difference is that I removed Deref impls, as apparently LLVM has
trouble maintaining metadata with a `&ptr -> &ptr` API. This was cited
as a blocker for ever stabilizing this API. It wasn't that ergonomic
anyway.
* Added `get` to NonZero to replace Deref impl
* Added `as_ptr` to Shared/Unique to replace Deref impl
* Added Unique's `as_ref` and `as_mut` conveniences to Shared
* Added `::empty()` convenience constructor for Unique/Shared
* Deprecated `as_mut_ptr` on Shared in favour of `as_ptr`
* Improved documentation of types
Note that Shared now only refers to *mut, and not *const
process:exit -> process::exit in mem::forget docs
The documentation in mem::forget says "...or call `process:exit`..."
instead of `process::exit`.
r? @steveklabnik
reduce stack requirements for floating-point formatting
Doing this speeds up float formatting by ~10% or so, and also makes the formatting code more suitable for embedded environments where stack space is at a premium.
We've got a freshly minted beta compiler, let's update to use that on nightly!
This has a few other changes associated with it as well
* A bump to the rustc version number (to 1.19.0)
* Movement of the `cargo` and `rls` submodules to their "proper" location in
`src/tools/{cargo,rls}`. Now that Cargo workspaces support the `exclude`
option this can work.
* Updates of the `cargo` and `rls` submodules to their master branches.
* Tweak to the `src/stage0.txt` format to be more amenable for Cargo version
numbers. On the beta channel Cargo will bootstrap from a different version
than rustc (e.g. the version numbers are different), so we need different
configuration for this.
* Addition of `dev` as a readable key in the `src/stage0.txt` format. If present
then stage0 compilers are downloaded from `dev-static.rust-lang.org` instead
of `static.rust-lang.org`. This is added to accomodate our updated release
process with Travis and AppVeyor.
The comments for flt2dec::to_shortest_str says that we only need a slice
of length 5 for the parts array. Initializing a 16-part array is just
wasted effort and wasted stack space. Other functions in the flt2dec
module have similar comments, so we adjust the parts arrays passed to
those functions accordingly.
For the two major entry points for float formatting, we split the exact
case and the shortest cases into separate functions. We mark the
separate functions as #[inline(never) so the exact cases won't bloat
stack space in their callers unnecessarily. The shortest cases are
marked so for similar reasons.
Fixes#41234.
We have benchmarks for the floating-point formatting algorithms
themselves, but not for the surrounding machinery like Formatter and
translating to the flt2dec::Part slices.
rustc: replace TypeContents with two independent properties (is_freeze / needs_drop).
`InteriorUnsafe` / `interior_unsafe` was replaced with a private lang-item `Freeze` auto trait in libcore.
`OwnsDtor` / `needs_drop` was replaced with a specialized traversal that *doesn't* avoid caching results in case of a cycle, as the only cycles left can only occur in erroneous "types with infinite sizes", references and raw pointers not having destructors. Also, `Copy` is now checked at every step of the recursion.
r? @nikomatsakis
