Previosly, panicking query would remove in-progress memos from the
table.
However, we use panic for cancellation, so it's reasonable to **not**
remove the old result after panic. This is also known as string
exception safety guarantee: not only database is in *some* consistent
state after a panic, it is in the same state it was before the panic!
Transparent queries are not really queries: they are just plain
uncached functions without any backing storage.
Making a query transparent can be useful to figure out if caching it
at all is a win
Now, the effect of GC is a "product" of three parameters:
* what values are affected (everything/everything except used)
* are we removing values
* are we removing deps
SweepStrategy::default is now a no-op GC.
Switch to a procedural implementation of the `query_group!` macro,
residing in the `components/salsa_macros` subcrate.
Allow the user to override the invoked function via `salsa::invoke(...)`
and the name of the generated query type via `salsa::query_type(...)`.
In all tests, replace the `salsa::query_group! { ... }` invocations with
the new attribute-style `#[salsa::query_group]` macro, and change them
to the new naming scheme for query types (`...Query`).
Update README, examples, and documentation.
If a query observes an untracked read, it gets changed_at equal to the
current revision. When we re-validate the query later, if it doesn't
do an untracked read this time, it gets changed_at equal to the
maximum of the dependencies. Crucially, this new changed_at may
be **older** then the previous value of changed_at. That is, we break
the rule that `changed_at` monotonically increases.
This can lead to missed re-executions down the line (see the added
test).
closes#66
