feat: C++ codegen for msgpack by aakoshh · Pull Request #7716 · noir-lang/noir

aakoshh · 2025-03-14T16:42:45Z

Description

Problem*

Builds on #7690

Summary*

Changes the C++ code generation to inject custom code that should work with the msgpack machinery in Barretenberg.

For now serialisation format is governed by the NOIR_SERIALIZATION_FORMAT env var, as there is no configuration available where the decision is made:

if unset, it's bincode as it was before
if bincode, it is bincode but with a format byte in the front
if msgpack, it is msgpack with a format byte in the front

Deserialisation looks at the first byte to see if it's one of the named formats, and if not, or it fails to deserialise, treats the data as bincode.

Additional Context

To run code generation we can run the following command, now with an env var instead of commenting out the assertion that would reject changes:

NOIR_CODEGEN_OVERWRITE=1 cargo test -p acir cpp_codegen

The code has been tested in
AztecProtocol/aztec-packages#12841

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.

Adds `msgpack` serialisation to the generated Acir and Witness C++ code. I moved the alterations described in `dsl/README.md` into the code generation itself, so no manual work is required. The PR is running against a feature branch with the same name in Noir, here's the upstream PR: noir-lang/noir#7716 With this PR is merged, `bb` should be able to handle `msgpack` or `bincode`. Once that's released we can switch to using `msgpack` in Noir in both native and wasm by merging noir-lang/noir#7810. And then we can remove the `msgpack` format detection and the fallback to `bincode`. **TODO**: - [x] Get it to compile - [x] Change `nargo` to allow compiling contracts with `msgpack` format: added `NOIR_SERIALIZATION_FORMAT` env var - [x] Add a first byte to the data to say which serialization format it is. There is a chance that it would clash with existing bincode data though, so a fallback would anyway be necessary. (Or we should ascertain that bincode never starts with some specific bit sequence). - [x] ~Change the `bb` code so it tries `bincode`, then falls back to `msgpack` - this way the currently used format stays fast, but we can feed it new data.~ _This looks problematic, as exceptions in the wasm build is disabled in `arch.cmake` and `throw_or_abort` aborts in wasm. Instead we run [msgpack::parse](https://c.msgpack.org/cpp/namespacemsgpack.html#ad844d148ad1ff6c9193b02529fe32968) first to check if the data looks like msgpack; if not, we use bincode._ - [x] Run integration tests with `msgpack` on both sides in #13021 - [x] Ignore the Brillig opcodes in Barretenberg - [x] Change the serialization of `WitnessStack` and `WitnessMap` to use the env var, add fallbacks in `bb` for them - [x] Revert the change to `noir-repo-ref` before merging ### Use of `MSGPACK_FIELDS` The generated code is using `MSGPACK_FIELDS` for structs, to keep it more terse. At some point during debugging the memory issue below I changed it so that I can have more direct control by generating code for individual fields. That needed some helper functions which I looted from the `msgpack-c` library and injected into the namespaces as a `Helpers` struct. This approach might be useful if we wanted to have extra checks, for example rejecting the data if there are extra fields, indicating a type has been extended with things we don't recognise, or if we wanted handle renamed fields. I left it out so there is less code to maintain, but if we need it we can recover it from the [commit history](noir-lang/noir@b0a612d). ### Compile `nargo` with the `msgpack` feature ```bash echo af/msgpack-codegen > noir/noir-repo-ref noir/bootstrap.sh ``` ### Generate and compile C++ code ```bash cd noir/noir-repo && NOIR_CODEGEN_OVERWRITE=1 cargo test -p acir cpp_codegen && cd - cp noir/noir-repo/acvm-repo/acir/codegen/acir.cpp barretenberg/cpp/src/barretenberg/dsl/acir_format/serde/acir.hpp cp noir/noir-repo/acvm-repo/acir/codegen/witness.cpp barretenberg/cpp/src/barretenberg/dsl/acir_format/serde/witness_stack.hpp cd barretenberg/cpp && ./format.sh changed && cd - barretenberg/cpp/bootstrap.sh ``` ### Test `nargo` with `bb` One example of an integration test that uses `bb` and noir in the Noir repo is https://github.com/noir-lang/noir/actions/runs/13631231158/job/38099477964 We can call it like this: ```bash cd noir/noir-repo && cargo install --path tooling/nargo_cli && cd - ./barretenberg/cpp/bootstrap.sh export BACKEND=$(pwd)/barretenberg/cpp/build/bin/bb export NOIR_SERIALIZATION_FORMAT=msgpack noir/noir-repo/examples/prove_and_verify/test.sh ``` If it works, it should print this: ```console % unset NOIR_SERIALIZATION_FORMAT % noir/noir-repo/examples/prove_and_verify/test.sh [hello_world] Circuit witness successfully solved [hello_world] Witness saved to /mnt/user-data/akosh/aztec-packages/noir/noir-repo/examples/prove_and_verify/target/witness.gz Finalized circuit size: 18 Proof saved to "./proofs/proof" Finalized circuit size: 18 VK saved to "./target/vk" Proof verified successfully ``` Whereas if it doesn't: ```console % export NOIR_SERIALIZATION_FORMAT=msgpack % noir/noir-repo/examples/prove_and_verify/test.sh [hello_world] Circuit witness successfully solved [hello_world] Witness saved to /mnt/user-data/akosh/aztec-packages/noir/noir-repo/examples/prove_and_verify/target/witness.gz Length is too large ``` I attached the final artefacts to the PR so it's easier to test with just `bb`. [hello_world.json](https://github.com/user-attachments/files/19391072/hello_world.json) [witness.gz](https://github.com/user-attachments/files/19391074/witness.gz) ### Further testing With the `noir-repo-ref` pointing at the feature `af/msgpack-codegen` feature branch, we can run all the contract compilations and tests with `msgpack` as follows: ```shell export NOIR_SERIALIZATION_FORMAT=msgpack ./bootstrap.sh ci ``` This is tested in #13021 ### Peek into artefacts We can inspect the file in JSON format using [this](https://crates.io/crates/msgpack-cli) msgpack CLI tool. ```shell jq -r '.bytecode' ./target/program.json | base64 --decode | gunzip | tail -c +2 | mpk --to-json | jq ``` Thanks Tom for the [spell](AztecProtocol/msgpack-c#5 (comment)) 🙏 ### False bug At some point I thought had to make some fixes in `msgpack-c` itself to make this work: AztecProtocol/msgpack-c#5 A similar [blocking bug](#12841 (comment)) was encountered when running the entire `ci` build with msgpack format. It turned out it was a [dangling pointer](msgpack/msgpack-c#695 (comment)) issue, fixed in 5810e3b Much of the comments below are related to my struggles that came from this mistake; you can ignore them.

