* Add test for untracked read on tracked struct created in previous cycle
* Initial fix
* Restrict seeding to memos from the same revision
* Reduce changes
* seed_outputs
* Cleanup test
* Add assertion
* Try
* Try merging outputs after query executed
* Assert logs from first execution
* Enable trace level logging
* Use `FxIndexSet` in `diff_outputs`
* Log more events
* Cleanup
* Append outputs only once
* remove table-wide dependencies
* add plumbing to reuse interned slots
* record durabilities on interned values
* appease clippy
* remove immortal interned value logic
* pass correct revision when tracking interned reads
* force new revision when resetting interned values
* avoid unnecessary calls to `Database::zalsa`
* add log events for value internment
* Only log event kind because thread id can differ between runs/computers
* cargo fmt
---------
Co-authored-by: Micha Reiser <micha@reiser.io>
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.
