Stabilize assoc_int_consts associated int/float constants
The next step in RFC https://github.com/rust-lang/rfcs/pull/2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325.
* Stabilize all constants under the `assoc_int_consts` feature flag.
* Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred.
* Update documentation examples to use new constants.
* Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway.
r? @LukasKalbertodt
Remove `usable_size` APIs
This removes the usable size APIs:
- remove `usable_size` (obv)
- change return type of allocating methods to include the allocated size
- remove `_excess` API
r? @Amanieu
closesrust-lang/wg-allocators#17
Unrevert "Remove `checked_add` in `Layout::repeat`"
This reapplies @kraai's original `libcore::alloc::Layout::repeat` change from #67174 which was temporarily reverted in #69241. Now that the proper LLVM fix has been cherry-picked, we can unrevert the revert.
This change was originally reviewed by @hanna-kruppe on the initial PR.
cc @RalfJung
Add documentation to compiler intrinsics
This adds documentation to the compiler intrinsics having stable standard implementations.
Relates to #34338 (cc @bstrie)
r? @steveklabnik (for reassignment?)
fix aliasing violation in align_to_mut
Fixes https://github.com/rust-lang/rust/issues/68549
I decided to add the testcase here to make it all one PR, but if you prefer I can also add that test case in the Miri repo instead.
Use assert_ne in hash tests
The hash tests were written before the assert_ne macro was added to the standard library. The assert_ne macro provides better output in case of a failure.
The hash tests were written before the assert_ne macro was added to the standard library. The assert_ne macro provides better output in case of a failure.
Add methods to 'leak' RefCell borrows as references with the lifetime of the original reference
Usually, references to the interior are only created by the `Deref` and
`DerefMut` impl of the guards `Ref` and `RefMut`. Note that `RefCell`
already has to cope with leaks of such guards which, when it occurs,
effectively makes it impossible to ever acquire a mutable guard or any
guard for `Ref` and `RefMut` respectively. It is already safe to use
this to create a reference to the inner of the ref cell that lives as
long as the reference to the `RefCell` itself, e.g.
```rust
fn leak(r: &RefCell<usize>) -> Option<&usize> {
let guard = r.try_borrow().ok()?;
let leaked = Box::leak(Box::new(guard));
Some(&*leaked)
}
```
The newly added methods allow the same reference conversion without an
indirection over a leaked allocation. It's placed on the `Ref`/`RefMut` to
compose with both borrow and try_borrow directly.
Add primitive module to libcore
This re-exports the primitive types from libcore at `core::primitive` to allow
macro authors to have a reliable location to use them from.
Fixes#44865
Fix minor error in `MaybeUninit::get_mut()` doc example
In the `MaybeUninit::get_mut()` example I wanted to assert that the slice was sorted and mistakenly used `.chunks(2)` rather than `.windows(2)` to assert it, as @ametisf pointed out in https://github.com/rust-lang/rust/pull/65948#issuecomment-589988183 .
This fixes it.
Prior to this commit, `str` documented that `get_unchecked` had
the precondition that "`begin` must come before `end`". This would appear
to prohibit empty slices (i.e. begin == end).
In practice, get_unchecked is called often with empty slices. Let's relax
the precondition so as to allow them.
Test `Duration::new` panics on overflow
A `Duration` is created from a second and nanoseconds variable. The
documentation says: "This constructor will panic if the carry from the
nanoseconds overflows the seconds counter". This was, however, not tested
in the tests. I doubt the behavior will ever regress, but it is usually a
good idea to test all documented behavior.
Make `u8::is_ascii` a stable `const fn`
`char::is_ascii` was already stabilized as `const fn` in #55278, so there is no reason for `u8::is_ascii` to go through an unstable period.
cc @rust-lang/libs
Revert `u8to64_le` changes from #68914.
`SipHasher128`'s `u8to64_le` function was simplified in #68914.
Unfortunately, the new version is slower, because it introduces `memcpy`
calls with non-statically-known lengths.
This commit reverts the change, and adds an explanatory comment (which
is also added to `libcore/hash/sip.rs`). This barely affects
`SipHasher128`'s speed because it doesn't use `u8to64_le` much, but it
does result in `SipHasher128` once again being consistent with
`libcore/hash/sip.rs`.
r? @michaelwoerister
Implement split_inclusive for slice and str
# Overview
* Implement `split_inclusive` for `slice` and `str` and `split_inclusive_mut` for `slice`
* `split_inclusive` is a substring/subslice splitting iterator that includes the matched part in the iterated substrings as a terminator.
* EDIT: The behaviour has now changed, as per @KodrAus 's input, to the same semantics with the `split_terminator` function. I updated the examples below.
* Two examples below:
```Rust
let data = "\nMäry häd ä little lämb\nLittle lämb\n";
let split: Vec<&str> = data.split_inclusive('\n').collect();
assert_eq!(split, ["\n", "Märy häd ä little lämb\n", "Little lämb\n"]);
```
```Rust
let uppercase_separated = "SheePSharKTurtlECaT";
let mut first_char = true;
let split: Vec<&str> = uppercase_separated.split_inclusive(|c: char| {
let split = !first_char && c.is_uppercase();
first_char = split;
split
}).collect();
assert_eq!(split, ["SheeP", "SharK", "TurtlE", "CaT"]);
```
# Justification for the API
* I was surprised to find that stdlib currently only has splitting iterators that leave out the matched part. In my experience, wanting to leave a substring terminator as a part of the substring is a pretty common usecase.
* This API is strictly more expressive than the standard `split` API: it's easy to get the behaviour of `split` by mapping a subslicing operation that drops the terminator. On the other hand it's impossible to derive this behaviour from `split` without using hacky and brittle `unsafe` code. The normal way to achieve this functionality would be implementing the iterator yourself.
* Especially when dealing with mutable slices, the only way currently is to use `split_at_mut`. This API provides an ergonomic alternative that plays to the strengths of the iterating capabilities of Rust. (Using `split_at_mut` iteratively used to be a real pain before NLL, fortunately the situation is a bit better now.)
# Discussion items
* <s>Does it make sense to mimic `split_terminator` in that the final empty slice would be left off in case of the string/slice ending with a terminator? It might do, as this use case is naturally geared towards considering the matching part as a terminator instead of a separator.</s>
* EDIT: The behaviour was changed to mimic `split_terminator`.
* Does it make sense to have `split_inclusive_mut` for `&mut str`?
A `Duration` is created from a second and nanoseconds variable. The
documentation says: "This constructor will panic if the carry from the
nanoseconds overflows the seconds counter". This was, however, not tested
in the tests. I doubt the behavior will ever regress, but it is usually a
good idea to test all documented behavior.
`SipHasher128`'s `u8to64_le` function was simplified in #68914.
Unfortunately, the new version is slower, because it introduces `memcpy`
calls with non-statically-known lengths.
This commit reverts the change, and adds an explanatory comment (which
is also added to `libcore/hash/sip.rs`). This barely affects
`SipHasher128`'s speed because it doesn't use `u8to64_le` much, but it
does result in `SipHasher128` once again being consistent with
`libcore/hash/sip.rs`.
