// Test evaluation order of operands of the compound assignment operators

// run-pass

use std::ops::AddAssign;

enum Side {
    Lhs,
    Rhs,
}

// In the following tests, we place our value into a wrapper type so that we
// can do an element access as the outer place expression. If we just had the
// block expression, it'd be a value expression and not compile.
struct Wrapper<T>(T);

// Evaluation order for `a op= b` where typeof(a) and typeof(b) are primitives
// is first `b` then `a`.
fn primitive_compound() {
    let mut side_order = vec![];
    let mut int = Wrapper(0);

    {
        side_order.push(Side::Lhs);
        int
    }.0 += {
        side_order.push(Side::Rhs);
        0
    };

    assert!(matches!(side_order[..], [Side::Rhs, Side::Lhs]));
}

// Evaluation order for `a op=b` otherwise is first `a` then `b`.
fn generic_compound<T: AddAssign<T> + Default>() {
    let mut side_order = vec![];
    let mut add_assignable: Wrapper<T> = Wrapper(Default::default());

    {
        side_order.push(Side::Lhs);
        add_assignable
    }.0 += {
        side_order.push(Side::Rhs);
        Default::default()
    };

    assert!(matches!(side_order[..], [Side::Lhs, Side::Rhs]));
}

fn custom_compound() {
    struct Custom;

    impl AddAssign<()> for Custom {
        fn add_assign(&mut self, _: ()) {
            // this block purposely left blank
        }
    }

    let mut side_order = vec![];
    let mut custom = Wrapper(Custom);

    {
        side_order.push(Side::Lhs);
        custom
    }.0 += {
        side_order.push(Side::Rhs);
    };

    assert!(matches!(side_order[..], [Side::Lhs, Side::Rhs]));
}

fn main() {
    primitive_compound();
    generic_compound::<i32>();
    custom_compound();
}

Add test for eval order for a+=b
Add test for eval order for a+=b

Yes, the order of evaluation *does* change depending on the types of
the operands. Cursed, I know.

I've elected to place this test into `expr/compound-assignment` creating
both the `expr` directory and the `compound-assignment` directory. I
plan in a future PR to also move the `if` directory and the loose `if`
tests into `expr/if` and other similar cleanups of the `test/ui`
directory.

Future work: Test more than just `+=`, but all operators. I don't know
if using a macro to generate these tests cases would be okay or not,
but it'd be boilerplatey without it. I'm also confident you cannot
change the evaluation order of one operator without changing all of
them.

Future work: Additionally, test more than just `i32 += i32` for the
primitive version. I don't actually know the full set of primitive
implementations, but I imagine there's enough to cause a combinatorial
explosion with the previous future work item. Somewhere on the order of
one to two hundred individual functions.
