fix(frontend)!: Ban zero sized arrays and strings as program input

[vezenovm]

Description

Problem*

Resolves #8451

Summary*

I expanded the is_valid_for_program_input cases for array and string by calling a new array_or_string_len_is_not_zero method.

Additional Context

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[jfecher]

There's no reason to allow these anyway

[github-actions]

Changes to number of Brillig opcodes executed

Generated at commit: 253d9056a2e4a12fcce6f34589fe5d5b0eb64e97, compared to commit: b657b076bdcfcf627a318237276a917d8e067e0f

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
regression_8261_inliner_max	-17 ✅	-8.46%
regression_8261_inliner_min	-17 ✅	-8.46%
regression_8261_inliner_zero	-17 ✅	-8.46%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
regression_8261_inliner_max	184 (-17)	-8.46%
regression_8261_inliner_min	184 (-17)	-8.46%
regression_8261_inliner_zero	184 (-17)	-8.46%

[github-actions]

Changes to Brillig bytecode sizes

Generated at commit: 253d9056a2e4a12fcce6f34589fe5d5b0eb64e97, compared to commit: b657b076bdcfcf627a318237276a917d8e067e0f

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
regression_8261_inliner_max	-11 ✅	-8.21%
regression_8261_inliner_min	-11 ✅	-8.21%
regression_8261_inliner_zero	-11 ✅	-8.21%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
regression_8261_inliner_max	123 (-11)	-8.21%
regression_8261_inliner_min	123 (-11)	-8.21%
regression_8261_inliner_zero	123 (-11)	-8.21%

[vezenovm]

regression_8261_inliner_max -17 ✅ -8.46%
regression_8261_inliner_min -17 ✅ -8.46%
regression_8261_inliner_zero -17 ✅ -8.46%

A parameter (empty string) was removed from these tests so this makes sense.

[TomAFrench]

@vezenovm there's a couple of test failures here.

[vezenovm]

@vezenovm there's a couple of test failures here.

Yeah I'm fixing them right now

[vezenovm]

One caveat of this PR is that if someone provides an incorrect numeric generic type to an array we will trigger this error as well now as the array type will have failed to resolve. This snippet is compile_failure/brillig_vec_to_acir

global DEPTH: Field = 40000;
fn main(x: [u32; DEPTH], y: u32) {
    let mut new_x = Vec::new();
    new_x = clear(x, y);
}
unconstrained fn clear(x: [u32; DEPTH], y: u32) -> Vec<u32> {
    let mut a = Vec::new();
    for i in 0..y {
        a.push(x[i]);
    }
    a
}

It previously had this stderr:

error: The numeric generic is not of type `u32`
  ┌─ src/main.nr:3:12
  │
3 │ fn main(x: [u32; DEPTH], y: u32) {
  │            ------------ expected `u32`, found `Field`
  │

error: The numeric generic is not of type `u32`
  ┌─ src/main.nr:8:27
  │
8 │ unconstrained fn clear(x: [u32; DEPTH], y: u32) -> Vec<u32> {
  │                           ------------ expected `u32`, found `Field`
  │

error: Call to unconstrained function is unsafe and must be in an unconstrained function or unsafe block
  ┌─ src/main.nr:5:13
  │
5 │     new_x = clear(x, y);
  │             -----------
  │

error: Slices cannot be returned from an unconstrained runtime to a constrained runtime
  ┌─ src/main.nr:5:13
  │
5 │     new_x = clear(x, y);
  │             -----------
  │

Aborting due to 4 previous errors

It now has this stderr:

error: The numeric generic is not of type `u32`
  ┌─ src/main.nr:3:12
  │
3 │ fn main(x: [u32; DEPTH], y: u32) {
  │            ------------ expected `u32`, found `Field`
  │

error: Only sized types may be used in the entry point to a program
  ┌─ src/main.nr:3:12
  │
3 │ fn main(x: [u32; DEPTH], y: u32) {
  │            ------------ Slices, references, or any type containing them may not be used in main, contract functions, or foldable functions
  │

error: The numeric generic is not of type `u32`
  ┌─ src/main.nr:8:27
  │
8 │ unconstrained fn clear(x: [u32; DEPTH], y: u32) -> Vec<u32> {
  │                           ------------ expected `u32`, found `Field`
  │

error: Call to unconstrained function is unsafe and must be in an unconstrained function or unsafe block
  ┌─ src/main.nr:5:13
  │
5 │     new_x = clear(x, y);
  │             -----------
  │

error: Slices cannot be returned from an unconstrained runtime to a constrained runtime
  ┌─ src/main.nr:5:13
  │
5 │     new_x = clear(x, y);
  │             -----------
  │

Aborting due to 5 previous errors

For the purpose of the test I switched to using a u32 type for the array input as that is not what this code is testing. But just noting here.