| Age | Commit message (Collapse) | Author | Lines |
|
|
|
move the Pin API into its own module for centralized documentation
This implements the change proposed by @withoutboats in #49150, as suggested by @RalfJung in the review of #53104,
along with the documentation that was originally in it, that was deemed more appropriate in module-level documentation.
r? @RalfJung
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
LLVM isn't able to remove the alloca for the unaligned block in the SIMD tail in some cases, so doing this helps SRoA work in cases where it currently doesn't. Found in the `replace_with` RFC discussion.
|
|
The docs were not specifying how to compute the alignment of the struct, so I had to spend some time trying to figure out how that works. Found the answer [on this page](http://camlorn.net/posts/April%202017/rust-struct-field-reordering.html):
> The total size of this struct is 5, but the most-aligned field is b with alignment 2, so we round up to 6 and give the struct an alignment of 2 bytes.
|
|
|
|
|
|
|
|
and `map_unchecked`
|
|
We might want to consider separately documenting the alignment of
primitives, rather than just their size, since 128-bit integers, unlike
all other primitives, have an alignment that is not identical to their
size (size_of is 16, align_of is 8)
|
|
Reword {ptr,mem}::replace docs.
Fixes https://github.com/rust-lang/rust/issues/50657.
|
|
Fixes https://github.com/rust-lang/rust/issues/50657.
|
|
|
|
|
|
|
|
turn `ManuallyDrop::new` into a constant function
|
|
|
|
|
|
Suggested by @dylanede at <https://github.com/rust-lang/rust/issues/49150#issuecomment-381071442>.
|
|
As discussed at [1] §3 and [2] and [3], a formal look at pinning requires considering a
distinguished "shared pinned" mode/typestate. Given that, it seems desirable to
at least eventually actually expose that typestate as a reference type. This
renames Pin to PinMut, freeing the name Pin in case we want to use it for a
shared pinned reference later on.
[1] https://www.ralfj.de/blog/2018/04/10/safe-intrusive-collections-with-pinning.html
[2] https://github.com/rust-lang/rfcs/pull/2349#issuecomment-379250361
[3] https://github.com/rust-lang/rust/issues/49150#issuecomment-380488275
|
|
|
|
|
|
Closes #43751.
|
|
|
|
|
|
|
|
|
|
Document the size of bool
|
|
|
|
Fixes #46038
|
|
|
|
This commit updates the bootstrap compiler, bumps the version to 1.23, updates
Cargo, updates books, and updates crates.io dependencies
|
|
|
|
`PhantomData<*const T>` has the implication of Send / Syncness following
the *const T type, but the discriminant should always be Send and Sync.
Use `PhantomData<fn() -> T>` which has the same variance in T, but is Send + Sync
|
|
Docs for size_of::<#[repr(C)]> items.
Most of this info comes from camlorn's blog post on optimizing struct layout and the Rustonomicon.
I don't really like my wording in the first paragraph.
I also cannot find a definition of what `#[repr(C)]` does for enums that have variants with fields. They're allowed, unlike `#[repr(C)] enum`s with no variants.
|
|
|
|
|
|
Most of this info comes from camlorn's blog post on optimizing
struct layout and the Rustonomicon.
|
|
This includes the following stabilizations:
- tcpstream_connect_timeout https://github.com/rust-lang/rust/pull/44563
- iterator_for_each https://github.com/rust-lang/rust/pull/44567
- ord_max_min https://github.com/rust-lang/rust/pull/44593
- compiler_fences https://github.com/rust-lang/rust/pull/44595
- needs_drop https://github.com/rust-lang/rust/pull/44639
- vec_splice https://github.com/rust-lang/rust/pull/44640
|
|
Expand size_of docs
This PR does 3 things.
1. Adds a description of what pointer size means to the primitive pages for usize and isize.
2. Says the general size of things is not stable from compiler to compiler.
3. Adds a table of sizes of things that we do guarantee. As this is the first table in the libstd docs, I've included a picture of how that looks.

|
|
|
|
|
|
Individualize feature gates for const fn invocation
This PR changes the meaning of `#![feature(const_fn)]` so it is only required to declare a const fn but not to call one. Based on discussion at #24111. I was hoping we could have an FCP here in order to move that conversation forward.
This sets the stage for future stabilization of the constness of several functions in the standard library (listed below), so could someone please tag the lang team for review.
- `std::cell`
- `Cell::new`
- `RefCell::new`
- `UnsafeCell::new`
- `std::mem`
- `size_of`
- `align_of`
- `std::ptr`
- `null`
- `null_mut`
- `std::sync`
- `atomic`
- `Atomic{Bool,Ptr,Isize,Usize}::new`
- `once`
- `Once::new`
- primitives
- `{integer}::min_value`
- `{integer}::max_value`
Some other functions are const but they are also unstable or hidden, e.g. `Unique::new` so they don't have to be considered at this time.
After this stabilization, the following `*_INIT` constants in the standard library can be deprecated. I wasn't sure whether to include those deprecations in the current PR.
- `std::sync`
- `atomic`
- `ATOMIC_{BOOL,ISIZE,USIZE}_INIT`
- `once`
- `ONCE_INIT`
|
|
|