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).
Quickest POC I could create to get some potentially cyclic queries to
not panic and instead return a result I could act on. (gluon's module
importing need to error on cycles).
```
// Causes `db.query()` to actually return `Result<V, CycleError>`
fn query(&self, key: K, key2: K2) -> V;
```
A proper implementation of this would likely return
`Result<V, CycleError<(K, K2)>>` or maybe larger changes are needed.
cc #6
The unsafe impl now asserts that the `DatabaseSlot` implementor type
is indeed `Send+Sync` if `DB::DatabaseData` is `Send+Sync`. Since our
query keys/values are a part of database-data, this means that `Slot`
must be `Send+Sync` if the key/value are `Send+Sync`. We test this
with a function that will cause compliation to fail if we accidentally
introduce an `Rc<T>` etc.
Transparent queries are not really queries: they are just plain
uncached functions without any backing storage.
Making a query transparent can be useful to figure out if caching it
at all is a win
Changes:
- Add interned keys to salsa (#150) -- see salsa-rs/salsa-rfcs#2
for more details.
- Fix bugs re: GC and volatile queries
- Optimization for GC (#144), though I think this later got undone
as part of the bug fixes =)
- GC API now more orthogonal + flexible (#138)
- Removed `set_unchecked` testing mechanism (#141)
- Generated enums now squelch `non_camel_case_types` lint (#135)
- Tests now using `set_foo` (#139)
- `Query::group_storage` now called `Query::query_storage` (#142)
Contributors to this release:
- @matklad
- @memoryruins
- @nikomatsakis
All the example code uses Default to create the db structs, but it turns
out the *GroupStorage's `#[derive(Default)]` adds a trait bound of
(e.g.) `DB__ + Default + HelloWorldDatabase` even though it never
actually needs to call HelloWorldDatabase::default(). So if you didn't
implement Default, then you couldn't be a salsa database struct.
Switch to a procedural implementation of the `query_group!` macro,
residing in the `components/salsa_macros` subcrate.
Allow the user to override the invoked function via `salsa::invoke(...)`
and the name of the generated query type via `salsa::query_type(...)`.
In all tests, replace the `salsa::query_group! { ... }` invocations with
the new attribute-style `#[salsa::query_group]` macro, and change them
to the new naming scheme for query types (`...Query`).
Update README, examples, and documentation.
