fix: Don't reuse brillig with slice arguments (AztecProtocol/aztec-pa…

…ckages#5800) This is a quick fix after AztecProtocol/aztec-packages#5737 since that PR assumes that one generated brillig is valid for all calls to the brillig function. This is however not true, since the generated brillig can differ if the arguments contains slices. This is because the entry point codegen depends on the size of the slice. We currently cannot copy slices of any length into brillig due to the limitations of [CALLDATACOPY](https://yp-aztec.netlify.app/docs/public-vm/instruction-set#calldatacopy) where the size being copied needs to be known at compile-time. I'm going to chat with the AVM team to see if we can lift this restriction and make brillig entry points be able to copy in arguments that contain slices of any length.
noir-lang · Apr 17, 2024 · 2aae5ce · 2aae5ce
1 parent 5b352d6
commit 2aae5ce
Show file tree

Hide file tree

Showing 139 changed files with 1,788 additions and 2,876 deletions.
diff --git a/.aztec-sync-commit b/.aztec-sync-commit
@@ -1 +1 @@
-1dfbe7bc3bf3c455d8fb6c8b5fe6a96c1edf7af9
+be9f24c16484b26a1eb88bcf35b785553160995d
diff --git a/Cargo.lock b/Cargo.lock
diff --git a/acvm-repo/acir/Cargo.toml b/acvm-repo/acir/Cargo.toml
@@ -20,6 +20,7 @@ thiserror.workspace = true
 flate2.workspace = true
 bincode.workspace = true
 base64.workspace = true
+serde-big-array = "0.5.1"
 
 [dev-dependencies]
 serde_json = "1.0"