mirror of
https://github.com/salsa-rs/salsa.git
synced 2025-01-13 00:40:22 +00:00
fad97eeb6a
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).
22 lines
592 B
Rust
22 lines
592 B
Rust
pub(crate) trait Counter: salsa::Database {
|
|
fn increment(&self) -> usize;
|
|
}
|
|
|
|
#[salsa::query_group(GroupStruct)]
|
|
pub(crate) trait Database: Counter {
|
|
fn memoized(&self) -> usize;
|
|
fn volatile(&self) -> usize;
|
|
}
|
|
|
|
/// Because this query is memoized, we only increment the counter
|
|
/// the first time it is invoked.
|
|
fn memoized(db: &dyn Database) -> usize {
|
|
db.volatile()
|
|
}
|
|
|
|
/// Because this query is volatile, each time it is invoked,
|
|
/// we will increment the counter.
|
|
fn volatile(db: &dyn Database) -> usize {
|
|
db.salsa_runtime().report_untracked_read();
|
|
db.increment()
|
|
}
|