Use #[rustc_inherit_overflow_checks] instead of Add::add etc.

[m-ou-se]

See #81721

[m-ou-se]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit bd1eb210f1636b4e69055bc37b1a5b118a2fed26 with merge 373cca1b4f95bdf0298d4add9943f805161c8c87...

[eddyb]

Hah, does this work? I half-expected it not to.

[m-ou-se]

Haha, this was your suggestion.. But yeah, it compiles. I think it works too, but I should check if it actually gets tested for this behaviour. :)

[eddyb]

Yeah, I was going off having seen #[inline(never)], IIRC, on closures, but I wasn't sure it would work out of the box.

[bors]

☀️ Try build successful - checks-actions
Build commit: 373cca1b4f95bdf0298d4add9943f805161c8c87 (373cca1b4f95bdf0298d4add9943f805161c8c87)

[rust-timer]

Queued 373cca1b4f95bdf0298d4add9943f805161c8c87 with parent e708cbd, future comparison URL.

[rust-timer]

Finished benchmarking try commit (373cca1b4f95bdf0298d4add9943f805161c8c87): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

[m-ou-se]

Okay this looks good, no regression in performance, and even a few percent improvement for cranelift.

To do: Verify that it actually works the same as before. I'm not sure if we test all these cases for ther release/debug-mode panic behaviour.

[m-ou-se]

To do: Verify that it actually works the same as before. I'm not sure if we test all these cases for ther release/debug-mode panic behaviour.

Manually verified that it behaves the same. Looks like there's also already tests for these in src/test/ui/iterators/iter-*-overflow-debug.rs.

[m-ou-se]

r? @Mark-Simulacrum

[Mark-Simulacrum]

Hm, so I initially thought "this seems wrong, don't we need it on the fn sum too? But it looks like in practice inherit is a bit wrong - this attribute just forces the MIR to contain overflow checks in all cases, and then when we codegen (potentially in a downstream crate) they'll get removed. So I think we're good -- not sure what a better name for the attribute is, but inherit definitely feels a bit off.

[m-ou-se]

Yeah, the inherit here is about crates rather than functions, in some sense.

[eddyb]

Yeah, "inherit" refers to the crate it's codegen'd in. So it's more "defer"? Or we can go more explicit really:

#[rustc_use_overflow_checks_settings_from_user_crate]

We could also make the attribute warn/error if building the MIR doesn't end up making a decision based on it, because that's what usually happens if it's applied to the wrong thing (e.g. a function doing iter.fold(...) instead of a closure).

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 053769d has been approved by Mark-Simulacrum

[bors]

⌛ Testing commit 053769d with merge e952db8...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing e952db8 to master...