[TRACKING ISSUE] aztec_noir: Attributes follow up work

[Maddiaa0]

Overview

Now that the initial work has been merged into our and noir's master branch (behind the aztec feature flag on the frontend). The job is refining and getting this work stable for the long term.

The goal of this issue is to coordinate the tasks planned, for reference, see a related tracking issue in Noir. Note; while the scope of these tracking issue collides. They are distinct; as Noir's deals with longer term solutions.

• [Tracking Issue]: Macro discussions, library transforming and long term goals noir-lang/noir#2419

Relevant Literature

Along with the linked tracking issue above, there are the following resources:

• https://hackmd.io/HFAqamogRda0AR3ZkWtrqQ

Relevant Prs

Aztec

• feat(noir): use #[aztec(private)] and #[aztec(public) attributes #1735
  • Initial work refactoring our test aztec noir contracts to use the new syntax

Noir

• feat(frontend): aztec syntactic sugar (feature flagged) noir-lang/noir#2403
  • This PR adds the initial scaffold for abstracting away the guts of the kernel circuit.

Future Work

Unsupported input params

Currently unable to have bool params.
Linked issue:

• Support bools params in aztec.noir #2175

Return Values

Right now the application user cannot return from the function without calling:

context.return_values.push(<value>); 

This further leaks the internals of the kernel to the developer. We should aspire such that the user should return from functions using n
normal noir semantics.
Linked Issue:

• feat(Aztec.nr): Abstract the kernel circuit internals when dealing with return types  #1885

Removing the Open Keyword

Right now all open functions have a return value keyword at the beginning. This is then included in the abi and included in the contract's function tree. And also determines that brillig should be generated for the function. The use of the open keyword was chosen as public is considered overloaded. Consensus has such changed; the public keyword is now deemed suitable for this.
Linked Issue:

• feat(Aztec.nr): Remove the open keyword, in favour of the public attribute #1886

Removing the internal Keyword

Right now all internal functions have a return value keyword at the beginning. This is then included in the abi and included in the contract's function tree.
Linked Issue:

• feat(Aztec.nr): Remove the internal keyword, in favour of an attribute #1916

Auto import required resources from the aztec library

Currently; compilation will fail if the user has not included imports to the structures required. The following imports are required:

use aztec::abi;
use aztec::abi::{
         Hasher,
         PrivateContextInputs,
         PublicContextInputs
};
use aztec::context::{
     PublicContext,
     PrivateContext
};

Compilation fails without this, and should be hidden
Linked issue:

• feat(Aztec.nr): Auto import all crucial imports from the aztec library required when using the macros #1888

Output Suitable Error message if using aztec noir features without the library installed.

Related to above, the ast information that is injected includes tokens that are only available if aztec noir is available. It is a footgun that installation will fail with syntax issues if the user has not included an import to the relevant files.
Linked Issue:

• feat(Aztec.nr): Output a suitable error message if using aztec.nr features without the library installed #1889

Handling Storage

Despite the existence of our macro syntax. The user still needs to call let storage = Storage::init(). at the beginning of each function call.
Defining storage should be standardised such that when it is defined at the top of the file the developer does not need to worry about it too much.
Linked Issue:

• feat(Aztec.nr): Abstract away storage initialisation from the user #1890

Sub issue
Storage semantics have evolved over time, abstract away their definition from the developer.
#2163

Bugs

• Investigate compilation not failing if a return value is defined but not used bug(AztecMacro): Should fail if a return value is defined but not given #2247

[LHerskind]

This seems to be solve as to what we can do until more macros or accounted for in #5077 so I'm closing this one for now.