Improve `char::is_ascii_*` codegen
This PR is an attempt to fix https://github.com/rust-lang/rust/issues/65127
A couple of warnings:
1. the generated code might be further improved (in LLVM and/or MIR) by emitting better comparison sequences; in particular, this would improve the performance of "complex" checks such as those in `is_ascii_punctuation`
2. the second commit is currently marked "DO NOT MERGE", because it regresses SIMD on `u8` slices; this could likely be fixed by improving the computation/usage of demanded bits in LLVM
An alternative approach to remove the code duplication might be the use of macros, but currently most of the duplication is actually in the doc comments, so maybe just keeping the redundancy could be ok
Add missing `_zeroed` varants to `AllocRef`
The majority of the allocator wg has decided to add the missing `_zeroed` variants to `AllocRef`:
> these should be added since they can be efficiently implemented with the `mremap` system call on Linux. `mremap` allows you to move/grow/shrink a memory mapping, and any new pages added for growth are guaranteed to be zeroed.
>
> If `AllocRef` does not have these methods then the user will have to manually write zeroes to the added memory since the API makes no guarantees on their contents.
For the full discussion please see https://github.com/rust-lang/wg-allocators/issues/14.
This PR provides default implementations for `realloc_zeroed`, `alloc_excess_zeroed`, `realloc_excess_zeroed`, and `grow_in_place_zeroed`.
r? @Amanieu
Remove common usage pattern from `AllocRef`
This removes the common usage patterns from `AllocRef`:
- `alloc_one`
- `dealloc_one`
- `alloc_array`
- `realloc_array`
- `dealloc_array`
Actually, they add nothing to `AllocRef` except a [convenience wrapper around `Layout` and other methods in this trait](https://doc.rust-lang.org/1.41.0/src/core/alloc.rs.html#1076-1240) but have a major flaw: The documentation of `AllocRefs` notes, that
> some higher-level allocation methods (`alloc_one`, `alloc_array`) are well-defined on zero-sized types and can optionally support them: it is left up to the implementor whether to return `Err`, or to return `Ok` with some pointer.
With the current API, `GlobalAlloc` does not have those methods, so they cannot be overridden for `liballoc::Global`, which means that even if the global allocator would support zero-sized allocations, `alloc_one`, `alloc_array`, and `realloc_array` for `liballoc::Global` will error, while calling `alloc` with a zeroed-size `Layout` could succeed. Even worse: allocating with `alloc` and deallocating with `dealloc_{one,array}` could end up with not calling `dealloc` at all!
For the full discussion please see https://github.com/rust-lang/wg-allocators/issues/18
r? @Amanieu
These methods explicitly check if a char is in a specific ASCII range,
therefore the `is_ascii()` check is not needed, but LLVM seems to be
unable to remove it.
WARNING: this change improves the performance on ASCII `char`s, but
complex checks such as `is_ascii_punctuation` become slower on
non-ASCII `char`s.
Remove problematic specialization from RangeInclusive
Fixes#67194 using the approach [outlined by Mark-Simulacrum](https://github.com/rust-lang/rust/issues/67194#issuecomment-581669549).
> I believe the property we want is that if `PartialEq(&self, &other) == true`, then `self.next() == other.next()`. It is true that this is satisfied by removing the specialization and always doing `is_empty.unwrap_or_default()`; the "wrong" behavior there arises from calling `next()` having an effect on initially empty ranges, as we should be in `is_empty = true` but are not (yet) there. It might be possible to detect that the current state is always empty (i.e., `start > end`) and then not fill in the empty slot. I think this might solve the problem without regressing tests; however, this could have performance implications.
> That approach essentially states that we only use the `is_empty` slot for cases where `start <= end`. That means that `Idx: !Step` and `start > end` would both behave the same, and correctly -- we do not need the boolean if we're not ever going to emit any values from the iterator.
This is implemented here by replacing the `is_empty: Option<bool>` slot with an `exhausted: bool` slot. This flag is
- `false` upon construction,
- `false` when iteration has not yielded an element -- importantly, this means it is always `false` for an iterator empty by construction,
- `false` when iteration has yielded an element and the iterator is not exhausted, and
- only `true` when iteration has been used to exhaust the iterator.
For completeness, this also adds a note to the `Debug` representation to note when the range is exhausted.
Make `num::NonZeroX::new` an unstable `const fn`
cc #53718
These require `#[feature(const_if_match)]`, meaning they must remain unstable for the time being.
Mark several functions and methods in core::cmp as #[must_use]
These functions and methods aren't mutating functions and ignoring the result of them is likely a bug in the user's code.
Don't use the word "unwrap" to describe "unwrap" methods
It's tautological, and "unwrap" is essentially Rust-specific jargon.
I was teaching a newbie some Rust, and doing the usual hand-waving about error handling using unwrap. They asked what 'unwrap' means. I said look it up in the docs. The docs read (paraphrased) "unwrap unwraps". I was embarrassed.
This changes all the Option/Result functions with unwrapping behavior to use a variation on a single description:
> "Returns the contained `Some/Ok` value [or ...]."
It also renames the closure of `Result::unwrap_or_else` to `default` for consistency with `Option`, and perhaps makes a few other small tweaks.
Previous: https://github.com/rust-lang/rust/pull/68849
Remove some unsound specializations
This removes the unsound and exploitable specializations in the standard library
* The `PartialEq` and `Hash` implementations for `RangeInclusive` are changed to avoid specialization.
* The `PartialOrd` specialization for slices now specializes on a limited set of concrete types.
* Added some tests for the soundness problems.
It's tautological, and Rust-specific Jargon.
This changes various Option/Result methods to consistently describe unwrapping
behavior using the words "return", "contain", "consume".
It also renames the closure argument of `Return::unwrap_or_else` to `default` to
be consistent with `Option`.
Mark fn map_or() as eagerly evaluated.
In the docs for option.rs and result.rs, it is noted for all *_or()
functions that they are eagerly evaluated, except for the map_or()
function.
This commit adds this missing documentation to the two files.
Closes#68866
In the docs for option.rs and result.rs, it is noted for all *_or()
functions that they are eagerly evaluated, except for the map_or()
function.
This commit adds this missing documentation to the two files.
Make more arithmetic functions unstably const
This is a smaller version of #66884 (thanks @9999years) that constifies many of the arithmetic functions on integer primitives from #53718 that were blocked on #49146.
This makes the following things unstably const.
- `feature = const_int_unchecked_arith`
- `intrinsics::unchecked_add`
- `intrinsics::unchecked_sub`
- `intrinsics::unchecked_mul`
- `intrinsics::unchecked_div`
- `intrinsics::unchecked_rem`
- `feature = const_checked_int_methods`
- `checked_add`
- `checked_sub`
- `checked_mul`
- `checked_div` (Uses `intrinsics::unchecked_div` internally)
- `checked_rem` (Uses `intrinsics::unchecked_rem` internally)
- `checked_neg`
- `checked_shl`
- `checked_shr`
- `checked_abs`
- `feature = const_saturating_int_methods`
- `saturating_mul`
- `saturating_neg` (Uses `intrinsics::unchecked_sub` internally)
- `saturating_abs` (Uses `intrinsics::unchecked_sub` internally)
- `feature = const_wrapping_int_methods`
- `wrapping_div`
- `wrapping_rem`
- `feature = const_overflowing_int_methods`
- `overflowing_div`
- `overflowing_rem`
- `feature = const_euclidean_int_methods`
- `checked_div_euclid`
- `checked_rem_euclid`
- `wrapping_div_euclid`
- `wrapping_rem_euclid`
- `overflowing_div_euclid`
- `overflowing_rem_euclid`
Exponentiation and operations on the `NonZero` types are left to a later PR.
r? @oli-obk
cc @rust-lang/wg-const-eval @rust-lang/libs
Step stage0 to bootstrap from 1.42
This also includes a commit which fixes the rustfmt downloading logic to redownload when the rustfmt channel changes, and bumps rustfmt to a more recent version.
