Change:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for on signed integral types. The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- First implemented in <!-- Include a list of all the PRs that were involved in implementing the feature. --
Are there any outstanding issues with this feature gate? It has a trivial implementation that is unquestionably correct, and it seemed quite clear in the RFC that it was desired.
One significant issue I see is currently the implementation for returns instead of . Edit: I found the reason. The is instead of as . This was not a problem so far because didn't appear in any function signature until now. So changing the call site for all pointer sizes should be enough.
Hmm…the behavior for different widths (16, 32, or 64). However, usize and u16/32/64 are not the same type. I'll make a modification locally and open a PR shortly.
Yes, exactly. Good job with the PR!
Why of returns instead of ? IMHO, it is not valid.
This is fixed on nightly (that you need anyway to use this for now)
Nice, thank you!

Discussion:
debug_assert!(source.len() == 0); // We should have consumed the source buffer. uint } <del> /// Computes the unsigned absolute value without wrapping or panicking. #[inline] pub fn uabs(value: i64) -> u64 { // The only tricky part here is if value == i64::MIN. In that case, // wrapping_abs() returns i64::MIN == -2^63. Casting this value to a u64 // gives 2^63, the correct value. value.wrapping_abs() as u64 } </del>

<del> use super::{uabs, AllocId, InterpResult}; </del> <ins> use super::{AllocId, InterpResult}; </ins> use rustc_macros::HashStable; use rustc_target::abi::{HasDataLayout, Size};

#[inline] fn overflowing_signed_offset(&self, val: u64, i: i64) -> (u64, bool) { // We need to make sure that i fits in a machine isize. <del> let n = uabs(i); </del> <ins> let n = i.unsigned_abs(); </ins> if i >= 0 { let (val, over) = self.overflowing_offset(val, n); (val, over || i > self.machine_isize_max())

use rustc_hir::def_id::DefId; use rustc_middle::mir::{ self, <del> interpret::{uabs, ConstValue, GlobalId, InterpResult, Scalar}, </del> <ins> interpret::{ConstValue, GlobalId, InterpResult, Scalar}, </ins> BinOp, }; use rustc_middle::ty;

// memory between these pointers must be accessible. Note that we do not require the // pointers to be properly aligned (unlike a read/write operation). let min_ptr = if offset_bytes >= 0 { ptr } else { offset_ptr }; <del> let size: u64 = uabs(offset_bytes); </del> <ins> let size = offset_bytes.unsigned_abs(); </ins> // This call handles checking for integer/NULL pointers. self.memory.check_ptr_access_align( min_ptr,

if val < 0 { neg = true; } <del> Some(val.wrapping_abs() as u128) </del> <ins> Some(val.unsigned_abs()) </ins> }) } _ => {

// It tries to find a positive number k such that `f << k / 10^e` is an in-range // significand. This will result in about `2^53 * f * 10^e` < `10^17 * f * 10^e`. // One input that triggers this is 0.33...33 (375 x 3). <del> f_len + (e.abs() as u64) + 17 </del> <ins> f_len + e.unsigned_abs() + 17 </ins> } }

/// Basic usage: /// /// ``` <del> /// #![feature(unsigned_abs)] </del> #[doc = concat!("assert_eq!(100", stringify!($SelfT), ".unsigned_abs(), 100", stringify!($UnsignedT), ");")] #[doc = concat!("assert_eq!((-100", stringify!($SelfT), ").unsigned_abs(), 100", stringify!($UnsignedT), ");")] /// assert_eq!((-128i8).unsigned_abs(), 128u8); /// ``` <del> #[unstable(feature = "unsigned_abs", issue = "74913")] </del> <ins> #[stable(feature = "unsigned_abs", since = "1.51.0")] #[rustc_const_stable(feature = "unsigned_abs", since = "1.51.0")] </ins> #[inline] pub const fn unsigned_abs(self) -> $UnsignedT { self.wrapping_abs() as $UnsignedT