salsa/tests/panic-when-creating-tracked-struct-outside-of-tracked-fn.rs

//! Test that creating a tracked struct outside of a
//! tracked function panics with an assert message.

#[salsa::tracked]
struct MyTracked<'db> {
    field: u32,
}

#[test]
#[should_panic(
    expected = "cannot create a tracked struct disambiguator outside of a tracked function"
)]
fn execute() {
    let db = salsa::DatabaseImpl::new();
    MyTracked::new(&db, 0);
}
Improve assert message when creating a tracked struct outside of a tracked function 2023-06-13 20:34:48 +00:00			`//! Test that creating a tracked struct outside of a`
			`//! tracked function panics with an assert message.`

wip 2024-07-16 10:04:01 +00:00			`#[salsa::tracked]`
'db all the things 2024-05-24 01:16:30 +00:00			`struct MyTracked<'db> {`
Improve assert message when creating a tracked struct outside of a tracked function 2023-06-13 20:34:48 +00:00			`field: u32,`
			`}`

			`#[test]`
			`#[should_panic(`
			`expected = "cannot create a tracked struct disambiguator outside of a tracked function"`
			`)]`
			`fn execute() {`
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-27 12:29:41 +00:00			`let db = salsa::DatabaseImpl::new();`
Improve assert message when creating a tracked struct outside of a tracked function 2023-06-13 20:34:48 +00:00			`MyTracked::new(&db, 0);`
			`}`