[futures] add a few blanket impls to std
these were defined in the futures crate, but with the core definitions moving to std these would need to move too.
add some docs to `From` conversions
This adds a helpful document to the bool → int* conversions as well as to the lossless integer conversions.
One of #51430 down, some more to go.
Document size_of for 128-bit integers
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)
Make the size of Option<NonZero*> a documented guarantee.
Closes#49137, the tracking issue for `NonZero*`, as this was the last remaining open question.
Note that `ptr::NonNull<T>` already documents a similar guarantee.
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)
Add Future and task system to the standard library
This adds preliminary versions of the `std::future` and `std::task` modules in order to unblock development of async/await (https://github.com/rust-lang/rust/issues/50547). These shouldn't be considered as final forms of these libraries-- design questions about the libraries should be left on https://github.com/rust-lang/rfcs/pull/2418. Once that RFC (or a successor) is merged, these APIs will be adjusted as necessary.
r? @aturon
Closes#49137, the tracking issue for `NonZero*`,
as this was the last remaining open question.
Note that `ptr::NonNull<T>` already documents a similar guarantee.
const fn integer operations
A follow up to #51171Fixes#51267
Makes a lot of the integer methods (`swap_bytes`, `count_ones` etc) `const fn`s. See #51267 for a discussion about why this is wanted and the solution used.
Make Layout's align a NonZeroUsize
This PR makes the `Layout`'s align field a `NonZeroUsize` since it cannot ever be zero, not even while building a `Layout`. It also contains some drive-by minor cleanups over the docs and the code, like updating the documented error types, or using the `size()` and `align()` methods instead of accessing the fields directly (the latter was required for the `NonZeroUsize` change anyways).
r? @SimonSapin
cc @Amanieu