This did not render as intended:
>This is defined in RFC 5737 - 192.0.2.0/24 (TEST-NET-1) - 198.51.100.0/24 (TEST-NET-2) - 203.0.113.0/24 (TEST-NET-3)
vs.
> This is defined in RFC 5737
- 192.0.2.0/24 (TEST-NET-1)
- 198.51.100.0/24 (TEST-NET-2)
- 203.0.113.0/24 (TEST-NET-3)
This commit does two things: it adds an example for indexing vectors, and it changes the \"Examples\" section to use full sentences.
This change was spurred by someone in the #rust IRC channel asking if there was a `.set()` method for changing the `i`-th value of a vector (they had missed that `Vec` implements `IndexMut`, which is easy to do if you're not aware of that trait).
This script used to be used to [extract the grammar sections from the reference](https://github.com/rust-lang/rust/pull/8585), but there is [now a separate src/doc/grammar.md](https://github.com/rust-lang/rust/pull/22308) that generates grammar.html where the grammar sections that used to be in the reference live, so there is no longer a need to extract the grammar from the reference.
I ❤️ deleting code :) But I totally understand if there's a reason to keep this around that I don't know about :)
- `File::open` is for opening a file in read-only mode
- `File::create` is for opening a file in write-only mode, which is what we want instead for this example to make sense
This makes the `bit::vec::bench::bench_bit_vec_big_union` benchmark go
from `774 ns/iter (+/- 190)` to `602 ns/iter (+/- 5)`.
(There's room for more work here too: if one can guarantee 128-bit
alignment for the vector, the compiler actually optimises `union`,
`intersection` etc. to SIMD instructions, which end up being ~5x faster
that the original version, and 4x faster than the optimised version in
this patch.)
This was one last spot where directories were being leaked through with
arguments of the form `\\?\` which neither `ld.exe` nor `gcc.exe` does
understands so the prefix needed to be stripped.
Closes#25072
This was one last spot where directories were being leaked through with
arguments of the form `\\?\` which neither `ld.exe` nor `gcc.exe` does
understands so the prefix needed to be stripped.
Closes#25072
I'm uncertain whether the 3 implementations in `net2` should unwrap the socket address values. Without unwrapping it looks like this:
```
UdpSocket { addr: Ok(V4(127.0.0.1:34354)), inner: 3 }
TcpListener { addr: Ok(V4(127.0.0.1:9123)), inner: 4 }
TcpStream { addr: Ok(V4(127.0.0.1:9123)), peer: Ok(V4(127.0.0.1:58360)), inner: 5 }
```
One issue is that you can create, e.g. `UdpSocket`s with bad addresses, which means you can't just unwrap in the implementation:
```
#![feature(from_raw_os)]
use std::net::UdpSocket;
use std::os::unix::io::FromRawFd;
let sock: UdpSocket = unsafe { FromRawFd::from_raw_fd(-1) };
println!("{:?}", sock); // prints "UdpSocket { addr: Err(Error { repr: Os(9) }), inner: -1 }"
```
Fixes#23134.
This makes the `bit::vec::bench::bench_bit_vec_big_union` benchmark go
from `774 ns/iter (+/- 190)` to `602 ns/iter (+/- 5)`.
(There's room for more work here too: if one can guarantee 128-bit
alignment for the vector, the compiler actually optimises `union`,
`intersection` etc. to SIMD instructions, which end up being ~5x faster
that the original version, and 4x faster than the optimised version in
this patch.)
- I found n error in the book, before contributing the patch to fix it, I had to find where they were hosted
- It took me quite look to find where within the rust-lang *organisation* it was! ... and this should make it easier for the next person in the same position
Without the inline annotation this:
str::from_utf8_unchecked( slice::from_raw_parts( ptr, len ) )
doesn't get inlined which can be pretty brutal performance-wise
when used in an inner loop of a low level string manipulation method.
This script used to be used to extract the grammar sections from the
reference, but there is now a separate src/doc/grammar.md where the
grammar sections that used to be in the reference live, so there is
no longer a need to extract the grammar from the reference.
Since the hashmap and its hasher are implemented in different crates, we
currently can't benefit from inlining, which means that especially for
small, fixed size keys, there is a huge overhead in hash calculations,
because the compiler can't apply optimizations that only apply for these
keys.
Fixes the brainfuck benchmark in #24014.