Adds `msgpack` serialisation to the generated Acir and Witness C++ code. I moved the alterations described in `dsl/README.md` into the code generation itself, so no manual work is required. The PR is running against a feature branch with the same name in Noir, here's the upstream PR: noir-lang/noir#7716 With this PR is merged, `bb` should be able to handle `msgpack` or `bincode`. Once that's released we can switch to using `msgpack` in Noir in both native and wasm by merging noir-lang/noir#7810. And then we can remove the `msgpack` format detection and the fallback to `bincode`. **TODO**: - [x] Get it to compile - [x] Change `nargo` to allow compiling contracts with `msgpack` format: added `NOIR_SERIALIZATION_FORMAT` env var - [x] Add a first byte to the data to say which serialization format it is. There is a chance that it would clash with existing bincode data though, so a fallback would anyway be necessary. (Or we should ascertain that bincode never starts with some specific bit sequence). - [x] ~Change the `bb` code so it tries `bincode`, then falls back to `msgpack` - this way the currently used format stays fast, but we can feed it new data.~ _This looks problematic, as exceptions in the wasm build is disabled in `arch.cmake` and `throw_or_abort` aborts in wasm. Instead we run [msgpack::parse](https://c.msgpack.org/cpp/namespacemsgpack.html#ad844d148ad1ff6c9193b02529fe32968) first to check if the data looks like msgpack; if not, we use bincode._ - [x] Run integration tests with `msgpack` on both sides in AztecProtocol/aztec-packages#13021 - [x] Ignore the Brillig opcodes in Barretenberg - [x] Change the serialization of `WitnessStack` and `WitnessMap` to use the env var, add fallbacks in `bb` for them - [x] Revert the change to `noir-repo-ref` before merging ### Use of `MSGPACK_FIELDS` The generated code is using `MSGPACK_FIELDS` for structs, to keep it more terse. At some point during debugging the memory issue below I changed it so that I can have more direct control by generating code for individual fields. That needed some helper functions which I looted from the `msgpack-c` library and injected into the namespaces as a `Helpers` struct. This approach might be useful if we wanted to have extra checks, for example rejecting the data if there are extra fields, indicating a type has been extended with things we don't recognise, or if we wanted handle renamed fields. I left it out so there is less code to maintain, but if we need it we can recover it from the [commit history](noir-lang/noir@b0a612d). ### Compile `nargo` with the `msgpack` feature ```bash echo af/msgpack-codegen > noir/noir-repo-ref noir/bootstrap.sh ``` ### Generate and compile C++ code ```bash cd noir/noir-repo && NOIR_CODEGEN_OVERWRITE=1 cargo test -p acir cpp_codegen && cd - cp noir/noir-repo/acvm-repo/acir/codegen/acir.cpp barretenberg/cpp/src/barretenberg/dsl/acir_format/serde/acir.hpp cp noir/noir-repo/acvm-repo/acir/codegen/witness.cpp barretenberg/cpp/src/barretenberg/dsl/acir_format/serde/witness_stack.hpp cd barretenberg/cpp && ./format.sh changed && cd - barretenberg/cpp/bootstrap.sh ``` ### Test `nargo` with `bb` One example of an integration test that uses `bb` and noir in the Noir repo is https://github.com/noir-lang/noir/actions/runs/13631231158/job/38099477964 We can call it like this: ```bash cd noir/noir-repo && cargo install --path tooling/nargo_cli && cd - ./barretenberg/cpp/bootstrap.sh export BACKEND=$(pwd)/barretenberg/cpp/build/bin/bb export NOIR_SERIALIZATION_FORMAT=msgpack noir/noir-repo/examples/prove_and_verify/test.sh ``` If it works, it should print this: ```console % unset NOIR_SERIALIZATION_FORMAT % noir/noir-repo/examples/prove_and_verify/test.sh [hello_world] Circuit witness successfully solved [hello_world] Witness saved to /mnt/user-data/akosh/aztec-packages/noir/noir-repo/examples/prove_and_verify/target/witness.gz Finalized circuit size: 18 Proof saved to "./proofs/proof" Finalized circuit size: 18 VK saved to "./target/vk" Proof verified successfully ``` Whereas if it doesn't: ```console % export NOIR_SERIALIZATION_FORMAT=msgpack % noir/noir-repo/examples/prove_and_verify/test.sh [hello_world] Circuit witness successfully solved [hello_world] Witness saved to /mnt/user-data/akosh/aztec-packages/noir/noir-repo/examples/prove_and_verify/target/witness.gz Length is too large ``` I attached the final artefacts to the PR so it's easier to test with just `bb`. [hello_world.json](https://github.com/user-attachments/files/19391072/hello_world.json) [witness.gz](https://github.com/user-attachments/files/19391074/witness.gz) ### Further testing With the `noir-repo-ref` pointing at the feature `af/msgpack-codegen` feature branch, we can run all the contract compilations and tests with `msgpack` as follows: ```shell export NOIR_SERIALIZATION_FORMAT=msgpack ./bootstrap.sh ci ``` This is tested in AztecProtocol/aztec-packages#13021 ### Peek into artefacts We can inspect the file in JSON format using [this](https://crates.io/crates/msgpack-cli) msgpack CLI tool. ```shell jq -r '.bytecode' ./target/program.json | base64 --decode | gunzip | tail -c +2 | mpk --to-json | jq ``` Thanks Tom for the [spell](AztecProtocol/msgpack-c#5 (comment)) 🙏 ### False bug At some point I thought had to make some fixes in `msgpack-c` itself to make this work: AztecProtocol/msgpack-c#5 A similar [blocking bug](AztecProtocol/aztec-packages#12841 (comment)) was encountered when running the entire `ci` build with msgpack format. It turned out it was a [dangling pointer](msgpack/msgpack-c#695 (comment)) issue, fixed in AztecProtocol/aztec-packages@5810e3b Much of the comments below are related to my struggles that came from this mistake; you can ignore them.

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: `471822d`	Previous: `7b09db8`	Ratio
`zkemail_noir-jwt_`	`7` s	`4` s	`1.75`
`zkemail_zkemail.nr_lib`	`3` s	`1` s	`3`

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

