From e1b1da4199ae259cb40072d0977ab4d34c3158b0 Mon Sep 17 00:00:00 2001 From: superstar0402 Date: Mon, 19 Feb 2024 08:35:32 -0300 Subject: [PATCH] feat!: autogenerate compute_note_hash_and_nullifier (#4610) Closes #2918. This adds a new macro function that processes the unresolved trait impls and injects a new function before name resolution takes place. This lets us leverage the parser and write the function in Noir instead of having to deal with more complicated processed objects. In order to find all of the note types we look for impls of the `NoteInterface` trait. This is a bit more involved than it seems, since other crates may also have structs that impl this trait, and those will have already been processed. We rely on the fact that the contract crate is processed last, and search for external crate impls via the NodeInterner and internal ones in the unresolved functions. This method is robust as long as we do the contract crate after all of its imports, which holds because the imports are recursively collected from the root crate. I also added a small escape hatch mechanism by skipping any code generation if the function is already defined by the user. This could use some polishing since it is possible for the user to e.g. provide the function but get the arity or parameter types wrong, in which case they'd get a duplicate definition error. Diagnosis and error messages can be improved here (https://github.com/AztecProtocol/aztec-packages/issues/4647), but I think a simple mechanism is sufficient for now. --- ### Minor issues - One of the function arguments is a fixed-size array, which should be as big as the largest note length. We are not yet pulling the note length (https://github.com/AztecProtocol/aztec-packages/issues/4649), so I'm passing a hardcoded value for now. 12 Fields ought to be enough for anyone. - Doing this introduces an implicit dependency on `AztecAddress` on all contracts. This won't be an issue once https://github.com/AztecProtocol/aztec-packages/pull/4496 is in, but I did have to manually add it to some of the account contracts for now. - I created a new macro function that is called on each crate after collection but before resolution. Due to some internal compilers shenanigans (mostly who holds mut references to what) I chose to specialize this function so that for now it only passes the collected unresolved functions, making it a bit niche for the current use case. @vezenovm and I are planning to generalize this down the road (https://github.com/AztecProtocol/aztec-packages/issues/4653). - I'm now importing in the macro from some places that were not previously used, notably the HIR and Noir errors. I am not sure if we might want to pull those differently - I simply imported what I needed. - I also introduced some getters to provide mutable access to private fields of the HIR Context and CrateDefMap. This is because we need to modify the contract module in the def map by declaring the new function (which is how we get things like duplicate definition detection). We're already mutating the HIR Context in the macros, so also mutating its members doesn't feel like a stretch. - Finally, I don't know enough about how Noir errors work to know how to produce a useful `Location` value for the new function, if indeed that can be done. Providing an empty span seems to at least not cause weird errors on the LSP plugin, so that's how I left it for now. --- value-note/src/balance_utils.nr | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/value-note/src/balance_utils.nr b/value-note/src/balance_utils.nr index 570f0cc..6372d71 100644 --- a/value-note/src/balance_utils.nr +++ b/value-note/src/balance_utils.nr @@ -1,6 +1,6 @@ use dep::aztec::note::{note_getter::view_notes, note_viewer_options::NoteViewerOptions}; use dep::aztec::state_vars::set::Set; -use crate::value_note::{VALUE_NOTE_LEN, ValueNote}; +use crate::value_note::ValueNote; unconstrained pub fn get_balance(set: Set) -> Field { get_balance_with_offset(set, 0)