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).

book/src/tutorial/db.md

@@ -17,9 +17,6 @@ All Salsa structs store the actual values of their fields in the Salsa database.
 This permits us to track when the values of those fields change to figure out what work will need to be re-executed.
 
 When you annotate a struct with one of the above Salsa attributes, Salsa actually generates a bunch of code to link that struct into the database.
-This code must be connected to some [jar](./jar.md).
-By default, this is `crate::Jar`, but you can specify a different jar with the `jar=` attribute (e.g., `#[salsa::input(jar = MyJar)]`).
-You must also list the struct in the jar definition itself, or you will get errors.
 
 ## Input structs