chore: Remove jar mentions from book (#775)

* Remove references to jar terminology

* Update or remove invalid code links in book

Author: detrumi

book/src/SUMMARY.md

@@ -7,7 +7,6 @@
 - [Overview](./overview.md)
 - [Tutorial: calc language](./tutorial.md)
   - [Basic structure](./tutorial/structure.md)
-  - [Jars and databases](./tutorial/jar.md)
   - [Defining the database struct](./tutorial/db.md)
   - [Defining the IR: the various "salsa structs"](./tutorial/ir.md)
   - [Defining the parser: memoized functions and inputs](./tutorial/parser.md)
@@ -28,7 +27,6 @@
 - [How Salsa works](./how_salsa_works.md)
 - [Videos](./videos.md)
 - [Plumbing](./plumbing.md)
-  - [Jars and ingredients](./plumbing/jars_and_ingredients.md)
   - [Databases and runtime](./plumbing/database_and_runtime.md)
   - [The db lifetime on tracked/interned structs](./plumbing/db_lifetime.md)
   - [Tracked structures](./plumbing/tracked_structs.md)

book/src/plumbing.md

@@ -7,7 +7,6 @@ We refer to this as the "plumbing".
 
 The plumbing section is broken up into chapters:
 
-- The [jars and ingredients](./plumbing/jars_and_ingredients.md) covers how each salsa item (like a tracked function) specifies what data it needs and runtime, and how links between items work.
 - The [database and runtime](./plumbing/database_and_runtime.md) covers the data structures that are used at runtime to coordinate workers, trigger cancellation, track which functions are active and what dependencies they have accrued, and so forth.
 - The [query operations](./plumbing/query_ops.md) chapter describes how the major operations on function ingredients work. This text was written for an older version of salsa but the logic is the same:
   - The [maybe changed after](./plumbing/maybe_changed_after.md) operation determines when a memoized value for a tracked function is out of date.

book/src/plumbing/database_and_runtime.md

@@ -4,7 +4,7 @@ A salsa database struct is declared by the user with the `#[salsa::db]` annotati
 It contains all the data that the program needs to execute:
 
 ```rust,ignore
-#[salsa::db(jar0...jarn)]
+#[salsa::db]
 struct MyDatabase {
     storage: Storage<Self>,
     maybe_other_fields: u32,
@@ -28,12 +28,12 @@ The `Snapshot` method returns a `Snapshot<DB>` type, which prevents these clones
 The salsa `Storage` struct contains all the data that salsa itself will use and work with.
 There are three key bits of data:
 
-- The `Shared` struct, which contains the data stored across all snapshots. This is primarily the ingredients described in the [jars and ingredients chapter](./jars_and_ingredients.md), but it also contains some synchronization information (a cond var). This is used for cancellation, as described below.
+- The `Shared` struct, which contains the data stored across all snapshots, such as synchronization information (a cond var). This is used for cancellation, as described below.
   - The data in the `Shared` struct is only shared across threads when other threads are active. Some operations, like mutating an input, require an `&mut` handle to the `Shared` struct. This is obtained by using the `Arc::get_mut` methods; obviously this is only possible when all snapshots and threads have ceased executing, since there must be a single handle to the `Arc`.
-- The `Routes` struct, which contains the information to find any particular ingredient -- this is also shared across all handles, and its construction is also described in the [jars and ingredients chapter](./jars_and_ingredients.md). The routes are separated out from the `Shared` struct because they are truly immutable at all times, and we want to be able to hold a handle to them while getting `&mut` access to the `Shared` struct.
+- The `Routes` struct, which contains the information to find any particular ingredient -- this is also shared across all handles. The routes are separated out from the `Shared` struct because they are truly immutable at all times, and we want to be able to hold a handle to them while getting `&mut` access to the `Shared` struct.
 - The `Runtime` struct, which is specific to a particular database instance. It contains the data for a single active thread, along with some links to shared data of its own.
 
-## Incrementing the revision counter and getting mutable access to the jars
+## Incrementing the revision counter
 
 Salsa's general model is that there is a single "master" copy of the database and, potentially, multiple snapshots.
 The snapshots are not directly owned, they are instead enclosed in a `Snapshot<DB>` type that permits only `&`-deref,
@@ -47,12 +47,6 @@ This allows us to get `&mut` access without any unsafe code and
 guarantees that we have successfully managed to cancel the other worker threads
 (or gotten ourselves into a deadlock).
 
-The code to acquire `&mut` access to the database is the `jars_mut` method:
-
-```rust
-{{#include ../../../src/storage.rs:jars_mut}}
-```
-
 The key initial point is that it invokes `cancel_other_workers` before proceeding:
 
 ```rust

book/src/plumbing/fetch.md

@@ -1,9 +1,5 @@
 # Fetch
 
-```rust,no_run,noplayground
-{{#include ../../../src/plumbing.rs:fetch}}
-```
-
 The `fetch` operation computes the value of a query. It prefers to reuse memoized values when it can.
 
 ## Input queries

book/src/plumbing/jars_and_ingredients.md

@@ -1,9 +1,5 @@
 # Maybe changed after
 
-```rust,no_run,noplayground
-{{#include ../../../src/plumbing.rs:maybe_changed_after}}
-```
-
 The `maybe_changed_after` operation computes whether a query's value *may have changed* **after** the given revision. In other words, `Q.maybe_change_since(R)` is true if the value of the query `Q` may have changed in the revisions `(R+1)..R_now`, where `R_now` is the current revision. Note that it doesn't make sense to ask `maybe_changed_after(R_now)`.
 
 ## Input queries

book/src/plumbing/maybe_changed_after.md

@@ -1,14 +1,6 @@
 # Query operations
 
-Each of the query storage struct implements the `QueryStorageOps` trait found in the [`plumbing`] module:
-
-```rust,no_run,noplayground
-{{#include ../../../src/plumbing.rs:QueryStorageOps}}
-```
-
- which defines the basic operations that all queries support. The most important are these two:
+The most important basic operations that all queries support are:
 
 * [maybe changed after](./maybe_changed_after.md): Returns true if the value of the query (for the given key) may have changed since the given revision.
 * [Fetch](./fetch.md): Returns the up-to-date value for the given K (or an error in the case of an "unrecovered" cycle).
-
-[`plumbing`]: https://github.com/salsa-rs/salsa/blob/master/src/plumbing.rs

book/src/plumbing/query_ops.md

@@ -1,4 +1,3 @@
 # Ingredient
 
-An *ingredient* is an individual piece of storage used to create a [salsa item](./salsa_item.md)
-See the [jars and ingredients](../jars_and_ingredients.md) chapter for more details.
+An *ingredient* is an individual piece of storage used to create a [salsa item](./salsa_item.md)

book/src/plumbing/terminology/ingredient.md

@@ -1,4 +1,3 @@
 # Salsa item
 
-A salsa item is something that is decorated with a `#[salsa::foo]` macro, like a tracked function or struct.
-See the [jars and ingredients](../jars_and_ingredients.md) chapter for more details.
+A salsa item is something that is decorated with a `#[salsa::foo]` macro, like a tracked function or struct.

book/src/plumbing/terminology/salsa_item.md

@@ -1,7 +1,6 @@
 # Defining the database struct
 
-Now that we have defined a [jar](./jar.md), we need to create the **database struct**.
-The database struct is where all the jars come together.
+First, we need to create the **database struct**.
 Typically it is only used by the "driver" of your application;
 the one which starts up the program, supplies the inputs, and relays the outputs.
 
@@ -13,11 +12,8 @@ In `calc`, the database struct is in the [`db`] module, and it looks like this:
 {{#include ../../../examples/calc/db.rs:db_struct}}
 ```
 
-The `#[salsa::db(...)]` attribute takes a list of all the jars to include.
-The struct must have a field named `storage` whose type is `salsa::Storage<Self>`, but it can also contain whatever other fields you want.
-The `storage` struct owns all the data for the jars listed in the `db` attribute.
-
-The `salsa::db` attribute autogenerates a bunch of impls for things like the `salsa::HasJar<crate::Jar>` trait that we saw earlier.
+The `#[salsa::db]` attribute marks the struct as a database.
+It must have a field named `storage` whose type is `salsa::Storage<Self>`, but it can also contain whatever other fields you want.
 
 ## Implementing the `salsa::Database` trait
 
@@ -34,11 +30,3 @@ If you want to permit accessing your database from multiple threads at once, the
 ```rust
 {{#include ../../../examples/calc/db.rs:par_db_impl}}
 ```
-
-## Implementing the traits for each jar
-
-The `Database` struct also needs to implement the [database traits for each jar](./jar.md#database-trait-for-the-jar).
-In our case, though, we already wrote that impl as a [blanket impl alongside the jar itself](./jar.md#implementing-the-database-trait-for-the-jar),
-so no action is needed.
-This is the recommended strategy unless your trait has custom members that depend on fields of the `Database` itself
-(for example, sometimes the `Database` holds some kind of custom resource that you want to give access to).