* `core::num`: adjust `UnsignedInt::is_power_of_two`,
`UnsignedInt::next_power_of_two`, `Int::pow`.
In particular for `Int::pow`: (1.) do not panic when `base`
overflows if `acc` never observes the overflowed `base`, and (2.)
if `acc` does observe the overflowed `base`, make sure we only
panic if we would have otherwise (e.g. during a computation of
`base * base`).
* also in `core::num`: avoid underflow during computation of `uint::MAX`.
* `std::num`: adjust tests `uint::test_uint_from_str_overflow`,
`uint::test_uint_to_str_overflow`, `strconv`
* `coretest::num`: adjust `test::test_int_from_str_overflow`.
These return the result of the operation *plus* an overflow/underflow bit.
This can make it easier to write operations where you want to chain
some arithmetic together, but also want to return a flag signalling if
overflow every occurred.
Many of the core rust libraries have places that rely on integer
wrapping behaviour. These places have been altered to use the wrapping_*
methods:
* core:#️⃣:sip - A number of macros
* core::str - The `maximal_suffix` method in `TwoWaySearcher`
* rustc::util::nodemap - Implementation of FnvHash
* rustc_back::sha2 - A number of macros and other places
* rand::isaac - Isaac64Rng, changed to use the Wrapping helper type
Some places had "benign" underflow. This is when underflow or overflow
occurs, but the unspecified value is not used due to other conditions.
* collections::bit::Bitv - underflow when `self.nbits` is zero.
* collections:#️⃣:{map,table} - Underflow when searching an empty
table. Did cause undefined behaviour in this case due to an
out-of-bounds ptr::offset based on the underflowed index. However the
resulting pointers would never be read from.
* syntax::ext::deriving::encodable - Underflow when calculating the
index of the last field in a variant with no fields.
These cases were altered to avoid the underflow, often by moving the
underflowing operation to a place where underflow could not happen.
There was one case that relied on the fact that unsigned arithmetic and
two's complement arithmetic are identical with wrapping semantics. This
was changed to use the wrapping_* methods.
Finally, the calculation of variant discriminants could overflow if the
preceeding discriminant was `U64_MAX`. The logic in `rustc::middle::ty`
for this was altered to avoid the overflow completely, while the
remaining places were changed to use wrapping methods. This is because
`rustc::middle::ty::enum_variants` now throws an error when the
calculated discriminant value overflows a `u64`.
This behaviour can be triggered by the following code:
```
enum Foo {
A = U64_MAX,
B
}
```
This commit also implements the remaining integer operators for
Wrapped<T>.
Adds overflow checking to integer addition, multiplication, and subtraction
when `-Z force-overflow-checks` is true, or if `--cfg ndebug` is not passed to
the compiler. On overflow, it panics with `arithmetic operation overflowed`.
Also adds `overflowing_add`, `overflowing_sub`, and `overflowing_mul`
intrinsics for doing unchecked arithmetic.
[breaking-change]
* count_ones/zeros, trailing_ones/zeros return u32, not usize
* rotate_left/right take u32, not usize
* RADIX, MANTISSA_DIGITS, DIGITS, BITS, BYTES are u32, not usize
Doesn't touch pow because there's another PR for it.
[breaking-change]
Changes .or() so that it can return a Result with a different E type
than the one it is called on.
Essentially:
fn or(self, res: Result<T, E>) -> Result<T, E>
becomes
fn or<F>(self, res: Result<T, F>) -> Result<T, F>
This brings `or` in line with the existing `and` & `or_else`
This is a
[breaking-change]
Due to some code needing additional type annotations.
Change MarkerTrait to be invariant. This is a (small) loss of expressiveness, but is necessary for now to work around #22806. Fixes#22655.
r? @pnkfelix
Ensure we do not zero when \"moving\" types that are Copy.
Uses more precise `type_needs_drop` for deciding about emitting cleanup code. Added notes about the weaknesses regarding `ty::type_contents` here.
Fix#22536
We were recording stability attributes applied to fields in the
compiler, and even annotating it in the libs, but the compiler didn't
actually do the checks to give errors/warnings in user crates.
Details in the commit messages.
Changes .or() so that it can return a Result with a different E type
than the one it is called on.
Essentially:
fn or(self, res: Result<T, E>) -> Result<T, E>
becomes
fn or<F>(self, res: Result<T, F>) -> Result<T, F>
This brings `or` in line with the existing `and` and `or_else` member
types.
This is a
[breaking-change]
Due to some code needing additional type annotations.
Specifically, the following actions were takend:
* The `copy_memory` and `copy_nonoverlapping_memory` functions
to drop the `_memory` suffix (as it's implied by the functionality). Both
functions are now marked as `#[stable]`.
* The `set_memory` function was renamed to `write_bytes` and is now stable.
* The `zero_memory` function is now deprecated in favor of `write_bytes`
directly.
* The `Unique` pointer type is now behind its own feature gate called `unique`
to facilitate future stabilization.
[breaking-change]
Specifically, the following actions were taken:
* The `copy_memory` and `copy_nonoverlapping_memory` functions
to drop the `_memory` suffix (as it's implied by the functionality). Both
functions are now marked as `#[stable]`.
* The `set_memory` function was renamed to `write_bytes` and is now stable.
* The `zero_memory` function is now deprecated in favor of `write_bytes`
directly.
* The `Unique` pointer type is now behind its own feature gate called `unique`
to facilitate future stabilization.
* All type parameters now are `T: ?Sized` wherever possible and new clauses were
added to the `offset` functions to require that the type is sized.
[breaking-change]
This is a breaking change if missing docs are forbidden in any module or crate.
I had to add documentation to undocumented associated types in libstd and libcore, please let me know if the documentation is inadequate anywhere!
Fixes#20648
fmt and hash are pretty straightforward I think. sync is a bit more complex. I thought one or two of the `isize`s ought to be `i32`s, but that would require a bunch of casting (the root cause being the lack of atomics other than isize/usize).
r? @alexcrichton
This is one more step towards completing #13231
This series of commits add support for default trait implementations. The changes in this PR don't break existing code and they are expected to preserve the existing behavior in the compiler as far as built-in bounds checks go.
The PR adds negative implementations of `Send`/`Sync` for some types and it removes the special cases for `Send`/`Sync` during the trait obligations checks. That is, it now fully relies on the traits check rather than lang items.
Once this patch lands and a new snapshot is created, it'll be possible to add default impls for `Send` and `Sync` and remove entirely the use of `BuiltinBound::{BoundSend,BoundSync}` for positive implementations as well.
This PR also removes the restriction on negative implementations. That is, it is now possible to add negative implementations for traits other than `Send`/`Sync`
