Debugger panic when assessing complex slice

[vezenovm]

Aim

I want to run the debugger on this program:

fn main() {
    let var1: [(i32, u8)] = [(1, 2)];
    let var2: [(i32, u8)] = var1;
}

@ggiraldez @mverzilli

Expected Behavior

I expected the debugger to complete successfully.

Bug

I get this output:

The application panicked (crashed).
Message:  called `Option::unwrap()` on a `None` value
Location: /mnt/user-data/maxim/noir/compiler/noirc_printable_type/src/lib.rs:316

To Reproduce

1. Make a program with the main posted above
2. nargo debug
3. continue

Project Impact

Nice-to-have

Impact Context

No response

Workaround

None

Workaround Description

No response

Additional Context

No response

Installation Method

None

Nargo Version

No response

NoirJS Version

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response

[ggiraldez]

This issue manifests with the debugger, but it's a problem with the array to slice coercion intrinsic. When simplifying the coercion, the code does not take into account that for SSA, complex types such as tuples and structs are flattened, resulting in an array representation with length of elements times the size of the complex type (as a result of the flattening). This bug is easily reproducible with this code, which fails the assertion:

fn main() {
    let var1: [(i32, u8)] = [(1, 2)];
    assert(var1.len() == 1);
}

Then, when trying to decodes the printable value from the type, the foreign function gets the wrong length of the slice, and attempts to decode more elements than what's available. This is also reproducible with printing the value:

fn main() {
    let var1: [(i32, u8)] = [(1, 2)];
    dep::std::println(var1);
}

The debugger uses the same decoding machinery as println, so this crashes in the same way as described in the OP.

I will submit a PR in a moment.