SSA with binary operation with operands of type reference

[sirasistant]

Aim

The references test (tests::prove_and_verify_test_data_ssa_refactor_references):

fn main() {
    let mut x = 2;
    add1(&mut x);
    assert(x == 3);

    let mut s = S { y: x };
    s.add2();
    assert(s.y == 5);

    // Test that normal mutable variables are still copied
    let mut a = 0;
    mutate_copy(a);
    assert(a == 0);

    // Test something 3 allocations deep
    let mut nested_allocations = Nested { y: &mut &mut 0 };
    add1(*nested_allocations.y);
    assert(**nested_allocations.y == 1);

    // Test nested struct allocations with a mutable reference to an array.
    let mut c = C {
        foo: 0,
        bar: &mut C2 {
            array: &mut [1, 2],
        },
    };
    *c.bar.array = [3, 4];
    assert(*c.bar.array == [3, 4]);
}

should compile even if x is passed as parameter (reducing SSA simplifications before ACIR gen)

fn main(mut x: Field) {
    add1(&mut x);

Expected Behavior

The test should pass

Bug

The application panicked (crashed).
Message:  internal error: entered unreachable code: References are invalid in binary operations
Location: crates/noirc_evaluator/src/ssa_refactor/acir_gen/mod.rs:576

The issue seems to be in the add2 function:

struct S { y: Field }

impl S {
    fn add2(&mut self) {
        self.y += 2;
    }
}

That seems to generate SSA with a binary op with parameters of Type::Reference.

To Reproduce

Installation Method

None

Nargo Version

No response

Additional Context

No response

Would you like to submit a PR for this Issue?

No

Support Needs

No response

[jfecher]

I was thinking this may be an issue with a dereference operation not getting inserted somewhere but the generated SSA code actually looks correct to me:

After Dead Instruction Elimination:
acir fn main f2 {
  b0(v0: Field):
    v14 = add v0, Field 2
    v15 = eq v14, Field 5
    constrain v15
    return 
}

It may be that x is registered as having a reference type rather than a Field type.
Nevermind, clearly I missed the large v0 :Field at the beginning.
This might be an acir-gen error in tracking values incorrectly or failing to call dfg.resolve(value_id).