mirror of
https://github.com/salsa-rs/salsa.git
synced 2024-10-23 20:59:51 +00:00
daaa78056a
Under this design, *all* databases are a `DatabaseImpl<U>`, where the `U` implements `UserData` (you can use `()` if there is none). Code would default to `&dyn salsa::Database` but if you want to give access to the userdata, you can define a custom database trait `MyDatabase: salsa::Databse` so long as you * annotate `MyDatabase` trait definition of impls of `MyDatabase` with `#[salsa::db]` * implement `MyDatabase` for `DatabaseImpl<U>` where `U` is your userdata (this could be a blanket impl, if you don't know the precise userdata type). The `tests/common/mod.rs` shows the pattern.
35 lines
725 B
Rust
35 lines
725 B
Rust
use salsa::{Database as Db, Setter};
|
|
use test_log::test;
|
|
|
|
#[salsa::input]
|
|
struct MyInput {
|
|
field: u32,
|
|
}
|
|
|
|
#[salsa::tracked]
|
|
struct MyTracked<'db> {
|
|
field: u32,
|
|
}
|
|
|
|
#[salsa::tracked]
|
|
fn tracked_fn(db: &dyn Db, input: MyInput) -> MyTracked<'_> {
|
|
MyTracked::new(db, input.field(db) / 2)
|
|
}
|
|
|
|
#[test]
|
|
fn execute() {
|
|
let mut db = salsa::DatabaseImpl::new();
|
|
|
|
let input1 = MyInput::new(&db, 22);
|
|
let input2 = MyInput::new(&db, 44);
|
|
let _tracked1 = tracked_fn(&db, input1);
|
|
let _tracked2 = tracked_fn(&db, input2);
|
|
|
|
// modify the input and change the revision
|
|
input1.set_field(&mut db).to(24);
|
|
let tracked2 = tracked_fn(&db, input2);
|
|
|
|
// this should not panic
|
|
tracked2.field(&db);
|
|
}
|