Use `drop_in_place` in Vec and VecDeque
We can use drop_in_place's DST capabilities directly in Vec::drop and similarly in VecDeque::drop. I verfied this has the same effect as the previous `needs_drop` code; `drop_in_place` it itself an intrinsic.
The VecDeque replacement should be more efficient too, even in release mode (slice iteration makes a more efficient loop than the deque iterator).
This PR privacy checks paths as they are resolved instead of in `librustc_privacy` (fixes#12334 and fixes#31779). This removes the need for the `LastPrivate` system introduced in PR #9735, the limitations of which cause #31779.
This PR also reports privacy violations in paths to intra- and inter-crate items the same way -- it always reports the first inaccessible segment of the path.
Since it fixes#31779, this is a [breaking-change]. For example, the following code would break:
```rust
mod foo {
pub use foo::bar::S;
mod bar { // `bar` should be private to `foo`
pub struct S;
}
}
impl foo::S {
fn f() {}
}
fn main() {
foo::bar::S::f(); // This is now a privacy error
}
```
r? @alexcrichton
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
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
Use unordered nested list for stabilised APIs to improve readability. This makes the release notes for 1.7 a bit longer, but I don't think we should optimise for brevity here. It's a bit inconsistent since the other releases are not done this way, so feel free to ignore this change.
Also:
- Add link to `u32::checked_neg`
- Remove trailing back tick from BTreeMap line
r? @brson
The default implementations (with `where Self: Sized`) are so that methods that take `self` by value can exist in a trait that’s implemented for dynamically-sized types (`str` and `[u8]`).
CC https://github.com/rust-lang/rust/issues/27809#issuecomment-177564950
CC @alexcrichton
This commit implements documentation generation of the nomicon, the book, the
style guide, and the standalone docs. New steps were added for each one as well
as appropriate makefile targets for each one as well.
