chore: do not inline acir calls in brillig

[guipublic]

Description

Problem*

Resolves #9390

Summary*

ACIR calls from Brillig are not inlined and furthermore they are forbidden during ssa validation.

Additional Context

The defunctionalisation pass has also been updated, because of these problems that become visible with this PR:

• the signatures when computing the 'variants' (i.e the set of functions matching a signature) are not checked against their runtime.
• generated code for apply function crash if there is a runtime error, due to not having a location.
• empty variants get a dummy function.

It turns out that calling acir from brillig can happen in the apply function of the defunctionalisation pass: this happens for instance with the zeroed functions generated by the frontend in the lambda_from_dynamic_if test, with force-brillig.
In that case, generating a runtime error when calling acir from brillig generates a crash due to missing location.
Filtering the bad function in the 'variants' works in this case but fail in other cases due to the dummy function.

As a result, I ensured that the apply function never calls acir from brillig by adding an assert if it happens, which provides an error message to the user.

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]

⚠️ Performance Alert ⚠️

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

Benchmark suite	Current: 6d23b0a	Previous: b2713a9	Ratio
sha512_100_bytes	137.5 MB	54.97 MB	2.50

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

CC: @TomAFrench

[TomAFrench]

I remember adding some assertions for this case in the past and from what I remember, I ran into issues with closures. I was working on the understanding that we'd need #7289 before we could enforce this.

[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: a422e94	Previous: 3679e4c	Ratio
test_report_zkpassport_noir-ecdsa_	3 s	1 s	3

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

CC: @TomAFrench

[guipublic]

I remember adding some assertions for this case in the past and from what I remember, I ran into issues with closures. I was working on the understanding that we'd need #7289 before we could enforce this.

Yes this is what is happening here, most tests with lambdas have the issue (most of the case with sorting arrays). At least it is now explicit.

[github-actions]

Changes to Brillig bytecode sizes

Generated at commit: ee564298e0b2681546ded1d4a578c5fe8d1d7798, compared to commit: f0783eaec0ba97f6f2147ace59f6f787dc55d322

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
lambda_from_dynamic_if_inliner_min	-5 ✅	-0.98%
lambda_from_dynamic_if_inliner_zero	-5 ✅	-1.00%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
lambda_from_dynamic_if_inliner_max	608 (-5)	-0.82%
lambda_from_dynamic_if_inliner_min	504 (-5)	-0.98%
lambda_from_dynamic_if_inliner_zero	496 (-5)	-1.00%

[TomAFrench]

Shall we change the base of this PR to go into @jfecher's branch?

[vezenovm]

Shall we change the base of this PR to go into @jfecher's branch?

This PR would be useful for testing out #9484.

[vezenovm]

@guipublic #7289 is resolved so this PR should be ready again once merge conflicts are resolved.