Merge pull request #515 from ProvableHQ/update-leo3.2.0

Update docs to be in line with Leo 3.2.0

Author: d0cd

documentation/cli/14_update.md

@@ -19,8 +19,18 @@ Checking latest released version... v3.1.0
 Leo is already on the latest version
 ```
 
+If you'd like to install a specific version of Leo, you can do so by passing the `--name` flag:
+
+```bash
+leo update --name v3.0.0
+```
+
 ### Flags:
 #### `-l`
 #### `--list`
 Lists all available versions of Leo.
 
+#### `-n`
+#### `--name`
+An optional release name if you wish to install a specific version of Leo.  By default, the command will look for the latest release.
+

documentation/getting_started/03_hello.md

@@ -45,9 +45,7 @@ hello/
 ```
 
 The program ID in `program` is the official name that other developers will be able to look up after the program has been deployed to a network.  This must be the same as the name of your program in `main.leo`, or compilation will fail.
-```json
-    "program": "hello.aleo",
-```
+
 
 Dependencies will be added to the field of the same name, as they are imported.  Dependencies that are only used during development and not in production will be added to the `dev_dependencies` field.
 
@@ -111,11 +109,11 @@ All programs must have an explicitly declared constructor function.
 For now, we'll leave it as is, which will prevent upgrades from occurring. For more details on how program upgradability works, and different patterns for upgrading your programs, check out [Upgrading Programs](./../guides/10_program_upgradability.md).
 
 
-Now let's compile the program and run the program.
+Now let's compile and run the program.
 
 ## Build and Run 
 
-Now let's compile the program.
+To compile the program, run:
 ```
 leo build
 ```

documentation/language/01_layout.md

@@ -3,9 +3,9 @@ id: layout
 title: Layout of a Leo Project
 sidebar_label: Project Layout
 ---
-[general tags]: # (project, project_layout, manifest)
+[general tags]: # (project, project_layout, manifest, module)
 
-### The Manifest
+## The Manifest
 
 **program.json** is the Leo manifest file that configures our package.
 ```json title="program.json"
@@ -14,7 +14,8 @@ sidebar_label: Project Layout
   "version": "0.1.0",
   "description": "",
   "license": "MIT",
-  "dependencies": null
+  "dependencies": null,
+  "dev_dependencies": null
 }
 ```
 
@@ -23,4 +24,68 @@ The program ID in `program` is the official name that other developers will be a
     "program": "hello.aleo",
 ```
 
-Dependencies will be added to the field of the same name, as they are added. The dependencies are also pegged in the **leo.lock** file.
+Dependencies will be added to the field of the same name, as they are added. The dependencies are also pegged in the **leo.lock** file.
+
+## The Code
+
+The `src/` directory is where all of your Leo code will live.  The main entry point of your project is a file in this directory.appropriately named `main.leo`.  Calls to many of the Leo CLI commands will require you to have this file within your project in order to succeed properly.
+
+
+### Modules 
+
+In addition to your main file, Leo also supports a module system as of v3.2.0.
+
+Leaf modules (i.e. modules without submodules) must be defined in a single file (ex. `foo.leo`).  Modules with submodules must be defined by an optional top-level `.leo` file and a subdirectory directory containing the submodules:
+
+
+Take the following project as an example:
+```
+src
+├── common.leo
+├── main.leo
+├── outer.leo
+└── outer
+    └── inner.leo
+```
+
+Given the structure above, the following modules are defined:
+
+| Filename | Type | Module Name | Access Location & Pattern |
+| -------- | ---- | ----------- | ------------------------- |
+| `common.leo` | Module | `common` | `main.leo` : `common::<item>`  |
+| `outer.leo` | Module | `outer` | `main.leo` : `outer::<item>` |
+| `outer/inner.leo` | Submodule | `outer::inner` |`main.leo` : `outer::inner::<item>` <br> `outer.leo` : `inner::<item>`|
+
+:::info
+Only relative paths are implemented so far. That means that items in `outer.leo` cannot be accessed from items in `inner.leo`, for example. This is limiting for now but will no longer be an issue when we add absolute paths.
+:::
+
+
+A module file may only contain `struct`, `const`, and `inline` definitions:
+
+```leo
+const X: u32 = 2u32;
+
+struct S {
+    a: field
+}
+
+inline increment(x: field) -> field {
+    return 1field;
+}
+```
+
+
+<!-- 
+
+## The Tests
+
+TODO
+
+## The Build and Outputs
+
+Only generated when the project is compiled.  Removed when `leo clean` is called. 
+
+TODO
+
+-->