Remove links to removed RFCs

book/src/plumbing/jars_and_ingredients.md

@@ -172,8 +172,7 @@ If we had one function ingredient directly invoke a method on `Ingredient<DB>`,
 
 We solve this via the `HasJarsDyn` trait. The `HasJarsDyn` trait exports a method that combines the "find ingredient, invoking method" steps into one method:
 
-[Perhaps this code snippet should only preview the HasJarsDyn method that is being referred to]
-```rust,ignore
+```rust,ignore aasaaasdfijjAasdfa
 {{#include ../../../components/salsa-2022/src/storage.rs:HasJarsDyn}}
 ```
 

book/src/plumbing/terminology/LRU.md

@@ -1,6 +1,6 @@
 # LRU
 
-the [`set_lru_capacity`](https://docs.rs/salsa/0.16.1/salsa/struct.QueryTableMut.html#method.set_lru_capacity) method can be used to fix the maximum capacity for a query at a specific number of values. If more values are added after that point, then salsa will drop the values from older [memos] to conserve memory (we always retain the [dependency] information for those memos, however, so that we can still compute whether values may have changed, even if we don't know what that value is). The LRU mechanism was introduced in [RFC #4](../../rfcs/RFC0004-LRU.md).
+The [`set_lru_capacity`](https://docs.rs/salsa/0.16.1/salsa/struct.QueryTableMut.html#method.set_lru_capacity) method can be used to fix the maximum capacity for a query at a specific number of values. If more values are added after that point, then salsa will drop the values from older [memos] to conserve memory (we always retain the [dependency] information for those memos, however, so that we can still compute whether values may have changed, even if we don't know what that value is).
 
 [memos]: ./memo.md
-[dependency]: ./dependency.md
+[dependency]: ./dependency.md

book/src/plumbing/terminology/durability.md

@@ -1,6 +1,6 @@
 # Durability
 
-*Durability* is an optimization that we use to avoid checking the [dependencies] of a [query] individually. It was introduced in [RFC #5](../../rfcs/RFC0005-Durability.md).
+*Durability* is an optimization that we use to avoid checking the [dependencies] of a [query] individually.
 
 [dependencies]: ./dependency.md
-[query]: ./query.md
+[query]: ./query.md

book/src/tuning.md

@@ -11,8 +11,6 @@ base_db::ParseQuery.in_db_mut(self).set_lru_capacity(lru_capacity);
 
 The default is `0`, which disables LRU-caching entirely.
 
-See [The LRU RFC for more details](./rfcs/RFC0004-LRU.md).
-
 Note that there is no garbage collection for keys and
 results of old queries, so LRU caches are currently the
 only knob available for avoiding unbounded memory usage
@@ -27,7 +25,6 @@ Interning is especially useful for queries that involve nested,
 tree-like data structures.
 
 See:
-- The [Intern Queries RFC](./rfcs/RFC0002-Intern-Queries.md)
 - The [`compiler` example](https://github.com/salsa-rs/salsa/blob/master/examples/compiler/main.rs),
 which uses interning.
 
@@ -47,7 +44,5 @@ If you have a query that contains a long loop which does not execute any interme
 salsa won't be able to cancel it automatically. You may wish to check for cancellation yourself
 by invoking `db.unwind_if_cancelled()`.
 
-For more details on cancellation, see:
-- [the Opinionated cancellation RFC](./rfcs/RFC0007-Opinionated-Cancelation.md).
-- The tests for cancellation behavior in the Salsa repo.
+For more details on cancellation, see the tests for cancellation behavior in the Salsa repo.
 

book/src/tutorial/ir.md

@@ -165,4 +165,4 @@ Since statements and expressions are not tracked, this implies that we are only
 whenever anything in a function body changes, we consider the entire function body dirty and re-execute anything that depended on it.
 It usually makes sense to draw some kind of "reasonably coarse" boundary like this.
 
-One downside of the way we have set things up: we inlined the position into each of the structs [what exactly does this mean?].
+One downside of the way we have set things up: we inlined the position into each of the structs.