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. This PR includes 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.

[BoxyUwU]

I'm gonna close this since it's not had any activity for ~2 months and making progress seems somewhat blocked. Feel free to re-open this at some future point.

[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

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred to constck

cc @fee1-dead

[pitaj]

Reopening this because I noticed the recent addition of the contract_checks intrinsic, and thought of a way to try the overflow_checks intrinsic out by modifying the legacy RangeFrom code to use it.

Running perf on this PR should give us some idea of how much impact this kind of check would have on compile times if the new RangeFrom became the default. Tests are expected to fail, but perf should still be able to run (the broken logic only affects debug mode).

[celinval]

Reopening this because I noticed the recent addition of the contract_checks intrinsic, and thought of a way to try the overflow_checks intrinsic out by modifying the legacy RangeFrom code to use it.

Running perf on this PR should give us some idea of how much impact this kind of check would have on compile times if the new RangeFrom became the default. Tests are expected to fail, but perf should still be able to run (the broken logic only affects debug mode).

FYI, I'm contemplating removing contract_checks. Not sure the cost is worth it at least for contracts.

[bors]

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

[rustbot]

This PR changes rustc_public

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

[pitaj]

I've rebased this on latest master, and moved the perf-testing commit to #146288

[bors]

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

[RalfJung]

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

This has so far been done with the rustc_inherit_overflow_checks attribute. Is that not viable here? In particular you can deliberately trigger an overflow in some situations to have a "conditional panic":

rust/library/core/src/iter/range.rs

Lines 237 to 241 in 6a9f223

	// In debug builds, trigger a panic on overflow.
	// This should optimize completely out in release builds.
	if Self::backward_checked(start, n).is_none() {
	let _ = Self::MIN - 1;
	}

If we have two mechanisms that do almost the same thing like this, we should also have clear guidance somewhere on which one to use when.

[pitaj]

@RalfJung maybe my explanation wasn't great.

The use case this supports is not something that can be achieved with just that attribute. That implementation is actually included in this PR in case you didn't see it, see commit 74cccf7

It's not just a conditional panic, it's the extra work of not panicking when the overflow would normally happen, deferring that panic to the subsequent call.

(Maybe it's possible another way but I haven't been able to work it out, and I've tried a lot)

[pitaj]

@saethlin

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.

#146288 adds additional code, gated by this new intrinsic, to the Iterator::next function for ops::RangeFrom. The perf run just completed, with no significant hit to compile times.

Can we consider the matter resolved?

[saethlin]

Yes, I think you've demonstrated that there is a fair chance this does not have significant compile-time overhead.

[pitaj]

Perfect! Thanks for the quick response.

@rustbot ready

[bors]

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

[BoxyUwU]

you say UB checks a bunch here, it should be overflow checks instead right?

[BoxyUwU]

Suggested change

	/// sysroot which is built without overflow_checks but with `#[rustc_preserve_overflow_checks]`.
	/// sysroot which is built without overflow_checks but with `#[rustc_inherit_overflow_checks]`.

judging by ur tests

[BoxyUwU]

this means that overflow checks using the intrinsic will always be run by ctfe, even when debug assertions and overflow checks are disabled. can you add a test for this?

[BoxyUwU]

compiler impl looks reasonable to me. If you split out the libs changes to a separate PR I can approve this myself, otherwise needs libs approval too. I'm not sure where tests for libs stuff is supposed to go, I'm not certain that it's tests/ui but I honestly couldn't tell you

[BoxyUwU]

sorry for taking a while to get to this. needs a rebase too

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[pitaj]

@rustbot ready

@BoxyUwU I think it makes sense to get libs buyoff before merging this. Its whole purpose is to support a libs usecase, so best to make sure they support that first.

I will request a review from libs once this has your approval for the compiler portion. Thanks!