| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit c8f9b84b393915a48253e3edc862c15a9b7152a7.
|
|
The previous syntax was causing rustdoc to interpret them as links.
|
|
|
|
Add #[repr(transparent)] to some libcore types
* `UnsafeCell`
* `Cell`
* `NonZero*`
* `NonNull`
* `Unique`
CC https://github.com/rust-lang/rust/issues/43036
|
|
Implement always-fallible TryFrom for usize/isize conversions that are infallible on some platforms
This reverts commit 837d6c70233715a0ae8e15c703d40e3046a2f36a "Remove TryFrom impls that might become conditionally-infallible with a portability lint".
This fixes #49415 by adding (restoring) missing `TryFrom` impls for integer conversions to or from `usize` or `isize`, by making them always fallible at the type system level (that is, with `Error=TryFromIntError`) even though they happen to be infallible on some platforms (for some values of `size_of::<usize>()`).
They had been removed to allow the possibility to conditionally having some of them be infallible `From` impls instead, depending on the platforms, and have the [portability lint](https://github.com/rust-lang/rfcs/pull/1868) warn when they are used in code that is not already opting into non-portability. For example `#[allow(some_lint)] usize::from(x: u64)` would be valid on code that only targets 64-bit platforms.
This PR gives up on this possiblity for two reasons:
* Based on discussion with @aturon, it seems that the portability lint is not happening any time soon. It’s better to have the conversions be available *at all* than keep blocking them for so long. Portability-lint-gated platform-specific APIs can always be added separately later.
* For code that is fine with fallibility, the alternative would force it to opt into "non-portability" even though there would be no real portability issue.
|
|
|
|
Fixes #49792
|
|
* `UnsafeCell`
* `Cell`
* `NonZero*`
* `NonNull`
* `Unique`
|
|
|
|
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.
|
|
a portability lint"
This reverts commit 837d6c70233715a0ae8e15c703d40e3046a2f36a.
Fixes https://github.com/rust-lang/rust/issues/49415
|
|
const fn integer operations
A follow up to #51171
Fixes #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.
|
|
Provide more context for what the {f32,f64}::EPSILON values represent.
Introduce the 'machine epsilon' term because if one googles 'epsilon', they might stumble upon https://en.wikipedia.org/wiki/Epsilon_numbers_(mathematics) instead of https://en.wikipedia.org/wiki/Machine_epsilon
|
|
|
|
|
|
Add From<bool> for int types
Fixes #46109.
|
|
|
|
|
|
Add missing Wrapping methods, use doc_comment!
Re-opened version of #49393 . Finishing touches for #32463.
Note that this adds `Shl` and `Shr` implementations for `Wrapping<i128>` and `Wrapping<u128>`, which were previously missed. This is technically insta-stable, but I don't know why this would be a problem.
|
|
|
|
Following up to #49896 and #50629. Fixes #32110.
E0689 is weird.
|
|
|
|
Stabilize num::NonZeroU*
Tracking issue: https://github.com/rust-lang/rust/issues/49137
|
|
Tracking issue: https://github.com/rust-lang/rust/issues/49137
|
|
|
|
It is now an implementation detail of ptr::NonNull and num::NonZero*
|
|
just a small typo.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add inherent methods in libcore for [T], [u8], str, f32, and f64
# Background
Primitive types are defined by the language, they don’t have a type definition like `pub struct Foo { … }` in any crate. So they don’t “belong” to any crate as far as `impl` coherence is concerned, and on principle no crate would be able to define inherent methods for them, without a trait. Since we want these types to have inherent methods anyway, the standard library (with cooperation from the compiler) bends this rule with code like [`#[lang = "u8"] impl u8 { /*…*/ }`](https://github.com/rust-lang/rust/blob/1.25.0/src/libcore/num/mod.rs#L2244-L2245). The `#[lang]` attribute is permanently-unstable and never intended to be used outside of the standard library.
Each lang item can only be defined once. Before this PR there is one impl-coherence-rule-bending lang item per primitive type (plus one for `[u8]`, which overlaps with `[T]`). And so one `impl` block each. These blocks for `str`, `[T]` and `[u8]` are in liballoc rather than libcore because *some* of the methods (like `<[T]>::to_vec(&self) -> Vec<T> where T: Clone`) need a global memory allocator which we don’t want to make a requirement in libcore. Similarly, `impl f32` and `impl f64` are in libstd because some of the methods are based on FFI calls to C’s `libm` and we want, as much as possible, libcore not to require “runtime support”.
In libcore, the methods of `str` and `[T]` that don’t allocate are made available through two **unstable traits** `StrExt` and `SliceExt` (so the traits can’t be *named* by programs on the Stable release channel) that have **stable methods** and are re-exported in the libcore prelude (so that programs on Stable can *call* these methods anyway). Non-allocating `[u8]` methods are not available in libcore: https://github.com/rust-lang/rust/issues/45803. Some `f32` and `f64` methods are in an unstable `core::num::Float` trait with stable methods, but that one is **not in the libcore prelude**. (So as far as Stable programs are concerns it doesn’t exist, and I don’t know what the point was to mark these methods `#[stable]`.)
https://github.com/rust-lang/rust/issues/32110 is the tracking issue for these unstable traits.
# High-level proposal
Since the standard library is already bending the rules, why not bend them *a little more*? By defining a few additional lang items, the compiler can allow the standard library to have *two* `impl` blocks (in different crates) for some primitive types.
The `StrExt` and `SliceExt` traits still exist for now so that we can bootstrap from a previous-version compiler that doesn’t have these lang items yet, but they can be removed in next release cycle. (`Float` is used internally and needs to be public for libcore unit tests, but was already `#[doc(hidden)]`.) I don’t know if https://github.com/rust-lang/rust/issues/32110 should be closed by this PR, or only when the traits are entirely removed after we make a new bootstrap compiler.
# Float methods
Among the methods of the `core::num::Float` trait, three are based on LLVM intrinsics: `abs`, `signum`, and `powi`. PR https://github.com/rust-lang/rust/pull/27823 “Remove dependencies on libm functions from libcore” moved a bunch of `core::num::Float` methods back to libstd, but left these three behind. However they aren’t specifically discussed in the PR thread. The `compiler_builtins` crate defines `__powisf2` and `__powidf2` functions that look like implementations of `powi`, but I couldn’t find a connection with the `llvm.powi.f32` and `llvm.powi.f32` intrinsics by grepping through LLVM’s code.
In discussion starting at https://github.com/rust-lang/rust/issues/32110#issuecomment-370647922 Alex says that we do not want methods in libcore that require “runtime support”, but it’s not clear whether that applies to these `abs`, `signum`, or `powi`. In doubt, I’ve **removed** them for the trait and moved them to inherent methods in libstd for now. We can move them back later (or in this PR) if we decide that’s appropriate.
# Change details
For users on the Stable release channel:
* I believe this PR does not make any breaking change
* Some methods for `[u8]`, `f32`, and `f64` are newly available to `#![no_std]` users (fixes https://github.com/rust-lang/rust/issues/45803)
* There should be no visible change for `std` users in terms of what programs compile or what their behavior is. (Only in compiler error messages, possibly.)
For Nightly users, additionally:
* The unstable `StrExt` and `SliceExt` traits are gone
* Their methods are now inherent methods of `str` and `[T]` (so only code that explicitly named the traits should be affected, not "normal" method calls)
* The `abs`, `signum` and `powi` methods of the `Float` trait are gone
* The `Float` trait’s unstable feature name changed to `float_internals` with no associated tracking issue, to reflect it being a permanently unstable implementation detail rather than a public API on a path to stabilization.
* Its remaining methods are now inherent methods of `f32` and `f64`.
-----
CC @rust-lang/libs for the API changes, @rust-lang/compiler for the new lang items
|
|
`Float` still needs to be public for libcore unit tests.
|
|
Affected methods are `abs`, `signum`, and `powi`.
CC https://github.com/rust-lang/rust/issues/32110#issuecomment-379503183
|
|
… previously in the unstable core::num::Float trait.
Per https://github.com/rust-lang/rust/issues/32110#issuecomment-379503183,
the `abs`, `signum`, and `powi` methods are *not* included for now
since they rely on LLVM intrinsics and we haven’t determined yet whether
those instrinsics lower to calls to libm functions on any platform.
|
|
This reverts commit e53a2a72743810e05f58c61c9d8a4c89b712ad2e.
|
|
Add to_bytes and from_bytes to primitive integers
Discussion issue turned tracking issue: https://github.com/rust-lang/rust/issues/49792
|
|
|
|
Implement RFC #2169 (Euclidean modulo).
Tracking issue: #49048
|
|
|
|
|
|
|
|
|
|
|
|
portability lint
https://github.com/rust-lang/rust/pull/49305#issuecomment-376293243
|
|
Tracking issue: https://github.com/rust-lang/rust/issues/33417
|
|
Instead, expose apparently-fallible conversions in cases where
the implementation happens to be infallible for a given target.
Having an associated type / return type in a public API change
based on the target is a portability hazard.
|
|
There is precendent in C for having a minimum pointer size, but I don’t feel confident enough about the future to mandate a maximum.
|
