-
Notifications
You must be signed in to change notification settings - Fork 283
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: use mutable refs in noir-contracts #1099
Conversation
82999ea
to
f6c114a
Compare
f6c114a
to
55e2ebe
Compare
Blocked by noir-lang/noir#1961, so converting this PR back to 'draft'. |
843bd9a
to
c8de12d
Compare
Soon to be unblocked by noir-lang/noir#2087 |
7af2051
to
ec762d0
Compare
Only compiles with Jake's PR's branch. Need to wait until that's merged before merging this. Edit: it's merged! |
06ac22e
to
5a2c2c3
Compare
Not sure why these tests are failing. They're working locally... |
dad2a3f
to
cfb690b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for tackling this, it was a major change! I really like the result, and agree with moving the call_function
methods into context.
One thing I hadn't noticed before is how some methods silently add the header to a note, which is now made explicit since they require a mutable reference to it. Does it make sense to use different types to represent notes with and without headers, to make it more clear which methods expect the header to be set, and which ones set it? Not for this PR of course.
@@ -36,9 +36,9 @@ contract EasyZkToken { | |||
let storage = Storage::init(); | |||
let balances = storage.balances; | |||
|
|||
context = balances.at(owner).add(context, initial_supply, owner); | |||
balances.at(owner).add(&mut context, initial_supply, owner); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yay, new syntax! Just to check: the compiler will complain if we don't include this &mut
keyword, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct! It results in something slightly more verbose and cumbersome than I'd have liked, because many end users won't be familiar with references, but now they have to be. But I guess Noir emulates Rust syntax, so this is unavoidable.
I think it's to prevent foot guns. The developer has to consciously say "I am aware that the context I am passing to this function could get mutated"
@@ -32,16 +29,16 @@ contract ZkToken { | |||
inputs: PrivateContextInputs, | |||
//*********************************/ | |||
initial_supply: Field, | |||
owner: Field, | |||
owner: Field |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious if you removed this manually or you have a noir formatter set up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This must have been a manual change.
let note = get_note_internal(storage_slot, note_interface); | ||
let mut unique_note_hash = 0; | ||
let is_dummy = note_interface.is_dummy; | ||
if is_dummy(note) == false { | ||
check_note_header(context, storage_slot, note_interface, note); | ||
check_note_header(*context, storage_slot, note_interface, note); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hold on, why *
? Do we need to manually dereference the mutable reference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, since check_note_header
doesn't mutate the context, we want to pass in a Context
type rather than an &mut Context
type
I like overall how we decided to expose a pretty low level interface and now we're cleaning it up as we go (versus making everything magic from the start, I suppose) LGTM at a glance, really like the change |
I'll tag @LeilaWang on this comment, because Leila did a lot of the lovely work introducing headers. |
Description
Refactoring:
call
fromPrivateCallStackItem
andPublicCallStackItem
to context.Checklist: