Partial stabilization of "nonzero_checked_ops".

[iago-lito]

Stabilizing checked arithmetics on NonZero types under #![feature(nonzero_checked_ops)] (previously nonzero_ops).

Not closing #84186 as only checked methods are stabilized here.
As per #84186 (comment), the two remaining unchecked methods unchecked_add and unchecked_mul will remain feature-gated under #![feature(nonzero_ops)] until #85122 is stabilized.

Unresolved questions:

• I've taken this opportunity to also implement/stabilize the infra-stable impl Neg for NonZeroI* as part of this PR. Is this the appropriate time to do so?
  • Nope : moved to impl Neg for NonZeroI* #97907.
• I went ahead and marked the stabilized methods as also rustc_const_stable. Is this okay?
  • Nope, moved to Stabilize NonZero* checked operations constness. #97908.
• I got a little mixed up with rustc_const_unstable attributes and marked constness of the stabilized methods as feature-gated by const_nonzero_checked_ops, and referring to Partial stabilization of "nonzero_checked_ops". #97547.. It's the best I could come up with, but it does feel weird, is it?

@rustbot modify labels: +T-libs-api

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

[iago-lito]

r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs

[yaahc]

@rfcbot merge

[rfcbot]

Team member @yaahc has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[yaahc]

• I've taken this opportunity to also implement/stabilize the infra-stable impl Neg for NonZeroI* as part of this PR. Is this the appropriate time to do so?

I think it's fine to collapse them though I'd definitely recommend having separate PRs that way issues on one part of the PR can't block acceptance of the rest of the PR.

I went ahead and marked the stabilized methods as also rustc_const_stable. Is this okay?

I don't think so, though this is another case where if it's something you need I'd recommend handling that as a separate PR. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html#when-theres-const-involved

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.