Repository: rust
Issue: Tracking Issue for inherent unchecked integer methods
Labels: T-libs-api,C-tracking-issue

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

This is a tracking issue for the `unchecked_*` methods on integers.

## `unchecked_math` (stable as of #122520)

```rust
impl uN {
    pub const unsafe fn unchecked_add(self, rhs: uN) -> uN;
    pub const unsafe fn unchecked_sub(self, rhs: uN) -> uN;
    pub const unsafe fn unchecked_mul(self, rhs: uN) -> uN;
}
impl iN {
    pub const unsafe fn unchecked_add(self, rhs: iN) -> iN;
    pub const unsafe fn unchecked_sub(self, rhs: iN) -> iN;
    pub const unsafe fn unchecked_mul(self, rhs: iN) -> iN;
}
```

### Steps / History

- [x] #69659 added `unchecked_{add,sub,mul}`
- [x] #85096
- [x] #115626
- [x] #122520
- [x] #121571

## `unchecked_neg`

```rust
impl iN {
    pub const unsafe fn unchecked_neg(self) -> iN;
}

```

### Steps / History

- [x] #115626 added `unchecked_neg`
- [x] #121571

## `unchecked_shifts`

```rust
impl uN {
    pub const unsafe fn unchecked_shl(self, rhs: u32) -> uN;
    pub const unsafe fn unchecked_shr(self, rhs: u32) -> uN;
}
impl iN {
    pub const unsafe fn unchecked_shl(self, rhs: u32) -> iN;
    pub const unsafe fn unchecked_shr(self, rhs: u32) -> iN;
}
```

### Steps / History

- [x] #85703
- [x] #103456
- [x] #115626
- [x] #121571

## `unchecked_*` (aggregate)

```rust
impl uN {
    pub const unsafe fn unchecked_add(self, rhs: uN) -> uN;
    pub const unsafe fn unchecked_sub(self, rhs: uN) -> uN;
    pub const unsafe fn unchecked_mul(self, rhs: uN) -> uN;
    pub const unsafe fn unchecked_shl(self, rhs: u32) -> uN;
    pub const unsafe fn unchecked_shr(self, rhs: u32) -> uN;
}
impl iN {
    pub const unsafe fn unchecked_add(self, rhs: iN) -> iN;
    pub const unsafe fn unchecked_sub(self, rhs: iN) -> iN;
    pub const unsafe fn unchecked_mul(self, rhs: iN) -> iN;
    pub const unsafe fn unchecked_shl(self, rhs: u32) -> iN;
    pub const unsafe fn unchecked_shr(self, rhs: u32) -> iN;
    pub const unsafe fn unchecked_neg(self) -> iN;
}
```

### Steps / History

- [x] #69659 added `unchecked_{add,sub,mul}`
- [x] #85096
- [x] #85703
- [x] #103456
- [x] #115626 added `unchecked_neg`
- [x] #122520
- [x] #121571
- [ ] Final commenting period (FCP)
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final commenting period
(FCP) is always needed before stabilization. This works as follows:

A library team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
commenting period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilzation PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- Should the other unchecked intrinsics like `exact_div` also get inherent versions?
- From #85703, consider if distinguishing the different kinds of ub could be useful (UB from overflow like `MIN/-1` or `MAX+1`, LLVM's `n[us]w`; UB from input range like `x/0` or `x << -1`; UB from lossy like `2/4` or `3 >> 1`, LLVM's `exact`)

Resolved unresolved questions:
- <del>Is `unchecked_*` the best naming for these?</del> <ins>We stabilised `unchecked_{add,sub,mul}` already, so, yes.</ins>