indirect-const-stabilize the exact_div intrinsic

[scottmcm]

See #74985 (comment)

[rustbot]

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

[scottmcm]

Hello lang folks!

I propose we const-stabilize the exact_div intrinsic for indirect use.

This is the equivalent of udiv exact or sdiv exact in LLVM: a division that, in addition to needing to not wrap or divide by zero, is UB if the numerator is not an exact multiple of the denominator. (Well, in LLVM it's poison, but to Rust the intrinsic is UB.)

It was originally added in #61885 for use converting the byte instance between pointers in the slice iterator to item differences, since an iterator over i32s can never have pointers 6 bytes apart, for example. That's no longer done in library code, though, as instead it uses the ptr_offset_from_unsigned intrinsic that uses the same mechanism internally.

It's coming up now because as_chunks uses it internally, so we'd need to allow this to stabilize that with its current implementation. (Technically as_chunks doesn't need it, but as_chunks_unchecked uses it.)

I think we should just stabilize it, even if libs decides to change that implementation, because it's not a big deal to allow in const. Everything it can do could be done with hint::assert_unchecked(a % b == 0), so we're not enabling any complicated new things. Abstracted a bit, this is just the simple case of value-based UB on integers that doesn't open any of the complicated doors, because it just cares about the values, not about state (in the machine or shadowy state).

And it would be legal to implement it as just /, so it's not forcing us to have some complicated implementation going forward. (Not that the implementation today is hard, and most of the pieces in the compiler to deal with it we'd need anyway for offset_from_unsigned.)

@rfcbot fcp merge

[rfcbot]

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

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

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!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[RalfJung]

FWIW, we don't yet have confirmation whether slice_as_chunks is also part of the t-libs-api FCP in #74985, so it's not clear yet whether exact_div will be needed. But I agree it doesn't hurt to const-stabilize this in either case.

[RalfJung]

With this, you should be able to remove the rustc_const_unstable from the slice_as_chunks methods. (They will still remain unstable due to #[unstable].)

Doing so is a good conformation to ensure there's nothing else preventing their const stabilization.

[scottmcm]

Oh, good point! Thanks!

[RalfJung]

As usual please Cc @rust-lang/wg-const-eval on const stabilizations.

This is a simple intrinsic, acting on immediate values with a clear spec. So no concerns from my side.

[traviscross]

All sounds right.

@rfcbot reviewed

[jhpratt]

LGTM; r=me when appropriate

[tmandry]

@rfcbot reviewed

[rfcbot]

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