Merge branch 'master' into zpedro/lsp

docs/getting_started/01_hello_world.md

@@ -110,14 +110,14 @@ x = "1"
 y = "2"
 ```
 
-Prove the valid execution of your Noir program with your preferred proof name, for example `p`:
+Prove the valid execution of your Noir program:
 
 ```sh
-nargo prove p
+nargo prove
 ```
 
 A new folder _proofs_ would then be generated in your project directory, containing the proof file
-`p.proof`.
+`<project-name>.proof`, where the project name is defined in Nargo.toml.
 
 The _Verifier.toml_ file would also be updated with the public values computed from program
 execution (in this case the value of `y`):
@@ -133,10 +133,10 @@ y = "0x0000000000000000000000000000000000000000000000000000000000000002"
 Once a proof is generated, we can verify correct execution of our Noir program by verifying the
 proof file.
 
-Verify your proof of name `p` by running:
+Verify your proof by running:
 
 ```sh
-nargo verify p
+nargo verify
 ```
 
 The verification will complete in silence if it is successful. If it fails, it will log the

docs/getting_started/02_breakdown.md

@@ -35,30 +35,48 @@ _Verifier.toml_ contains public in/output values computed when executing the Noi
 
 _Nargo.toml_ contains the environmental options of your project. It contains a "package" section and a "dependencies" section.
 
-#### Package section
-
-The package section requires a number of fields including:
-
-- name - the name of the package
-- type - can be "bin", "lib", or "contract" to specify whether its a binary, library or Aztec contract
-- authors
-- compiler_version - specifies the version of the compiler to use. This is not currently enforced by the compiler, but will be in future versions.
-
-For example:
+Example Nargo.toml:
 
 ```toml
 [package]
 name = "noirstarter"
 type = "bin"
 authors = ["Alice"]
 compiler_version = "0.9.0"
+description = "Getting started with Noir"
+entry = "circuit/main.nr"
+license = "MIT"
+
+[dependencies]
+ecrecover = {tag = "v0.9.0", git = "https://github.com/colinnielsen/ecrecover-noir.git"}
 ```
 
+Nargo.toml for a [workspace](../modules_packages_crates/workspaces) will look a bit different. For example:
+
+```toml
+[workspace]
+members = ["crates/a", "crates/b"]
+default-member = "crates/a"
+```
+
+#### Package section
+
+The package section requires a number of fields including:
+
+- `name` (**required**) - the name of the package
+- `type` (**required**) - can be "bin", "lib", or "contract" to specify whether its a binary, library or Aztec contract
+- `authors` (optional) - authors of the project
+- `compiler_version` (optional) - specifies the version of the compiler to use. This is not currently enforced by the compiler, but will be in future versions.
+- `description` (optional)
+- `entry` (optional) - a relative filepath to use as the entry point into your package (overrides the default of `src/lib.nr` or `src/main.nr`)
+- `backend` (optional)
+- `license` (optional)
+
 #### Dependencies section
 
 This is where you will specify any dependencies for your project. See the [Dependencies page](../modules_packages_crates/dependencies) for more info.
 
-_proofs_ and _contract_ directories will not be immediately visible until you create a proof or
+`./proofs/` and `./contract/` directories will not be immediately visible until you create a proof or
 verifier contract respectively.
 
 ### main.nr
@@ -95,13 +113,12 @@ x = "1"
 y = "2"
 ```
 
-When the command `nargo prove my_proof` is executed, two processes happen:
+When the command `nargo prove` is executed, two processes happen:
 
 1. Noir creates a proof that `x` which holds the value of `1` and `y` which holds the value of `2`
    is not equal. This not equal constraint is due to the line `assert(x != y)`.
 
-2. Noir creates and stores the proof of this statement in the _proofs_ directory and names the proof
-   file _my_proof_. Opening this file will display the proof in hex format.
+2. Noir creates and stores the proof of this statement in the _proofs_ directory in a file called your-project.proof. So if your project is named "private_voting" (defined in the project Nargo.toml), the proof will be saved at `./proofs/private_voting.proof`. Opening this file will display the proof in hex format.
 
 #### Arrays of Structs
 
