The internal API is now based around providing
references to the `TrackedStructValue`.
Documenting the invariants led to one interesting
case, which is that we sometimes verify a tracked
struct as not having changed (and even create
`&`-ref to it!) but then re-execute the function
around it.
We now guarantee that, in this case, the data
does not change, even if it has leaked values.
This is required to ensure soundness.
Add a test case about it.
Right now, this doesn't change much except the
behavior in the event that `Eq` is not properly
implemented. In the future, it will enable
the use of references and slices and things.
In a previous PR we added the `include_all_fields`
parameter to `DebugWithDb` to allow it to
not create spurious dependencies.
This PR takes a different approach: we simply
ignore the dependencies created during debug
operations. This is risky as it can create
incorrect dependencies, but it is way more
convenient and seems like what users probably
want.
It also means that `DebugWithDb` has a simpler
signature that matches the `Debug` trait again,
which seems good to me.
Requires unsafe, since Rust currently doesn't have built-in
support for guaranteed in-place initialization. Unfortunately,
this unsafety propagates to making `Jar` unsafe to implement
in order to guarantee that the jar is initialized, but since
the preferred way to implement it is via `salsa::jar`, this
won't impact most users.
435: Allow `clippy::needless_lifetimes` on tracked method getters r=XFFXFF a=DropDemBits
The tracked method generation adds an extra `__db` lifetime to the signature, but clippy complains that this lifetime can be elided in some cases, so add an allow to silence this warning.
Unfortunately clippy doesn't lint inside of the warning tests, so those tests don't do anything to check that no clippy warnings are generated.
Co-authored-by: DropDemBits <r3usrlnd@gmail.com>
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 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.
392: Allow creation of tracked methods r=nikomatsakis a=Skepfyr
Fixes#319.
This allows users to annotate impl blocks with `#[salsa::tracked]` and
then create tracked methods by marking individual functions with
`#[salsa::tracked]`.
Note this requires your code that looks like:
```rust
#[salsa::tracked(jar = Jar)]
impl MyInput {
#[salsa::tracked]
fn tracked_fn(self, db: &dyn Db) -> u32 {
self.field(db) * 2
}
}
```
You get an error if you annotate a method with `#[salsa::tracked]` but forget to mark the impl block.
It got messier than I was hoping but I think it turned out alright, this would look really pretty if we had [inherent associated types](https://github.com/rust-lang/rust/issues/8995), but we don't. Annoyingly even if that landed I think we'd still need the attribute on the impl block just so that it was possible to create the associated struct somewhere as you can't put types inside an impl block (and they aren't accessible if placed inside a function).
Co-authored-by: Jack Rickard <jack.rickard@outlook.com>
