In old code, we converted to a `&'db` when
creating a new tracked struct or interning,
but this value in fact persisted beyond the end
of `'db` (i.e., into the new revision).
We now refactor so that we create the `Foo<'db>`
from a `NonNull<T>` instead of a `&'db T`, and
then only create safe references when users
access fields.
This makes miri happy.
We now have AsId (always present)
and FromId/LookupId (sometimes present).
AsId is no longer part of the
salsa public interface.
Replace the ad-hoc `salsa_id` etc methods with
calls to `AsId::as_id`.
Previously tracked structs relied on an
interned ingredient to intern their keys.
But really it has more complex logic than we
need. Simpler to just remove it and duplicate
the basic concept.
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.
There are 3 call-sites to this function:
* One of them has already marked the outputs
* One of them has no outputs
* The third does need to mark the outputs
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.
First step towards the new tracked struct design.
SUBTLE: This is actually broken if the `#[id]`
fields have a broken hash. We'll fix that in the
next commit and add a test.
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.
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>
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.
406: no need to generate a config struct for each field of `salsa::input` r=nikomatsakis a=XFFXFF
https://github.com/salsa-rs/salsa/pull/342 added `InputFieldIngredient` which replaces the `FunctionIngredient` for `salsa::input`, so we don't need to generate a config struct and `salsa::function::Configuration` impl for each field, beacuse they are only needed when we use `FunctionIngredient`
Co-authored-by: XFFXFF <1247714429@qq.com>
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>
This changes tracked methods from being annotated with `#[tracked]` to
`#[salsa::tracked]`. This improves consistency and allows outputting a
nicer error message if someone forgets to put the attribute on the impl
block.
383: Have users of `SalsaStruct` specify allowed options r=XFFXFF a=DropDemBits
This allows adding new options exclusively to `tracked`, `input`, `interned`, or any combination of them, without having to add support code to `SalsaStruct`.
The motivating example is #337, where `input` needs to accept a new `singleton` option, but `tracked` and `interned` should reject it.
Co-authored-by: DropDemBits <r3usrlnd@gmail.com>
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>