@@ -139,23 +156,23 @@ baz = 2
 
 You can specify a `toml` file with a different name to use for proving by using the `--prover-name` or `-p` flags.
 
-This command looks for proof inputs in the default **Prover.toml** and generates proof `p`:
+This command looks for proof inputs in the default **Prover.toml** and generates the proof and saves it at `./proofs/<project-name>.proof`:
 
 ```bash
-nargo prove p
+nargo prove
 ```
 
-This command looks for proof inputs in the custom **OtherProver.toml** and generates proof `pp`:
+This command looks for proof inputs in the custom **OtherProver.toml** and generates proof and saves it at `./proofs/<project-name>.proof`:
 
 ```bash
-nargo prove -p OtherProver pp
+nargo prove -p OtherProver
 ```
 
 ## Verifying a Proof
 
-When the command `nargo verify my_proof` is executed, two processes happen:
+When the command `nargo verify` is executed, two processes happen:
 
-1. Noir checks in the _proofs_ directory for a file called _my_proof_
+1. Noir checks in the _proofs_ directory for a proof file with the project name (eg. test_project.proof)
 
 2. If that file is found, the proof's validity is checked
 

docs/language_concepts/00_data_types.md

@@ -133,7 +133,7 @@ fn main() {
 > **Note:** When returning a boolean value, it will show up as a value of 1 for `true` and 0 for
 > `false` in _Verifier.toml_.
 
-The boolean type is most commonly used in conditionals like `if` expressions and `constrain`
+The boolean type is most commonly used in conditionals like `if` expressions and `assert`
 statements. More about conditionals is covered in the [Control Flow](./control_flow) and
 [Assert Function](./assert) sections.
 

docs/language_concepts/03_ops.md

@@ -72,12 +72,12 @@ let mut flag = 1;
 if (my_val > 6) | (my_val == 0) {
     flag = 0;
 }
-constrain flag == 1;
+assert(flag == 1);
 
 if (my_val != 10) & (my_val < 50) {
     flag = 0;
 }
-constrain flag == 0;
+assert(flag == 0);
 ```
 
 ### Shorthand operators

docs/language_concepts/07_mutability.md

@@ -29,7 +29,7 @@ c = 13; // OK
 d = 14; // OK
 
 // etc.
-let MyStruct { x: mut y } = MyStruct { x: a }
+let MyStruct { x: mut y } = MyStruct { x: a };
 // y is now in scope
 ```
 

docs/modules_packages_crates/crates_and_packages.md

@@ -1,7 +1,6 @@
 ---
 title: Crates and Packages
-description:
-  Learn how to use Crates and Packages in your Noir project
+description: Learn how to use Crates and Packages in your Noir project
 keywords: [Nargo, dependencies, package management, crates, package]
 ---
 
@@ -12,12 +11,20 @@ Crates can contain modules, and the modules may be defined in other files that g
 
 ### Crate Types
 
-A Noir crate can come in one of two forms: a binary crate or a library crate.
+A Noir crate can come in several forms: binaries, libraries or contracts.
+
+#### Binaries
 
 _Binary crates_ are programs which you can compile to an ACIR circuit which you can then create proofs against. Each must have a function called `main` that defines the ACIR circuit which is to be proved.
 
+#### Libraries
+
 _Library crates_ don't have a `main` function and they don't compile down to ACIR. Instead they define functionality intended to be shared with multiple projects, and eventually included in a binary crate.
 
+#### Contracts
+
+Contract crates are similar to binary crates in that they compile to ACIR which you can create proofs against. They are different in that they do not have a single `main` function, but are a collection of functions to be deployed to the [Aztec network](https://aztec.network). You can learn more about the technical details of Aztec in the [monorepo](https://github.com/AztecProtocol/aztec-packages) or contract [examples](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/noir-contracts/src/contracts).
+
 ### Crate Root
 
 Every crate has a root, which is the source file that the compiler starts, this is also known as the root module. The Noir compiler does not enforce any conditions on the name of the file which is the crate root, however if you are compiling via Nargo the crate root must be called `lib.nr` or `main.nr` for library or binary crates respectively.

docs/modules_packages_crates/dependencies.md

@@ -1,5 +1,5 @@
 ---
-title: Managing Dependencies
+title: Dependencies
 description:
   Learn how to specify and manage dependencies in Nargo, allowing you to upload packages to GitHub
   and use them easily in your project.
@@ -34,7 +34,7 @@ You can also specify dependencies that are local to your machine.
 
 For example, this file structure has a library and binary crate
 
-```
+```tree
 ├── binary_crate
 │   ├── Nargo.toml
 │   └── src
@@ -79,6 +79,10 @@ can import multiple items in the same line by enclosing them in curly braces:
 use dep::std::ec::tecurve::affine::{Curve, Point};
 ```
 
+We don't have a way to consume libraries from inside a [workspace](./workspaces) as external dependencies right now.
+
+Inside a workspace, these are consumed as `{ path = "../to_lib" }` dependencies in Nargo.toml.
+
 ## Dependencies of Dependencies
 
 Note that when you import a dependency, you also get access to all of the dependencies of that package.

docs/modules_packages_crates/modules.md

@@ -1,13 +1,11 @@
 ---
-title: Understanding Modules
+title: Modules
 description:
   Learn how to organize your files using modules in Noir, following the same convention as Rust's
   module system. Examples included.
 keywords: [Noir, Rust, modules, organizing files, sub-modules]
 ---
 
-# Modules
-
 Noir's module system follows the same convention as the _newer_ version of Rust's module system.
 
 ## Purpose of Modules
@@ -51,7 +49,8 @@ crate
 ```
 
 ### Importing a module throughout the tree
-All modules are accessible from the ``crate::`` namespace.
+
+All modules are accessible from the `crate::` namespace.
 
 ```
 crate
@@ -60,7 +59,8 @@ crate
  └── main
 
 ```
-In the above snippet, if ``bar`` would like to use functions in ``foo``, it can do so by ``use crate::foo::function_name``.
+
+In the above snippet, if `bar` would like to use functions in `foo`, it can do so by `use crate::foo::function_name`.
 
 ### Sub-modules
 

docs/modules_packages_crates/workspaces.md

@@ -0,0 +1,39 @@
+---
+title: Workspaces
+---
+
+Workspaces are a feature of nargo that allow you to manage multiple related Noir packages in a single repository. A workspace is essentially a group of related projects that share common build output directories and configurations.
+
+Each Noir project (with it's own Nargo.toml file) can be thought of as a package. Each package is expected to contain exactly one "named circuit", being the "name" defined in Nargo.toml with the program logic defined in `./src/main.nr`.
+
+For a project with the following structure:
+
+```tree
+├── crates
+│   ├── a
+│   │   ├── Nargo.toml
+│   │   └── src
+│   │       └── main.nr
+│   └── b
+│       ├── Nargo.toml
+│       └── src
+│           └── main.nr
+├── Nargo.toml
+└── Prover.toml
+```
+
+You can define a workspace in Nargo.toml like so:
+
+```toml
+[workspace]
+members = ["crates/a", "crates/b"]
+default-member = "crates/a"
+```
+
+`members` indicates which packages are included in the workspace. As such, all member packages of a workspace will be processed when the `--workspace` flag is used with various commands or if a `default-member` is not specified.
+
+`default-member` indicates which package various commands process by default.
+
+Libraries can be defined in a workspace. We just don't have a way to consume libraries from inside a workspace as external dependencies right now.
+
+Inside a workspace, these are consumed as `{ path = "../to_lib" }` dependencies in Nargo.toml.