salsa/tests/accumulate-execution-order.rs
Niko Matsakis daaa78056a switch to new database design
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.
2024-07-28 12:47:50 +00:00

64 lines
1.4 KiB
Rust

//! Demonstrates that accumulation is done in the order
//! in which things were originally executed.
mod common;
use expect_test::expect;
use salsa::{Accumulator, Database};
use test_log::test;
#[salsa::accumulator]
struct Log(#[allow(dead_code)] String);
#[salsa::tracked]
fn push_logs(db: &dyn Database) {
push_a_logs(db);
}
#[salsa::tracked]
fn push_a_logs(db: &dyn Database) {
Log("log a".to_string()).accumulate(db);
push_b_logs(db);
push_c_logs(db);
push_d_logs(db);
}
#[salsa::tracked]
fn push_b_logs(db: &dyn Database) {
Log("log b".to_string()).accumulate(db);
push_d_logs(db);
}
#[salsa::tracked]
fn push_c_logs(db: &dyn Database) {
Log("log c".to_string()).accumulate(db);
}
#[salsa::tracked]
fn push_d_logs(db: &dyn Database) {
Log("log d".to_string()).accumulate(db);
}
#[test]
fn accumulate_execution_order() {
salsa::DatabaseImpl::new().attach(|db| {
let logs = push_logs::accumulated::<Log>(db);
// Check that we get logs in execution order
expect![[r#"
[
Log(
"log a",
),
Log(
"log b",
),
Log(
"log d",
),
Log(
"log c",
),
]"#]]
.assert_eq(&format!("{:#?}", logs));
})
}