Output of to_le_bits doesn't work for functions that take generic array inputs

[shuklaayush]

Aim

Running the following tests causes in a panic in test1 while test2 passes

fn and<N>(bits: [u1; N]) -> u1 {
    let mut ans: u1 = 1;
    for i in 0..bits.len() {
        ans *= bits[i];
    }
    ans
}

global n = 11;

#[test]
fn test1() {
    let bits = n.to_le_bits(4);

    let ans = and(bits);
    assert(ans == 0);
}

#[test]
fn test2() {
    let tmp = n.to_le_bits(4);
    let mut bits = [0; 4];
    for i in 0..4 {
       bits[i]= tmp[i]; 
    }

    let ans = and(bits);
    assert(ans == 0);
}

Expected behavior

Both tests should pass

Bug

Error message:

Running 1 test functions...
Testing test1...
The application panicked (crashed).
Message:  called `Option::unwrap()` on a `None` value
Location: crates/noirc_frontend/src/monomorphization/mod.rs:729

To reproduce

1. Copy the code above
2. Run nargo test --show-output --allow-warnings test1

Installation method

Binary

Nargo version

nargo 0.5.1 (git version hash: 7f6dede, is dirty: false)

@noir-lang/noir_wasm version

No response

@noir-lang/barretenberg version

No response

@noir-lang/aztec_backend version

No response

Additional context

No response

Submission Checklist

• Once I hit submit, I will assign this issue to the Project Board with the appropriate tags.

[jfecher]

This is caused by a bug where the length of the array returned by to_le_bits (and friends) is unknown to the type system since it depends on the argument to the function. A quick fix for now may be to specify the size you expect the array to be:

let bits: [u1; 3] = n.to_le_bits(4);

But this is obviously suboptimal if the argument is not a constant and thus the length is unknown.

[shuklaayush]

A quick fix for now may be to specify the size you expect the array to be:

let bits: [u1; 4] = n.to_le_bits(4);

Even this doesn't work. I get the following error which I guess is suggesting the same problem that you mentioned

error: Expected type [u1; 4], found type [u1; _]

[kevaundray]

@jfecher what is the status of this issue?

[jfecher]

@kevaundray still open. It has the same cause as most other to_{le,be}_{bits,bytes} bugs. These functions claim they return an array of any length in the stdlib but really they just return a different length depending on the input. We can't express this in the type system so we need to change them to either return slices or return an array with a maximum size and fill zeroes in for the rest.