fix: slice push_back when length is not known

[guipublic]

Description

Problem*

Resolves #10170

Summary*

'Slice push_back' push after the slice length, which is not the same as the slice end when the capacity is bigger than the slice length.

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.

[github-actions]

Changes to number of Brillig opcodes executed

Generated at commit: 94b4668afa2335c68268f01c42d5d2c589901481, compared to commit: fcafe4e506fe1c2a5d4fc61fb923429db185e312

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
slices_inliner_max	+1,089 ❌	+43.01%
slices_inliner_zero	+1,097 ❌	+40.18%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
slices_inliner_max	3,621 (+1,089)	+43.01%
slices_inliner_zero	3,827 (+1,097)	+40.18%
slices_inliner_min	4,919 (+1,120)	+29.48%
nested_array_in_slice_inliner_max	1,383 (+184)	+15.35%
nested_array_in_slice_inliner_min	1,476 (+178)	+13.71%
nested_array_in_slice_inliner_zero	1,476 (+178)	+13.71%

[github-actions]

Changes to Brillig bytecode sizes

Generated at commit: 94b4668afa2335c68268f01c42d5d2c589901481, compared to commit: fcafe4e506fe1c2a5d4fc61fb923429db185e312

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
slices_inliner_zero	+477 ❌	+29.00%
slices_inliner_max	+473 ❌	+28.07%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
slices_inliner_zero	2,122 (+477)	+29.00%
slices_inliner_max	2,158 (+473)	+28.07%
slices_inliner_min	2,671 (+491)	+22.52%
nested_array_in_slice_inliner_max	1,014 (+13)	+1.30%
nested_array_in_slice_inliner_min	817 (+8)	+0.99%
nested_array_in_slice_inliner_zero	817 (+8)	+0.99%

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Test Suite Duration'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: c38428a	Previous: fcafe4e	Ratio
test_report_zkpassport_noir_rsa_	2 s	1 s	2

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench

[github-actions]

Changes to circuit sizes

Generated at commit: 94b4668afa2335c68268f01c42d5d2c589901481, compared to commit: fcafe4e506fe1c2a5d4fc61fb923429db185e312

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
slices	+154 ❌	+91.12%	+678 ❌	+20.82%
nested_array_in_slice	+164 ❌	+20.15%	+584 ❌	+11.99%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
slices	323 (+154)	+91.12%	3,935 (+678)	+20.82%
nested_array_in_slice	978 (+164)	+20.15%	5,456 (+584)	+11.99%
array_to_slice	59 (+14)	+31.11%	3,024 (+98)	+3.35%
slice_dynamic_index	804 (+5)	+0.63%	5,157 (+62)	+1.22%

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Execution Time'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: c9e985e	Previous: 6424d4a	Ratio
sha512-100-bytes	0.084 s	0.052 s	1.62

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench

[asterite]

I think there's still something to improve here (I'll write this and then investigate it a bit more).

Given this code:

fn main(cond: bool, index: u32) -> pub Field {
    let mut slice = &[0, 1];
    if cond {
        slice = slice.push_back(2);
    }

    let slice = slice.push_back(3);
    let (slice, _) = slice.pop_back();

    let slice = slice.push_back(4);
    let (slice, _) = slice.pop_back();

    let slice = slice.push_back(5);
    let (slice, _) = slice.pop_back();

    let slice = slice.push_back(6);
    let (slice, _) = slice.pop_back();

    slice[index]
}

statically we can determine that the slice max length won't exceed 4, because we start with 2 elements, then conditionally push one more, then push one more and remove it, etc.

However, the generated ACIR has this:

func 0
private parameters: [w0, w1]
public parameters: []
return values: [w2]
...
INIT b0 = [w6, w7, w8, w9]
...
INIT b1 = [w15, w16, w17, w18]
...
INIT b3 = [w15, w16, w17, w18, w6]
...
INIT b5 = [w23, w24, w25, w26, w27, w6]
...
INIT b7 = [w30, w31, w32, w33, w34, w35, w6]
...
INIT b8 = [w38, w39, w40, w41, w42, w43, w44]
...

I'm not exactly sure why this happens. Maybe it's because when we do slice_pop_back we don't remove any elements from the back of the array. If we write the same Noir code but using slice_pop_front then the array stays at a maximum length of 4.

Out of curiosity, I'm going to try applying the change from #10179 in this PR to see what happens (I'll do it after running all tests locally).

[asterite]

Cool, it improved things a tiny bit :-)

[asterite]

Looks good!