chore: Bump Noir reference

[AztecBot]

Automated pull of nightly from the noir programming language, a dependency of Aztec.
BEGIN_COMMIT_OVERRIDE
chore(docs): Brillig VM docs (noir-lang/noir#9078)
fix(expand): missing struct member visibility, and use "crate" instead of "super" when possible (noir-lang/noir#9081)
fix: revert #9044 (noir-lang/noir#9080)
chore: error on infinite recursion (noir-lang/noir#9063)
fix(fuzz): Assign to an index variable to sequence side effects (noir-lang/noir#9056)
chore: bump cargo deny (noir-lang/noir#9077)
chore: Refactor ConstrainEqFailed to have Option<String> for msg (noir-lang/noir#9065)
chore(debug): Toggle SSA locations when printing SSA (noir-lang/noir#9066)
chore(acir_gen): Improve error message for radix decomposition (noir-lang/noir#9068)
chore(ci): fix upload of benchmark results on master (noir-lang/noir#9069)
fix: check both coordinates for point doubling (noir-lang/noir#9039)
fix: codegen generic type arguments (noir-lang/noir#9044)
chore: remove accidentally committed files (noir-lang/noir#9048)
fix(fuzz): enable print in comptime_vs_brillig_direct (noir-lang/noir#9045)
chore: move a couple of test_utils functions into a module (noir-lang/noir#9052)
chore: bump external pinned commits (noir-lang/noir#9046)
fix: put constraint failure after binary operations that overflow (noir-lang/noir#9023)
fix(ssa): Remove array from cache in constant folding if it's an argument to a Call (noir-lang/noir#9040)
feat: some nargo expand fixes related to function and method calls (noir-lang/noir#9038)
feat(ssa_fuzzer): custom mutations (noir-lang/noir#8988)
feat: implicit coercion of str and fmtstr into CtString (noir-lang/noir#9032)
chore: add idempotency check to remove_unreachable_functions (noir-lang/noir#9017)
chore: add logging for signature failure cases which break barretenberg (noir-lang/noir#9030)
feat(ssa): Handle println in the SSA interpreter (noir-lang/noir#9028)
chore: don't compute used globals during DIE (noir-lang/noir#9029)
fix(ssa_fuzzer): nested conditions in loops (noir-lang/noir#8997)
fix(fuzz): Consider == turning into != equivalent (noir-lang/noir#9025)
fix(fuzz): Avoid overflow in gen_unary (noir-lang/noir#9024)
fix(ssa): Perform mem2reg before DIE (noir-lang/noir#9018)
fix: Strange use of predicates in euclidian division (noir-lang/noir#8934)
fix: compute the dominance frontier of the reverse cfg using the extended cfg (noir-lang/noir#9019)
fix(fuzz): Handle overflow errors from the elaborator (noir-lang/noir#9014)
feat: show why an assertion will always fail if it's a static string (noir-lang/noir#9013)
chore(ssa): Add SsaPass:and_then (noir-lang/noir#9016)
fix: Add a remove_unreachable_instructions SSA pass (with unreachable terminator) (noir-lang/noir#9008)
feat: nargo expand for LSP (noir-lang/noir#9012)
fix(mem2reg): Add the value in ArraySet to aliased_references (noir-lang/noir#8976)
feat(debug): Print ssa locations along with ssa (noir-lang/noir#9001)
chore: move nargo expand code to its own crate (noir-lang/noir#9011)
chore: redo typo PR by donatik27 (noir-lang/noir#9004)
fix: recover generics when defining trait impl function (noir-lang/noir#9009)
fix: replace public key with curve generators in inactive branches (noir-lang/noir#8993)
fix(fuzz): Avoid overflowing binary ops in "no dynamic" mode (noir-lang/noir#8996)
END_COMMIT_OVERRIDE

[asterite]

I still don't know what's going on. We get an error like this:

Same struct with different number of args encountered: types::abis::log::Log (4), types::abis::log::Log (4), types::abis::log::Log (6)...

but it's a bit strange because I don't see Log being used inside another type with those values. Then, numeric generics don't result in different fields in the generator.

But I guess the tricky part is that I can't seem to reproduce this locally. Or, well, I tried with some code that's similar to the types that use Log here. In the mainframe I'm not sure how to get a noir with patched changes (./boostrap.sh inside noir fails for me). I also can't find any #[export] functions in this codebase. I think they are maybe generated via macros? Or do the abi annotations also produce export types?

[TomAFrench]

But I guess the tricky part is that I can't seem to reproduce this locally. Or, well, I tried with some code that's similar to the types that use Log here. In the mainframe I'm not sure how to get a noir with patched changes (./boostrap.sh inside noir fails for me)

How does this fail? You should be able to just write code changes into noir/noir-repo and bootstrap will pick them up. There shouldn't be a need to commit them to the patch file afaik.

I also can't find any #[export] functions in this codebase. I think they are maybe generated via macros? Or do the abi annotations also produce export types?

#[export] is just a method to compile extra functions into build artifacts. noir_codegen can be run on any build artifact so it can be run on the protocol circuits directly. https://github.com/AztecProtocol/aztec-packages/blob/next/yarn-project/ivc-integration/src/scripts/generate_ts_from_abi.ts

[TomAFrench]

Is this just a case of noir_codegen not handling numeric generics? It was created prior to their addition so I can imagine it struggling with them.

From it's perspective, we've got a single struct which is showing up as having multiple sizes which the demonomorphizer is not set up to handle and this also explains the error message.

[asterite]

Thanks! Right, I think it has to do with numeric generics. However, I couldn't reproduce the issue locally.

I'm trying it with a code like this:

pub struct Log<let N: u32> {
    pub fields: [u32; N],
    pub length: u32,
}

pub struct Four {
    pub log: Log<4>,
}

pub struct Six {
    pub log: Log<6>,
}

#[export]
fn exported_function_numeric_generics(a: Four, b: Six) -> u32 {
    a.log.fields[0] + a.log.length + b.log.fields[0] + b.log.fields[1] + b.log.length
}

and the generated code ends up being:

export type Log = {
  fields: u32[];
  length: u32;
}

export type Four = {
  log: Log;
}

export type Six = {
  log: Log;
}

and that works fine.

I added some debug logs to the CI output, I'll try to see if I can find how to reproduce it locally.

[TomAFrench]

Maybe try

pub struct Log<let N: u32> {
    pub fields: [u32; N],
    pub length: u32,
}

#[export]
fn exported_function_numeric_generics(a: Log<4>, b: Log<6>) -> u32 {
    a.log.fields[0] + a.log.length + b.log.fields[0] + b.log.fields[1] + b.log.length
}

[asterite]

Right, that's what I tried first and it didn't break. The Log type is always nested inside other types... deeply nested. I'm trying with just one nest level and it still works fine.

At least now exporting some protocol circuit types locally and running codegen I was able to reproduce the issue... now I need to reduce it or at least understand why it's failing :-)

[asterite]

Finally, I found a small code that reproduces the issue:

pub struct Input1 {
    input2: Input2,
    key: Generic<1>,
}

pub struct Input2 {
    vk_data: Generic<2>,
}

pub struct Generic<let N: u32> {
    pub key: [Field; N],
}

#[export]
fn foo(_: Input1, _: Input2) {}

I still don't know why it fails, though.

[asterite]

Also happens without numeric generics:

pub struct Input1 {
    input2: Input2,
    key: Generic<u32>,
}

pub struct Input2 {
    vk_data: Generic<Field>,
}

pub struct Generic<T> {
    key: T,
}

#[export]
fn export_function_with_numeric_generics(_x: Input1, _y: Input2) -> u32 {
    0
}

I guess it started happening because now we generate types for struct fields, something we previously didn't... which makes me wonder if the exported code was actually usable, if all the nested types weren't generated 🤔

[asterite]

It seems nested types were generated, it's just types inside generics that weren't generated. So probably my fix wasn't good. But the ABI has no notion of generics so I'm not sure how it can be done.

So maybe we can revert my PR and try to find another way to fix the issue?

[asterite]

Yeah, my PR is not good. If we have fn foo(x: Parent<Child>) then Child is correctly generated. But if we have fn foo(x: Parent<Child>, y: Parent<u32>) then Child is not generated. It seems when the generic type is used with another argument then the previous generic argument isn't generated. So for now I'm going to send a PR to revert the wrong PR.

[TomAFrench]

Yeah, a revert seems like the best solution here. We can pull some new testcases across and fix in the main repo.

[asterite]

It's better now, but now we get duplicate structs generated...

[asterite]

I removed it from the merge queue because it's pointing to a very specific commit. I guess we'd want to wait for tomorrow's nightly.

[TomAFrench]

Adding this back in now. Also it's fine to point at a particular commit rather than a nightly release, it doesn't make any difference to aztec-packages.