feat!: require trait method calls (foo.bar()) to have the trait in scope (imported)

[asterite]

Description

Based on top of #6882

Problem

Part of #6864

Summary

Similar to 6882 but for method calls (foo.bar()).

Additional Context

Even though this PR wants to be backwards compatible (producing just warnings for existing code) it actually introduces breaking changes if multiple trait methods could be applied but none of them are imported. I don't know why Noir worked "well" in this case, choosing the trait that probably is correct... or maybe it was a coincidence.

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.

[github-actions]

Compilation Report

Program	Compilation Time	%
sha256_regression	1.336s	-1%
regression_4709	0.769s	-1%
ram_blowup_regression	14.900s	-1%
rollup-root	4.210s	0%
rollup-block-merge	3.700s	-3%
rollup-base-public	30.100s	2%
rollup-base-private	12.500s	1%
private-kernel-tail	1.025s	-4%
private-kernel-reset	6.802s	2%
private-kernel-inner	2.292s	2%

[github-actions]

Peak Memory Sample

Program	Peak Memory	%
keccak256	78.51M	0%
workspace	123.53M	0%
regression_4709	422.93M	0%
ram_blowup_regression	1.58G	0%
private-kernel-tail	168.28M	-17%
private-kernel-reset	168.31M	-77%
private-kernel-inner	168.28M	-43%
parity-root	151.60M	-12%

[github-actions]

Compilation Memory Report

Program	Peak Memory
keccak256	78.53M
workspace	123.73M
regression_4709	422.94M
ram_blowup_regression	1.58G
rollup-base-public	2.56G
rollup-base-private	1.25G
private-kernel-tail	202.05M
private-kernel-reset	716.65M
private-kernel-inner	292.32M

[github-actions]

Execution Memory Report

Program	Peak Memory
keccak256	74.62M
workspace	123.73M
regression_4709	315.96M
ram_blowup_regression	512.47M
rollup-base-public	773.33M
rollup-base-private	424.88M
private-kernel-tail	182.09M
private-kernel-reset	255.66M
private-kernel-inner	215.27M

[asterite]

This is ready for review. Some external projects break but I created PRs to fix them:

• chore: let IndexedTreeLeafPreimage have LeafPreimage as a parent trait AztecProtocol/aztec-packages#10913
• feat!: remove redefinition of arithmetic methods on BigNumTrait noir-bignum#84
• chore: explicitly import CurveTrait for sub trait method and remove some default implementations noir-edwards#20

Maybe it would be good to merge those first.

[github-actions]

Execution Report

Program	Execution Time	%
sha256_regression	0.099s	0%
regression_4709	0.001s	0%
ram_blowup_regression	0.573s	-2%
rollup-root	0.105s	0%
rollup-block-merge	0.104s	-2%
rollup-base-public	1.430s	-1%
rollup-base-private	0.641s	-1%
private-kernel-tail	0.022s	-5%
private-kernel-reset	0.385s	-1%
private-kernel-inner	0.117s	-1%

[jfecher]

Looks like all the tests are passing now, are the external repo issues fixed?

[asterite]

Strange! The issue on Aztec-Packages is tracked here: AztecProtocol/aztec-packages#11081 but it's not fixed... so I'm not sure why tests pass now.

[asterite]

I'm seeing errors on the actual output, maybe it's #6930 . I'll try undoing that in this PR to confirm.

[TomAFrench]

@asterite I turned off the reports for noir-contracts in #6973 due to the fact it no longer compiles until we next sync into aztec-packages. I think this is the CI job which was failing for you too.

[asterite]

Oooh... I see, thanks. We could alternatively remove the .github/critical_libraries_status/AztecProtocol/aztec-packages/noir-projects/noir-contracts.failures.jsonl file so the compile failure is expected.

[TomAFrench]

We could alternatively remove the .github/critical_libraries_status/AztecProtocol/aztec-packages/noir-projects/noir-contracts.failures.jsonl file so the compile failure is expected.

I tried that but the failure isn't happening in the external checks workflow (which is what those files control) but in the compilation time, etc. reports workflow.

[asterite]

Is it okay to merge this now then?

[TomAFrench]

Ah sorry, I thought this was already approved based on conversation above

[asterite]

Oh, all good, I didn't know if it was okay to click the merge button, I also didn't notice it was not approved 😄