feat: Evaluation of dynamic assert messages

[vezenovm]

Description

Problem*

Resolves #3113

Summary*

The first major change is a new MacroProcessor that generates an oracle and the respective unconstrained oracle wrapper for resolving assert message expressions. This was done as to prevent exposing the resolve assert message funcs in the stdlib directly.

Before an assertion with a dynamic assert message we perform a foreign call out to the user with the format-string and the values to be formatted. The user must then return what the assert message should look like. This is then cached on by nargo when executing the ACVM and should the next opcode fail to execute then this error message will be returned to the user.

We now require end-users (people running ACVM) to format their own assert messages.

Example output for assert_msg_runtime test:

Assert message still work in the stdlib as expected:

Output for debug logs when putting assert(x == y, struct_string); on line 48 immediately following std::println(struct_string);:

Additional Context

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [Exceptional Case] 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 circuit sizes

Generated at commit: 34f621fde878665ad034c3a74b09b8df289dbb90, compared to commit: 3af2a89826f7d9b6dcd1782b8b38417c64065293

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
assert_statement	+6 ❌	+600.00%	+3 ❌	+42.86%
u128	+52 ❌	+5.84%	+31 ❌	+0.66%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
assert_statement	7 (+6)	+600.00%	10 (+3)	+42.86%
u128	943 (+52)	+5.84%	4,758 (+31)	+0.66%

[TomAFrench]

Using foreign calls to resolve error messages like this makes me a bit sad. The flow for Javascript would then be

1. ACVM hits a failing assertion
2. ACVM boots out a foreign call with the assert message format string.
3. Javascript formats this string and passes it back to the ACVM. (Requires a JS formatting implementation)
4. ACVM then fails, returning the string which Javascript just handed it.

I'd need to think on whether we can do this formatting in the ACVM cleanly (i.e. without having another abstraction leak from Noir into ACVM).

[vezenovm]

Is this the case when assert messages are not lazy evaluated?

1. Process an assert message foreign call and save the formatted string.
2. If we hit an assert that fails we use the previously saved message. If we passed the assertion, we clear the assert message.
3. Continue normal execution

So instead we resolve the assert message, then we hit a failing assertion. I previously had the resolved assert message be its own NargoError, but then this can potentially lead to mismatched errors when we process an assert message that has not failed. I can switch to this if you think it makes more sense.

[jfecher]

Could we possibly simplify this by doing the formatting in Noir? For example, can we carry forward the format string in expect until it reaches assert, then from there expand the string to "print" each part as needed?

E.g.

fn foo(x: i32) {
    println(f"x is {x}, which should be 3") 
}

// Compiled into
fn foo(x: i32) {
    print("x is");
    print(x);
    println(", which should be 3") 
}

Since each format string is given a unique type based on the structure of the arguments it captures, this would probably be possible after monomorphization. Then perhaps we could have some primitives of extending this to assert somehow? My thinking is just that ideally formatted strings aren't something that is built into the backend of a language - I think we'd be saving ourselves complexity by trying to compile them out beforehand somehow. I could be missing something though.

[vezenovm]

Going to answer in the main conversation as well for visibility. Your suggestion is an interesting way to possibly simplify formatted strings, but I do lean towards that it can be done in a followup PR. I would have to think through about how much it simplifies things vs. other options when we start to extend this to assert and any other gotchas.

To highlight some of the unknowns, we currently attach the type metadata during monomorphization, so we would have to do this println or resolve_assert_message expansion before that pass or the attaching of type metadata would have to be changed. In general it seems that string formatting can be re-thought, but it is best left as its own proposal.

[TomAFrench]

One issue with splitting this up into multiple print calls is that we're then performing many foreign calls for a single println which is not ideal.

[vezenovm]

Good point. Lets move discussion to this issue (#4238)

[vezenovm]

In order to reset the current assertion message I went with inserting a resolve_assert_message call before every constrain and in the case one isn't specified we simply have an empty string. However, I could change this to be a separate boolean flag or something but I didn't think it was very important people got to print empty strings.

[Savio-Sou]

cc @noir-lang/developerrelations re doc changes contained