296: Slot no more: overhauled internal algorithm r=nikomatsakis a=nikomatsakis
This is the overhauled implementation that avoids slots, is more parallel friendly, and paves the way to fixed point and more expressive cycle handling.
We just spent 90 minutes going over it. [Some rough notes are available here,](https://hackmd.io/6x9f6mavTRS2imfG96tP5A) and a video will be posted soon.
You may find the [flowgraph useful](https://raw.githubusercontent.com/nikomatsakis/salsa/slot-no-more/book/src/derived-query-read.drawio.svg).
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
This change resolves a fixme that referenced #120.
This change breaks no tests, and, if I understand
correctly, does not affect user-facing API.
Here is the difference for the `HelloWorldGroupStorage__` struct
generated from macros in the `hello_world` example:
**Before:**
```rs
struct HelloWorldGroupStorage__ {
pub input_string:std::sync::Arc<<InputStringQuery as salsa::Query> ::Storage> ,pub length:std::sync::Arc<<LengthQuery as salsa::Query> ::Storage> ,
}
```
**After:**
```rs
struct HelloWorldGroupStorage__ {
input_string:std::sync::Arc<<InputStringQuery as salsa::Query> ::Storage> ,length:std::sync::Arc<<LengthQuery as salsa::Query> ::Storage> ,
}
```
Instead of grabbing the arc, just pass back an `&mut Runtime`.
The eventual goal is to get rid of the lock on the `set` pathway
altogether, but one step at a time.
290: Update doc in macro about query.in_db for dyn db r=nikomatsakis a=mheiber
Update the macro for `query_group` so the comment
on `fn in_db` no longer says that it is more common
to use the trait method on `db`.
Afaict, the trait methods referred to were removed
when dyn database were introduced in RFC0006:
./book/src/rfcs/RFC0006-Dynamic-Databases.md, as
described in the section
"Instead of `db.query(Q)`, you write `Q.in_db(&db)`"
Co-authored-by: Maxwell Elliot Heiber <mheiber@fb.com>
Update the macro for `query_group` so the comment
on `fn in_db` no longer says that it is more common
to use the trait method on `db`.
Afaict, the trait methods referred to were removed
when dyn database were introduced in RFC0006:
./book/src/rfcs/RFC0006-Dynamic-Databases.md, as
described in the section
"Instead of `db.query(Q)`, you write `Q.in_db(&db)`"
Rather than checking return value of from `Q::cycle_fallback`, we
now consult the computed recovery strategy to decide whether to
panic or to recover. We can thus assume that we will successfully
recover and don't need to check for `None` results anymore.
This had two unexpected consequences, one unfortunate, one "medium":
* All `salsa::Database` must be `'static`. This falls out from
`Q::DynDb` not having access to any lifetimes, but also the defaulting
rules for `dyn QueryGroup` that make it `dyn QueryGroup + 'static`. We
don't really support generic databases anyway yet so this isn't a big
deal, and we can add workarounds later (ideally via GATs).
* It is now statically impossible to invoke `snapshot` from a query,
and so we don't need to test that it panics. This is because the
signature of `snapshot` returns a `Snapshot<Self>` and that is not
accessible to a `dyn QueryGroup` type. Similarly, invoking
`Runtime::snapshot` directly is not possible becaues it is
crate-private. So I removed the test. This seems ok, but eventually I
would like to expose ways for queries to do parallel
execution (matklad and I had talked about a "speculation" primitive
for enabling that).
* This commit is 99% boilerplate I did with search-and-replace. I also
rolled in a few other changes I might have preferred to factor out,
most notably removing the `GetQueryTable` plumbing trait in favor of
free-methods, but it was awkward to factor them out and get all the
generics right (so much simpler in this version).