CC: @TomAFrench

@TomAFrench

Followup for #12841 Changes code generation for msgpack so that it doesn't throw an error if an optional field of a `struct` is not present in the data. This is to allow @TomAFrench and @asterite to delete `Opcode::MemoryOp::predicate` which is an optional field that we no longer use. Removing such a field should be a non-breaking change, as the field was optional to begin with, so while even if it's present in C++ it should already handle it being empty. Unfortunately the `msgpack-c` library as far as I can see [would throw an error](https://github.com/AztecProtocol/msgpack-c/blob/54e9865b84bbdc73cfbf8d1d437dbf769b64e386/include/msgpack/v1/adaptor/detail/cpp11_define_map.hpp#L33-L45) if the optional field would not be present in the data as NIL. For this to work the PR re-introduces the `Helpers` and enumerates fields explicitly, instead of using `MSGPACK_FIELDS`. I changed the unmerged noir-lang/noir#7716 to do codegen with this change. I rebased #13021 on top of this PR to see if it works when msgpack is actually in use. ### Note for future migration path @ludamad reached out that while the bytecode size increase shown in noir-lang/noir#7690 doesn't seem too bad, and compression compensates for the inclusion of string field names, it's still wasteful to have to parse them, and it would be better to use arrays. I established in [tests](https://github.com/noir-lang/noir/pull/7690/files#diff-2d66028e5a8966511a76d1740d752be294c0b6a46e0a567bc2959f91d9ce224bR169-R176) that we what we call `msgpack-compact` format uses arrays for structs, but still tags enums with types. We use a lot of enums, so there is still quite a few strings. Ostensibly we could use [serde attributes](https://serde.rs/container-attrs.html) to shorten names, but it would probably be a nightmare and ugly. Nevertheless if we generated C++ code to deal with arrays, we could save some space. And if we want to stick to `bincode`, we can use `NOIR_SERIALIZATION_FORMAT=bincode`, which I back ported to the Noir codegen PR, to generate `bincode` with a format byte marker. There is also `bincode-legacy`, but unfortunately we only have one shot at deserialising bincode in C++: if it fails, we can't catch the exception. Therefore the path to be able to use the bincode format marker is: 1. Release `bb` which can handle the `msgpack` format (which has a probe, doesn't have to throw) 2. Start producing msgpack data from `nargo` 3. Stop accepting unmarked bincode in `bb` and look for format byte == 1 to show that bincode is in use 4. Tell `nargo` which format to use EDIT: Unfortunately if we use `binpack` with today's data types it forces us to parse the Brillig part, as established by #13143 which would mean the Noir team can't make any changes to Brillig opcodes without breaking `bb`. We would need to change the format again to use two tier encoding, or use msgpack arrays.

