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>
401: Support singleton inputs #337 r=nikomatsakis a=OLUWAMUYIWA
## What?
In #337, it was requested `Singleton` input option be made available for Input structs with a single field. This PR addresses that
## How?
I basically followed the mentoring instructions made available.
Fixes#337
Co-authored-by: OLUWAMUYIWA <onigbindemy@gmail.com>
Co-authored-by: Onigbinde Oluwamuyiwa Elijah <onigbindemy@gmail.com>
408: Exhaustive macros test r=nikomatsakis a=OLUWAMUYIWA
### What
Used `trybuild` to verify that incompatible options with salsa structs will not compile
Ref: #354
### How:
I created a `.rs` file for each salsa struct. I decided not to create one for each incompatible option, as this would only greatly increase the number of files.
Co-authored-by: OLUWAMUYIWA <onigbindemy@gmail.com>
Co-authored-by: Onigbinde Oluwamuyiwa Elijah <onigbindemy@gmail.com>
393: Allow "constant" tracked functions r=XFFXFF a=Skepfyr
Fixes#323.
This adds support for tracked functions with only a database as input,
that is, it does not take a salsa struct.
I'm not entirely convinced by this, it feels like it works somewhat accidentally and may be fragile to changes. I'm happy if this just get closed as I was mostly playing around to see how this worked.
This change has the odd side-effect of making this code work:
```rust
#[salsa::tracked]
fn tracked_fn(db: &dyn Db, unit: ()) -> u32 {
44
}
```
Co-authored-by: Jack Rickard <jack.rickard@outlook.com>
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>
