`ui/deriving/issue-89188-gat-hrtb.rs` test fails with debug assertions enabled

[asquared31415]

The ui/deriving/issue-89188-gat-hrtb.rs test fails due to an arithmetic overflow when debug assertions are enabled.

The offending code likely intends to use the explicit wrapping math methods, as the test does pass with the overflow.

The test was implemented in #89341

Backtrace

thread 'rustc' panicked at 'attempt to subtract with overflow', compiler/rustc_trait_selection/src/traits/project.rs:561:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.57.0-dev running on x86_64-unknown-linux-gnu

note: compiler flags: -Z threads=1 -Z ui-testing -Z deduplicate-diagnostics=no -Z emit-future-incompat-report -C codegen-units=1 -C prefer-dynamic -C rpath -C debuginfo=0

query stack during panic:
#0 [specialization_graph_of] building specialization graph of trait `core::clone::Clone`
#1 [coherent_trait] coherence checking all impls of trait `core::clone::Clone`
end of query stack

[camelid]

The overflowing code is

rust/compiler/rustc_trait_selection/src/traits/project.rs

Lines 560 to 561 in 5641481

	let index =
	self.universe_indices.len() - debruijn.as_usize() + self.current_index.as_usize() - 1;

To me, it actually seems like the overflow might be a bug. @jackh726 it looks like you added this code. Is it incorrect for it to be overflowing?

[nbdd0121]

This is introduced in #86993 with guards like if debruijn.as_usize() + 1 > self.current_index.as_usize() + self.universe_indices.len() => bug!() near call-site. So I suppose just swapping the order should be sufficient?

[jackh726]

Overflowing here is a bug. Given that we haven't seen an index out of bound panics on like 562, I would guess that the actual logic here is correct (so, we underflow, then overflow). I do want to prove to myself that again (and put it in a comment).

[the8472]

If it is really intended then wrapping_sub should be used.

[tlyu]

Oh, I think I ran into this as well and thought it was due to a local change I had made violating an invariant.