@TomAFrench

Followup for AztecProtocol/aztec-packages#12841 Changes code generation for msgpack so that it doesn't throw an error if an optional field of a `struct` is not present in the data. This is to allow @TomAFrench and @asterite to delete `Opcode::MemoryOp::predicate` which is an optional field that we no longer use. Removing such a field should be a non-breaking change, as the field was optional to begin with, so while even if it's present in C++ it should already handle it being empty. Unfortunately the `msgpack-c` library as far as I can see [would throw an error](https://github.com/AztecProtocol/msgpack-c/blob/54e9865b84bbdc73cfbf8d1d437dbf769b64e386/include/msgpack/v1/adaptor/detail/cpp11_define_map.hpp#L33-L45) if the optional field would not be present in the data as NIL. For this to work the PR re-introduces the `Helpers` and enumerates fields explicitly, instead of using `MSGPACK_FIELDS`. I changed the unmerged noir-lang/noir#7716 to do codegen with this change. I rebased AztecProtocol/aztec-packages#13021 on top of this PR to see if it works when msgpack is actually in use. ### Note for future migration path @ludamad reached out that while the bytecode size increase shown in noir-lang/noir#7690 doesn't seem too bad, and compression compensates for the inclusion of string field names, it's still wasteful to have to parse them, and it would be better to use arrays. I established in [tests](https://github.com/noir-lang/noir/pull/7690/files#diff-2d66028e5a8966511a76d1740d752be294c0b6a46e0a567bc2959f91d9ce224bR169-R176) that we what we call `msgpack-compact` format uses arrays for structs, but still tags enums with types. We use a lot of enums, so there is still quite a few strings. Ostensibly we could use [serde attributes](https://serde.rs/container-attrs.html) to shorten names, but it would probably be a nightmare and ugly. Nevertheless if we generated C++ code to deal with arrays, we could save some space. And if we want to stick to `bincode`, we can use `NOIR_SERIALIZATION_FORMAT=bincode`, which I back ported to the Noir codegen PR, to generate `bincode` with a format byte marker. There is also `bincode-legacy`, but unfortunately we only have one shot at deserialising bincode in C++: if it fails, we can't catch the exception. Therefore the path to be able to use the bincode format marker is: 1. Release `bb` which can handle the `msgpack` format (which has a probe, doesn't have to throw) 2. Start producing msgpack data from `nargo` 3. Stop accepting unmarked bincode in `bb` and look for format byte == 1 to show that bincode is in use 4. Tell `nargo` which format to use EDIT: Unfortunately if we use `binpack` with today's data types it forces us to parse the Brillig part, as established by AztecProtocol/aztec-packages#13143 which would mean the Noir team can't make any changes to Brillig opcodes without breaking `bb`. We would need to change the format again to use two tier encoding, or use msgpack arrays.

