423: salsa 2022: fix input macro set_* being off by one if id field present r=XFFXFF a=jhgg
This PR fixes an issue with code generation for `#[salsa::input]` struct's `set_` methods.
Consider the following code:
```rust
#[salsa::input(jar = Jar)]
struct BuggedInput {
#[id]
id: u32,
other: String,
}
```
This will expand to:
```rust
#[derive(Copy, Clone, PartialEq, PartialOrd, Eq, Ord, Hash, Debug)]
struct BuggedInput(salsa::Id);
impl BuggedInput {
// snip...
fn set_other<'db>(
self,
__db: &'db mut <Jar as salsa:🫙:Jar<'_>>::DynDb,
) -> salsa::setter::Setter<'db, BuggedInput, u32> {
// ^^^ wrong type (should be `String`)
let (__jar, __runtime) = <_ as salsa::storage::HasJar<Jar>>::jar_mut(__db);
let __ingredients =
<Jar as salsa::storage::HasIngredientsFor<BuggedInput>>::ingredient_mut(__jar);
salsa::setter::Setter::new(__runtime, self, &mut __ingredients.0)
// ^ wrong index (should be `1`)
}
}
```
Here we can see that the generated `set_other` impl is improperly setting the `id` field. This bug is caused because the filtering of the id fields in `InputStruct::all_set_field_names` causes a mismatch in `InputStruct::input_inherent_impl` when zipped with the field indices and types.
This PR changes `all_set_field_names` to return an `Option<&syn::Ident>` where the None is provided when a setter should not be generated, thus not causing index mismatches because no filtering occurs. Instead, we filter inside of `input_inherent_impl` after all the zips have been applied to the iterator.
After this PR, the code generated is now correct:
```rust
#[derive(Copy, Clone, PartialEq, PartialOrd, Eq, Ord, Hash, Debug)]
struct BuggedInput(salsa::Id);
impl BuggedInput {
// snip...
fn set_other<'db>(
self,
__db: &'db mut <Jar as salsa:🫙:Jar<'_>>::DynDb,
) -> salsa::setter::Setter<'db, BuggedInput, String> {
let (__jar, __runtime) = <_ as salsa::storage::HasJar<Jar>>::jar_mut(__db);
let __ingredients =
<Jar as salsa::storage::HasIngredientsFor<BuggedInput>>::ingredient_mut(__jar);
salsa::setter::Setter::new(__runtime, self, &mut __ingredients.1)
}
}
```
Co-authored-by: Jake Heinz <jh@discordapp.com>
This may have been true in the past, but both the Salsa 2022 and original tests demonstrate recovery from a cycle where only a subset of the cycle queries have recovery functions.
412: Fix race condition in interned data r=nikomatsakis a=Skepfyr
In some scenarios the `InternedIngredient` could return two different ids for the same data if called in parallel.
Co-authored-by: Jack Rickard <jack.rickard@outlook.com>
416: Correct docs to refer to `#[salsa::cycle]` r=nikomatsakis a=ssbr
Judging by the examples, `recover` is an outdated name.
E.g. https://github.com/salsa-rs/salsa/blob/master/tests/cycles.rs
(I can't really test this on version 0.16, so I'm just going by the examples.)
Co-authored-by: Devin Jeanpierre <jeanpierreda@google.com>
404: On-demand input r=nikomatsakis a=Skepfyr
Fixes#394
This is not yet done, but I'd like to get some feedback on the approach.
I think these things are remaining:
- [x] Clean up some now incorrect comments in `input_field.rs`
- [x] ~Update calc-example to use on-demand inputs, and remove the lazy-input example (this is quite fun as you end up with an interactive calculator)~
- [x] Update the book
Co-authored-by: Jack Rickard <jack.rickard@outlook.com>
This adds initial support for on-demand inputs by allowing new inputs to
be created with only a shared reference to the database. This allows
creating new inputs during a revision and therefore from inside tracked
functions.
405: Include only identity fields by default in `DebugWithDb::debug` and add `DebugWithDb::debug_all` r=nikomatsakis a=vemoo
This addresses a couple of items of #397
I initially added a separate `DebugWithDb::fmt_all` method but then changed it to an extra parameter to make it easier to propagate to inner fields. Also tried introducing something like:
```rust
pub struct FormatterWithDb<'me, 'f, Db: ?Sized>{
fmt: &'me mut std::fmt::Formatter<'f>,
db: &'me Db,
include_all_fields: bool
}
```
to pass to `fmt`, but I gave up because the lifetimes got a bit unwieldy.
Co-authored-by: Bernardo Uriarte <berublan@gmail.com>
