Add overflow_checks intrinsic

[pitaj]

This adds an intrinsic which allows code in a pre-built library to inherit the overflow checks option from a crate depending on it. This enables code in the standard library to explicitly change behavior based on whether overflow_checks are enabled, regardless of the setting used when standard library was compiled.

This is very similar to the ub_checks intrinsic, and refactors the two to use a common mechanism.

The primary use case for this is to allow the new RangeFrom iterator to yield the maximum element before overflowing, as requested here. I already have a working IterRangeFrom implementation based on this new intrinsic that exhibits the desired behavior.

Prior discussion on Zulip

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
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 MIR optimizations

cc @rust-lang/wg-mir-opt

This PR changes Stable MIR

cc @oli-obk, @celinval, @ouz-a

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

This PR changes MIR

cc @oli-obk, @RalfJung, @JakobDegen, @davidtwco, @celinval, @vakaras

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[saethlin]

Given how invasive and boilerplatey the implementation of the intrinsic is, I strongly prefer we not merge this unless it comes with well-motivated use in the standard library implementation.

[pitaj]

Just to be clear, do you mean the existing motivation (better debug behavior for IterRangeFrom) is insufficient?

[saethlin]

Oh wow that wording I left was very unclear. I'll try to explain myself better this time.

The implementation strategy that is currently used for the runtime UB checks (intrinsic which lowers to a new NullOp that's branched on) is concerningly heavy on both compiler implementation complexity and compile-time overhead. There are 4 places where the runtime UB checks are cfg'd out or not merged yet because their compile-time overhead isn't justifiable (ptr::read, ptr::write, Alignment::new_unchecked, and Layout::from_size_align_unchecked). The compile-time overhead is directly caused by the fact that both sides of the if are implemented in the library source.

Before we merge the compiler complexity in this PR, I want evidence that actually using the new intrinsic for its intended purpose has tolerable compile-time overhead. If the compile-time overhead of the approach in this PR is so high that its use must be avoided in often-instantiated code paths, we should find another strategy. So what would make me happy is a draft PR based on this one (or just modifying this PR) that swaps in the new range types and uses this new overflow_checks() intrinsic in their implementation, and a perf run that demonstrates a tolerable compile-time hit.

---

I've mostly put up with the UB checks implementation because I have finite time to investigate things, and it has so far been a mostly-successful way to deliver a feature we've been missing for years. My leading theory on a better way to do this is to have a magic const (I mentioned it in this issue #120848 and now I wish I could link to that one checkbox directly) because that would prevent this system from leaking into the types for MIR.

[bors]

☔ The latest upstream changes (presumably #128707) made this pull request unmergeable. Please resolve the merge conflicts.

[BoxyUwU]

It's worth noting that like the UB checks flag, if this gets added we need to ensure that ctfe always runs with either the flag enabled or disabled and is not affected by any kind of rustc flag as otherwise it would be unsound for const generics (#129552). I think what @saethlin said about making sure this is actually usable in practice is a good point so marked this as S-blocked until that is resolved.

[celinval]

I'm wondering if these cases where we want to enable extra checks in the standard library should be fixed by improving and stabilizing the cargo option to build the standard library together with the target crate.

[saethlin]

I too would love to see all of the issues addressed: https://github.com/rust-lang/wg-cargo-std-aware/issues?q=is%3Aissue+label%3A%22stabilization+blocker%22+is%3Aopen but it's a huge engineering and political effort. If you'd like to push forward such work, a PR is not the right place to advocate for it.

[celinval]

I too would love to see all of the issues addressed: https://github.com/rust-lang/wg-cargo-std-aware/issues?q=is%3Aissue+label%3A%22stabilization+blocker%22+is%3Aopen but it's a huge engineering and political effort. If you'd like to push forward such work, a PR is not the right place to advocate for it.

I'm just trying to understand the motivation behind the chosen approach, which I think is a fair point to ask.

What are the trade-offs and why this has to be solved by adding more logic to the compiler backend so the std library behaves like any other cargo dependency.

From what I understand, building the standard library in cargo is out of the table given its current state. So thank you for clarifying.