360: Permit renaming constructors, getters and setters r=nikomatsakis a=MihailMihov
The goal is to add an option `constructor_name` to `#[salsa::input]`, `#[salsa::interned]` and `#[salsa::tracked]` that allows changing the name of the generated constructor. After that add attributes `get` and `set` to the fields which allow overriding the names of the getters and setters. In the end the following snippet should compile and work:
```rust
#[salsa::interned(constructor = from_string)]
struct MyInterned {
#[get(text)] #[set(set_text)] #[return_ref]
field: String,
}
impl MyInterned {
pub fn new(db: &dyn Db, s: impl Display) -> MyInterned {
MyInterned::from_string(db, s.to_string())
}
pub fn field(self, db: &dyn Db) -> &str {
self.text(db)
}
pub fn set_field(self, db: &mut dyn Db, id: String) {
self.set_text(&mut db, id)
}
}
```
resolves#332
Co-authored-by: Mihail Mihov <mmihov.personal@gmail.com>
359: fix: typos in tutorial ir chapter r=nikomatsakis a=dawnofmidnight
Looking at the tutorial, I believe `ProgramSource` is a typo for `SourceProgram`. I'm also pretty sure the `define` -> `derive` is correct, unless `define` is some attribute I'm not aware of.
361: test for compiling failure: lru can not be used with specify r=nikomatsakis a=XFFXFF
ref #354
Test for compile failures with [tybuild](https://github.com/dtolnay/trybuild.git). This is an example to show how it works.
Co-authored-by: dawn <78233879+dawnofmidnight@users.noreply.github.com>
Co-authored-by: XFFXFF <1247714429@qq.com>
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>
358: add from impls for u32/usize r=nikomatsakis a=nikomatsakis
Make it easy to create an `Id`, especially from a `usize`
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
356: make Id::from_u32 public r=nikomatsakis a=nikomatsakis
I made it private 'just because', but it turns out that dada uses it, and it seems reasonable.
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
352: Add options to tracked funcitons for lru capacity r=nikomatsakis a=XFFXFF
fixes#344
Now we can write something like the following to set the lru capacity of tracked functions
```rust
#[salsa::tracked(lru=32)]
fn my_tracked_fn(db: &dyn crate::Db, ...) { }
```
some details:
* lru should not be combined with specify. We will report an error if people do #[salsa::tracked(lru = 32, specify)]
* set 0 as default capacity to disable LRU (Because I think doing this would make the code simpler when implementing `create_ingredients` of tracked functions).
* old salsa support to change lru capacity at runtime, [as noted here](https://salsa-rs.github.io/salsa/rfcs/RFC0004-LRU.html?highlight=change#reference-guide), but we do not support this now
Co-authored-by: XFFXFF <1247714429@qq.com>
350: Accumulators r=nikomatsakis a=nikomatsakis
This branch fixes accumulators so they have the right *behavior* -- the implementation leaves something to be desired, though, in that you don't get very good re-use if you are using accumulators from inside tracked functions. Right now that is treated as an untracked read, so if you want to get good re-use you need a workaround like this one...
```rust
#[salsa::tracked(return_ref)]
fn accumulated_values(db: &dyn Db) -> Vec<T> {
some_query::accumulated::<SomeAccumulator>(db)
}
```
...which would track and compare the new vs old vector and detect when they've changed.
Despite this limitation, this PR makes accumulators behave correctly with respect to the value taht gets returned and is good enough to Fix#313 in my opinion. I'll file an issue for the remaining improvements.
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).
349: GC tracked structs r=nikomatsakis a=nikomatsakis
Extends the system to track when a tracked struct is no longer created in a new revision and eagerly delete data associated with it. It's not a *complete* answer for GC but it seems pretty useful.
Fix#315
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
