Adding a trait bound can change evaluation order of compound assignments and change drop behavior of closures.

I'm not sure if this is a bug or not.

This is a consequence of https://github.com/rust-lang/rust/issues/24066, and uses the same setup as https://github.com/rust-lang/rust/issues/149234

trait ToI32 {
    type I32: Default + std::ops::AddAssign;
}
impl<T> ToI32 for T {
    type I32 = i32;
}

fn make<U: Default>(msg: &str) -> U {
    println!("{msg}");
    U::default()
}

fn foo<T: ToI32>() {
    *&mut make::<<T as ToI32>::I32>("left") += make::<<T as ToI32>::I32>("right");
}

fn bar<T>() {
    *&mut make::<<T as ToI32>::I32>("left") += make::<<T as ToI32>::I32>("right");
}

fn main() {
    foo::<()>();
    bar::<()>();
}

I expected foo and bar to behave the same way. Instead, I got the following output:

left
right
right
left

It is documented in the reference that the evaluation order of compound assignment expressions depends on whether the types involved are primitives or not. That is, for primitives, the right operand is evaluated first, but for other types, the left operand is evaluated first.

It seems that adding a ToI32 trait bound causes the compiler to no longer see that the type involved is i32, causing the evaluation order to change.

Meta

Reproducible on the playground with version 1.91.0-nightly (2025-09-10 565a9ca63e9df4b223fe)

Start by running the supplied Rust reproducer and compare the foo, bar, and main entry points against the linked compound-assignment rule in the Reference. Trace why the associated type changes operand evaluation order, then establish whether the behavior is intended; done requires a documented diagnosis and, if it is a compiler bug, a regression test and fix.