376: add `synthetic_write` r=nikomatsakis a=XFFXFF
fixes#364
add `synthetic_write` and use it in test `lru_keeps_dependency_info`, the test will now be broken. We can use `lru_keeps_dependency_info` as a test for https://github.com/salsa-rs/salsa/issues/365, which already has a pr https://github.com/salsa-rs/salsa/pull/371.
379: Update test.yml r=nikomatsakis a=agluszak
- Add names to steps
- No need to run clippy AND check (https://stackoverflow.com/questions/57449356/is-cargo-clippy-a-superset-of-cargo-check)
- Run clippy on all targets with all features
- Fix issues reported by clippy
Co-authored-by: XFFXFF <1247714429@qq.com>
Co-authored-by: Andrzej Głuszak <gluszak.andrzej@gmail.com>
Co-authored-by: andrzej.gluszak <andrzej.gluszak@mpi-sp.org>
369: Try to fix issue#340 r=XFFXFF a=zjp-CN
(WIP)
Follow the instructions from https://github.com/salsa-rs/salsa/issues/340#issuecomment-1210153085.
Still not sure what to do with `fmt_index`...
Fix#340
Co-authored-by: zjp <jiping_zhou@foxmail.com>
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
353: start documenting plumbing r=nikomatsakis a=nikomatsakis
Feedback desired! I am trying to document an overview of the new salsa 2022 plumbing. I'd love for folks to [read these docs and tell me if they make sense](https://deploy-preview-353--salsa-rs.netlify.app/plumbing.html).
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
Accumulators don't currently work across revisions
due to a few bugs. This commit adds 2 tests to show
the problems and reworks the implementation strategy.
We keep track of when the values in an accumulator were pushed
and reset the vector to empty when the push occurs in a new
revision.
We also ignore stale values from old revisions
(but update the revision when it is marked as validated).
Finally, we treat an accumulator as an untracked read,
which is quite conservative but correct. To get better
reuse, we would need to (a) somehow determine when different
values were pushed, e.g. by hashing or tracked the old values;
and (b) have some `DatabaseKeyIndex` we can use to identify
"the values pushed by this query".
Both of these would add overhead to accumulators and I didn'τ
feel like doing it, particularly since the main use case for
them is communicating errors and things which are not typically
used from within queries.
It turns out that we have some outputs (accumulators) for which
it only makes sense to have a `DependencyIndex` (they don't have
individual keys to identify).
We also track whether reset is required at the ingredient level.
For tracked struct fields, we were not using `push_mut`,
and I think that was an oversight.
The plan is to do a "dependent ingredient" interlinking pass
once the database is constructed.
