Just like for Vec. This should benefit both non-optimized and optimized
performance. Non-optimized since the intrinsic drop_in_place is easily
removed, and optimized because iterating the slices is more efficient
than using the VecDeque iterators.
Vectors come up in sections dedicated to ownership with the assumption that we know something about it but we haven't seen it yet. On the other hand, you need not know anything about ownership or lifetimes to understand the basics of vectors covered in the vector section of the book. Additionally, by moving it where it is there is a natural progression from loops to an iterative type which discusses for loops. This kind of interaction is generally better for learning.
I would like to have moved the struct section as well but I'm less confident about how to handle it since the ownership sections discuss structs and the structs section talks about mutable borrow.
The names are "0", "1", "2" etc, the same as used in field access.
This generally make things simpler and potentially allows to reuse braced struct machinery (struct patterns, struct expressions) for tuple structs.
I haven't touched the AST for stability reasons, but I intend to do it later.
r? @eddyb
a test file may specify `// revisions: foo bar baz`
headers and expected errors may be made specific to a revision
by writing `//[foo] header` or `//[foo]~ ERROR`
Use raw pointer casts for slice, str's .as_ptr()
We can now use raw pointer casts `*const [T] as *const T` and
`*const str as *const u8` instead of .repr() for getting the
pointer out of a slice.
Was getting error:
```
running: "sh" "/home/flubba86/rust/src/libstd/../libbacktrace/configure" "--with-pic" "--disable-multilib" "--disable-shared" "--disable-host-shared" "--host=asmjs-unknown-emscripten" "--build=x86_64-unknown-linux-gnu"
...
Invalid configuration `asmjs-unknown-emscripten': system `emscripten' not recognized
```
This commit adds the emscripten target to the libbacktrace configure script so it is no longer unrecognized.
These types were already `!Sync`, but this improves error messages when they are used in contexts that require `Sync`, aligning them with conventions used with `Rc`, among others.
r? @alexcrichton
Vectors come up in sections dedicated to ownership with the assumption that we know something about it but we haven't seen it yet. On the other hand, you need not know anything about ownership or lifetimes to understand the basics of vectors covered in the vector section of the book. Additionally, by moving it where it is there is a natural progression from loops to an iterative type which discusses for loops. This kind of interaction is generally better for learning.
I would like to have moved the struct section as well but I'm less confident about how to handle it since the ownership sections discuss structs and the structs section talks about mutable borrow.
Was getting error:
```
running: "sh" "/home/flubba86/rust/src/libstd/../libbacktrace/configure" "--with-pic" "--disable-multilib" "--disable-shared" "--disable-host-shared" "--host=asmjs-unknown-emscripten" "--build=x86_64-unknown-linux-gnu"
...
Invalid configuration `asmjs-unknown-emscripten': system `emscripten' not recognized
```
Undo change to libbacktrace configure script.
Modify libstd build.rs to not build libbacktrace in the case of targeting emscripten.
These types were already `!Sync`, but this improves error messages when
they are used in contexts that require `Sync`, aligning them with
conventions used with `Rc`, among others.
Zeroing on-drop seems to work fine. Still thinking about the best way to approach zeroing on-move.
(based on top of the other drop PR; only the last 2 commits are relevant)
Hello.
Quite a few of the links in the `core` module concerning redirection to additional primitive type documentation are broken. I noticed in #30214 that there seemed to be a consensus with linking across to `std` module documentation from the `core` module. This is what I've done with the `core` modules for primitive types.
If the changes here are good to go forward with, I'll happily tend to adding more documentation links for the extension traits in the aforementioned issue if need be.
r? @steveklabnik