aakoshh · 2025-05-15T16:01:53Z

We could add the following post-processing to match what Brillig does in a patch:

  perl -pi -e '
    s{std::array<\s*([^,<>]+?)\s*,\s*([0-9]+)\s*>}{std::shared_ptr<std::array<$1, $2>>}gx' acir.hpp

EDIT: Done in 3e44754

…f/msgpack-codegen

github-actions

⚠️ Performance Alert ⚠️

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

Benchmark suite	Current: `4c9116b`	Previous: `e2a52b7`	Ratio
`rollup-block-root-single-tx`	`173` s	`128` s	`1.35`

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

CC: @TomAFrench

acvm-repo/acir/src/lib.rs

Automated pull of nightly from the [noir](https://github.com/noir-lang/noir) programming language, a dependency of Aztec. BEGIN_COMMIT_OVERRIDE fix(licm): Account for nested loops being control dependent when analyzing outer loops (noir-lang/noir#8593) chore(refactor): Switch unreachable function removal to use centralized call graph (noir-lang/noir#8578) chore(test): Allow lambdas in fuzzing (noir-lang/noir#8584) chore: use insta for execution_success stdout (noir-lang/noir#8576) chore: use generator instead of zero for ec-add predicate (noir-lang/noir#8552) fix: use predicate expression as binary result (noir-lang/noir#8583) fix(ssa): Do not generate apply functions when no lambda variants exist (noir-lang/noir#8573) chore: put `nargo expand` snapshosts in the same directory (noir-lang/noir#8577) chore: Use FxHashMap for TypeBindings (noir-lang/noir#8574) chore(experimental): use larger stack size for parsing (noir-lang/noir#8347) chore: use insta snapshots for compile_failure stderr (noir-lang/noir#8569) chore(inlining): Mark functions with <= 10 instructions and no control flow as inline always (noir-lang/noir#8533) chore(ssa): Add weighted edges to call graph, move callers and callees methods to call graph (noir-lang/noir#8513) fix(frontend): Override to allow empty array input (noir-lang/noir#8568) fix: avoid logging all unused params in DIE pass (noir-lang/noir#8566) chore: bump external pinned commits (noir-lang/noir#8562) chore(deps): bump base-x from 3.0.9 to 3.0.11 (noir-lang/noir#8555) chore(fuzz): Call function pointers (noir-lang/noir#8531) feat: C++ codegen for msgpack (noir-lang/noir#7716) feat(performance): brillig array set optimization (noir-lang/noir#8550) chore(fuzz): AST fuzzer to use function valued arguments (Part 1) (noir-lang/noir#8514) fix(licm): Check whether the loop is executed when hoisting with a predicate (noir-lang/noir#8546) feat: Implement $crate (noir-lang/noir#8537) fix: add offset to ArrayGet (noir-lang/noir#8536) chore: remove some unused enum variants and functions (noir-lang/noir#8538) fix: disallow `()` in entry points (noir-lang/noir#8529) chore: Remove println in ssa interpreter (noir-lang/noir#8528) fix: don't overflow when casting signed value to u128 (noir-lang/noir#8526) chore(performance): Enable hoisting pure with predicate calls (noir-lang/noir#8522) feat(fuzz): AST fuzzing with SSA interpreter (noir-lang/noir#8436) chore: Add u1 ops to interpreter, convert Value panics to errors (noir-lang/noir#8469) chore: Release Noir(1.0.0-beta.6) (noir-lang/noir#8438) chore(fuzz): AST generator to add `ctx_limit` to all functions (noir-lang/noir#8507) fix(inlining): Use centralized CallGraph structure for inline info computation (noir-lang/noir#8489) fix: remove private builtins from `Field` impl (noir-lang/noir#8496) feat: primitive types are no longer keywords (noir-lang/noir#8470) fix: parenthesized pattern, and correct 1-element tuple printing (noir-lang/noir#8482) fix: fix visibility of methods in `std::meta` (noir-lang/noir#8497) fix: Change `can_be_main` to be recursive (noir-lang/noir#8501) chore: add SSA interpreter test for higher order functions (noir-lang/noir#8486) fix(frontend)!: Ban zero sized arrays and strings as program input (noir-lang/noir#8491) fix!: remove `to_be_radix` and `to_le_radix` from stdlib interface (noir-lang/noir#8495) END_COMMIT_OVERRIDE --------- Co-authored-by: AztecBot <tech@aztecprotocol.com> Co-authored-by: Tom French <15848336+TomAFrench@users.noreply.github.com>

aakoshh mentioned this pull request Mar 18, 2025

feat: msgpack encoding for Program and WitnessStack AztecProtocol/aztec-packages#12841

Merged

8 tasks

aakoshh changed the title ~~feat(DRAFT): C++ codegen for msgpack~~ feat: C++ codegen for msgpack Mar 21, 2025

aakoshh marked this pull request as ready for review March 21, 2025 12:54

aakoshh requested a review from a team March 21, 2025 12:56

aakoshh mentioned this pull request Mar 25, 2025

chore!: Use msgpack-compact format by default #7810

Merged

5 tasks

github-actions bot reviewed Mar 28, 2025

View reviewed changes

aakoshh mentioned this pull request Mar 28, 2025

feat(noir): Allow missing optional fields in msgpack AztecProtocol/aztec-packages#13141

Merged

aakoshh mentioned this pull request Apr 2, 2025

msgpack-compact C++ codegen #7886

Open

Base automatically changed from af/msgpack to master April 9, 2025 09:20

aakoshh and others added 17 commits April 9, 2025 10:28

Tests to verify what msgpack does

8dcb587

Generate code to serialize with msgpack

305e04b

Unpack newtypes

9f6810e

Unpack enum

87a3842

include msgpack.hpp

1d71bbd

Throw if variant is unknown

efbc91e

Add NOIR_CODEGEN_OVERWRITE

baff280

Fix clippy

cea2c8a

Generate empty pack and unpack for enum variants

eaf30e5

Include the enum name in error messages

9199ae8

Factor out common codegen

cdfd50c

Replace throw with throw_or_abort

6440535

Fix clippy

772e3fe

Fix some C++ compilation issues

941c50a

Fix the msgpack::object stuff to compile

a5c19a8

Try to just use packer.pack and object.convert

2362625

Change the namespace names to avoid ambiguity

a55706b

TomAFrench and others added 2 commits May 13, 2025 14:30

Merge branch 'master' into af/msgpack-codegen

f63b7bb

Merge branch 'master' into af/msgpack-codegen

4f8ee67

aakoshh and others added 6 commits May 15, 2025 17:03

Update Cargo.lock

a4d013a

Add Adam's shared_ptr hack

3e44754

Merge branch 'master' into af/msgpack-codegen

4c9116b

update cargo.lock

2d7e01a

Merge branch 'af/msgpack-codegen' of github.com:noir-lang/noir into a…

33cfbc8

…f/msgpack-codegen

update acir.cpp

91271d1

github-actions bot reviewed May 15, 2025

View reviewed changes

guipublic requested a review from TomAFrench May 15, 2025 17:32

aakoshh commented May 16, 2025

View reviewed changes

acvm-repo/acir/src/lib.rs Outdated Show resolved Hide resolved

aakoshh and others added 2 commits May 16, 2025 09:41

Update acvm-repo/acir/src/lib.rs

7f79f12

Merge branch 'master' into af/msgpack-codegen

7e88d2d

TomAFrench approved these changes May 16, 2025

View reviewed changes

TomAFrench enabled auto-merge May 16, 2025 14:59

TomAFrench added this pull request to the merge queue May 16, 2025

Merged via the queue into master with commit 0298a63 May 16, 2025
119 checks passed

TomAFrench deleted the af/msgpack-codegen branch May 16, 2025 15:56

noirwhal mentioned this pull request May 16, 2025

chore: Release Noir(1.0.0-beta.7) #8520

Merged

AztecBot mentioned this pull request May 22, 2025

chore(next): release 1.0.0 AztecProtocol/aztec-packages#14467

Closed

AztecBot mentioned this pull request May 23, 2025

chore(next): release 0.88.0 AztecProtocol/aztec-packages#14495

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: C++ codegen for msgpack#7716

feat: C++ codegen for msgpack#7716
TomAFrench merged 63 commits intomasterfrom
af/msgpack-codegen

aakoshh commented Mar 14, 2025 •

edited

Loading

Uh oh!

github-actions bot left a comment •

edited

Loading

Uh oh!

aakoshh commented May 15, 2025 •

edited

Loading

Uh oh!

github-actions bot left a comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

aakoshh commented Mar 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Problem*

Summary*

Additional Context

Documentation*

PR Checklist*

Uh oh!

github-actions bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

⚠️ Performance Alert ⚠️

Uh oh!

aakoshh commented May 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot left a comment

Choose a reason for hiding this comment

⚠️ Performance Alert ⚠️

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

aakoshh commented Mar 14, 2025 •

edited

Loading

github-actions bot left a comment •

edited

Loading

aakoshh commented May 15, 2025 •

edited

Loading