The first paragraph of the docs of the Cursor struct contains a Markdown
link. In listings, this won't get rendered. (Rustdoc seems to split off the
first paragraph and after that convert Markdown to HTML.)
Improve siphash performance for longer data
Use `ptr::copy_nonoverlapping` (aka memcpy) to load an u64 from the
byte stream. This is correct for any alignment, and the compiler will
use the appropriate instruction to load the data.
Also contains small tweaks that should benefit hashing short data too,
both the commit that removes a variable and the autovectorization of
the hash state initialization (in SipHash::reset).
Benchmarks show that hashing longer data benefits for the improved word loading.
Before (using benchmarks from the first commit in the PR):
The before benchmark is a bit noisy.
```
test hash::sip::bench_bytes_4 ... bench: 41 ns/iter (+/- 0) = 97 MB/s
test hash::sip::bench_bytes_7 ... bench: 49 ns/iter (+/- 2) = 142 MB/s
test hash::sip::bench_bytes_8 ... bench: 42 ns/iter (+/- 4) = 190 MB/s
test hash::sip::bench_bytes_a_16 ... bench: 57 ns/iter (+/- 14) = 280 MB/s
test hash::sip::bench_bytes_b_32 ... bench: 85 ns/iter (+/- 74) = 376 MB/s
test hash::sip::bench_bytes_c_128 ... bench: 278 ns/iter (+/- 33) = 460 MB/s
test hash::sip::bench_long_str ... bench: 825 ns/iter (+/- 103)
test hash::sip::bench_str_of_8_bytes ... bench: 151 ns/iter (+/- 66)
test hash::sip::bench_str_over_8_bytes ... bench: 59 ns/iter (+/- 3)
test hash::sip::bench_str_under_8_bytes ... bench: 47 ns/iter (+/- 56)
test hash::sip::bench_u32 ... bench: 39 ns/iter (+/- 93) = 205 MB/s
test hash::sip::bench_u32_keyed ... bench: 40 ns/iter (+/- 88) = 200 MB/s
test hash::sip::bench_u64 ... bench: 54 ns/iter (+/- 96) = 148 MB/s
```
After:
```
test hash::sip::bench_bytes_4 ... bench: 41 ns/iter (+/- 3) = 97 MB/s
test hash::sip::bench_bytes_7 ... bench: 48 ns/iter (+/- 0) = 145 MB/s
test hash::sip::bench_bytes_8 ... bench: 35 ns/iter (+/- 1) = 228 MB/s
test hash::sip::bench_bytes_a_16 ... bench: 45 ns/iter (+/- 1) = 355 MB/s
test hash::sip::bench_bytes_b_32 ... bench: 60 ns/iter (+/- 0) = 533 MB/s
test hash::sip::bench_bytes_c_128 ... bench: 161 ns/iter (+/- 5) = 795 MB/s
test hash::sip::bench_long_str ... bench: 514 ns/iter (+/- 5)
test hash::sip::bench_str_of_8_bytes ... bench: 44 ns/iter (+/- 0)
test hash::sip::bench_str_over_8_bytes ... bench: 51 ns/iter (+/- 0)
test hash::sip::bench_str_under_8_bytes ... bench: 52 ns/iter (+/- 6)
test hash::sip::bench_u32 ... bench: 40 ns/iter (+/- 2) = 200 MB/s
test hash::sip::bench_u32_keyed ... bench: 39 ns/iter (+/- 1) = 205 MB/s
test hash::sip::bench_u64 ... bench: 36 ns/iter (+/- 1) = 222 MB/s
```
Many of these have long since reached their stage of being obsolete, so this
commit starts the removal process for all of them. The unstable features that
were deprecated are:
* box_heap
* cmp_partial
* fs_time
* hash_default
* int_slice
* iter_min_max
* iter_reset_fuse
* iter_to_vec
* map_in_place
* move_from
* owned_ascii_ext
* page_size
* read_and_zero
* scan_state
* slice_chars
* slice_position_elem
* subslice_offset
Many of these have long since reached their stage of being obsolete, so this
commit starts the removal process for all of them. The unstable features that
were deprecated are:
* cmp_partial
* fs_time
* hash_default
* int_slice
* iter_min_max
* iter_reset_fuse
* iter_to_vec
* map_in_place
* move_from
* owned_ascii_ext
* page_size
* read_and_zero
* scan_state
* slice_chars
* slice_position_elem
* subslice_offset
Visual Studio 2015, recently released, includes the Universal CRT, a different
flavor than was provided before. The binaries and header files for this library
are included in new locations not previously known about by gcc-rs, and this
commit adds support for the necessary probing to find these.
Unfortunately there are no prior examples of this probing to be found in
frameworks like CMake or clang, so this is done is a bit of a sketchy method
today. It assumes that the installation is in a relatively standard format and
then blindly looks for the location of the UCRT. I'd love to switch this over to
using registry keys for probing, but I was currently unable to find such keys.
This should enable the compiler to work outside VS 2015 dev tools prompts.
These aren't really used for anything any more, so there doesn't seem to be much
reason to leave them around in the `rt` directory. There was some limiting of
threads spawned or tests when run under valgrind, but very little is run under
valgrind nowadays so there's also no real use keeping these around.
So I have tried to improve the rustbook engine:
- The sidebar now looks a lot more like gitbook (I thinks it cleaner)
- Added the Open Sans font, in my opinion more readable for prolonged periods of time
- Changed the style for code blocks a little
I encountered 1 problem. In `build.rs` I added this google font url (I commented out the non-relevant parts for clarity)
```rust
let rustdoc_args: &[String] = &[
//"".to_string(),
//preprocessed_path.display().to_string(),
//format!("-o{}", out_path.display()),
//format!("--html-before-content={}", prelude.display()),
//format!("--html-after-content={}", postlude.display()),
//format!("--markdown-playground-url=http://play.rust-lang.org"),
//format!("--markdown-css={}", item.path_to_root.join("rust-book.css").display()),
format!("--markdown-css=http://fonts.googleapis.com/css?family=Open+Sans:400italic,700italic,400,700"),
//"--markdown-no-toc".to_string(),
];
```
As you can see, I had to escape `=` with `=` because the string would get truncated if I didn't. Is that normal behaviour? Is that for security measures? If it is, isn't it a little weak if you can circumvent it by escaped characters? I don't know the reason behind, but I thought it was at least worth mentioning :)
Take your time for this PR, I still want to add multiple improvements:
- Like gitbook, possibility to change font by user
- Put `css` and `js` in their respective files (not hardcoded in rust)
- button to hide sidebar
- ...
So I'm not in a hurry to get this merged ;) But if you think it's good enough to be merged, go ahead. I will make another PR when I have other improvements.
In the image below is a screen of the improvements
This reverts commit a0efd3a3d9.
This commit caused a lot of unintended breakage for many Cargo builds. The problem is that Cargo compiles build scripts with `-C prefer-dynamic`, so the standard library is always dynamically linked and hence any imports need to be marked with `dllimport`. Dependencies of build scripts, however, were compiled as rlibs and did not have their imports tagged with `dllimport`, so build scripts would fail to link.
While known that this situation would break, it was unknown that it was a common scenario in the wild. As a result I'm just reverting these heuristics for now.
Instead of bar/baz, use valid/invalid as default methods. This
illustrates why you might want default methods, and shows that you can
call other trait methods from a default method.
r? @steveklabnik
It's deprecated and unsafe, so we shouldn't be encouraging people to use
it. Move it to `std:🧵:scoped` instead, since it's still useful
information to anyone who is using the API.
`Rc::new(RefCell::new(x)): Rc<RefCell<Trait>>` should not mean `RefCell::new(x): RefCell<Trait>`.
The latter is impossible, as an rvalue can't have an unsized type.
We were already handling unsized argument hints, but not when dealing with unsized structures.
It's deprecated and unsafe, so we shouldn't be encouraging people to use
it. Move it to `std:🧵:scoped` instead, since it's still useful
information to anyone who is using the API.
Fixes#26689
This PR tries to clarify uses of "character" where it means "code point" or "UTF-8 sequence", which are almost, but not quite the same. Edge cases added to some examples to demonstrate this.
However, I've kept use of the term "code point" instead of "Unicode scalar value", because in UTF-8 they're the same, and "code point" is more widely known.
