Cannot access slice of slice in unconstrained environment

[vezenovm]

Aim

Slices as fields of structs is currently not enabled in ACIR, but this should be possible with Brillig.

For example:

struct Key
{
    bytes : [u8]
}

struct KeyList
{
    keys : [Key]
}

impl KeyList
{
    unconstrained fn new(&mut self)
    {
        self.keys = [ Key { bytes: "a".as_bytes() } ];
    }

    unconstrained fn new2() -> Self
    {
        Self { keys : [ Key { bytes: "a".as_bytes() } ] }
    }
}

#[test]
unconstrained fn test_mutable_member_slice()
{
    let key_bytes = "a".as_bytes();

    let mut wrap = KeyList { keys : [] };
    wrap.new();

    assert(wrap.keys.len() != 0);                     // OK
    assert(wrap.keys[0].bytes.len() != 0);            // OK
    // assert(wrap.keys[0].bytes[0] == key_bytes[0]); // crash index out of bounds: the len is 9 but the index is 97; brillig_vm-0.27.0/src/memory.rs:19

    let wrap2 = KeyList::new2();

    assert(wrap2.keys.len() != 0);                     // OK
    assert(wrap2.keys[0].bytes.len() != 0);            // OK
    // assert(wrap2.keys[0].bytes[0] == key_bytes[0]); // crash, same message

    let wrap3 = KeyList { keys : [ Key { bytes: key_bytes } ] };

    assert(wrap3.keys.len() != 0);                     // OK
    assert(wrap3.keys[0].bytes.len() != 0);            // OK
    // assert(wrap3.keys[0].bytes[0] == key_bytes[0]); // crash, same message
}

Expected Behavior

I should be able to access the heap vectors during Brillig runtime like I do any other slice.

Bug

We panic inside of the Brillig VM:

Message:  index out of bounds: the len is 9 but the index is 97
Location: acvm-repo/brillig_vm/src/memory.rs:19

The index being 97 definitely throws me off as that seems much too high.

To Reproduce

1. Copy the snippet over to a Noir program
2. Run nargo test

Installation Method

Compiled from source

Nargo Version

nargo 0.15.0 (git version hash: 9854416, is dirty: true)

Additional Context

As we have not yet made the effort to implement slices as struct fields in ACIR there is a chance that SSA gen itself has incorrect codegen for tuple member accesses. This would be good to check as the slices themselves are represented by a tuple of (length, contents) which could be the cause of issues if not handled appropriately.

Would you like to submit a PR for this Issue?

No

Support Needs

No response

[vezenovm]

Nested slices have been banned and we are leaning into BoundedVec for now #4197 due to a combination of their complexity + inefficiency in ACIR.

Slice of slices may be brought back in the future, but we want to have parity in feature across our constrained and unconstrained environment. Apologies for any inconvenience this may cause. Closing this issue for now.