mirror of
https://github.com/salsa-rs/salsa.git
synced 2025-01-22 21:05:11 +00:00
A generic framework for on-demand, incrementalized computation. Inspired by adapton, glimmer, and rustc's query system.
252d21e358
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> |
||
---|---|---|
.github/workflows | ||
book | ||
components | ||
examples | ||
examples-2022 | ||
salsa-2022-tests | ||
src | ||
tests | ||
.dir-locals.el | ||
.gitignore | ||
bors.toml | ||
Cargo.toml | ||
FAQ.md | ||
LICENSE-APACHE | ||
LICENSE-MIT | ||
README.md | ||
RELEASES.md | ||
rustfmt.toml |
salsa
A generic framework for on-demand, incrementalized computation.
Obligatory warning
Very much a WORK IN PROGRESS at this point. Ready for experimental use but expect frequent breaking changes.
Credits
This system is heavily inspired by adapton, glimmer, and rustc's query system. So credit goes to Eduard-Mihai Burtescu, Matthew Hammer, Yehuda Katz, and Michael Woerister.
Key idea
The key idea of salsa
is that you define your program as a set of
queries. Every query is used like function K -> V
that maps from
some key of type K
to a value of type V
. Queries come in two basic
varieties:
- Inputs: the base inputs to your system. You can change these whenever you like.
- Functions: pure functions (no side effects) that transform your inputs into other values. The results of queries are memoized to avoid recomputing them a lot. When you make changes to the inputs, we'll figure out (fairly intelligently) when we can re-use these memoized values and when we have to recompute them.
Want to learn more?
To learn more about Salsa, try one of the following:
- read the heavily commented
hello_world
example; - check out the Salsa book;
- watch one of our videos.
Getting in touch
The bulk of the discussion happens in the issues and pull requests, but we have a zulip chat as well.