Assign memo ingredients per salsa-struct-ingredient

[ShoyuVanilla]

Closes #600

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	38ad655
🔍 Latest deploy log	https://app.netlify.com/sites/salsa-rs/deploys/673d39260520da0008776f8d

[codspeed-hq]

CodSpeed Performance Report

Merging #614 will not alter performance

_{Comparing ShoyuVanilla:issue-600 (38ad655) with master (e4d36da)}

Summary

✅ 8 untouched benchmarks

[ShoyuVanilla]

I don't like this new table for SalsaStruct -> IngredientIndex but I couldn't find any other way to pass the salsa-struct-ingredient to its tracked function when creating the function's ingredient, as salsa-struct-ingredient is accessible only with its Configuration, that is private inside the macro-expanded code of that salsa struct.
Would there be some good alternatives?

[MichaReiser]

I would be inclined to add a method ingredient_index to SalsaStructInDb but best to hear what @nikomatsakis thinks

[ShoyuVanilla]

We need to get the IngredientIndex for salsa struct here;

salsa/components/salsa-macro-rules/src/setup_tracked_fn.rs

Lines 196 to 205 in e4d36da

	impl $zalsa::Jar for $Configuration {
	fn create_ingredients(
	&self,
	aux: &dyn $zalsa::JarAux,
	first_index: $zalsa::IngredientIndex,
	) -> Vec<Box<dyn $zalsa::Ingredient>> {
	let fn_ingredient = <$zalsa::function::IngredientImpl<$Configuration>>::new(
	first_index,
	aux,
	);

and we can't get the actual instance of salsa struct here. All we have is JarAux - actually, this is Zalsa -, so that function should be a static method, I guess. (I'm afraid that this makes SalsaStructInDb dyn-incompatible but we are not using it as a trait object anywhere in salsa)

Thus, the function would be implemented inside our setup_* macros like;

fn ingredient_index(aux: &dyn JarAux) -> IngredientIndex {
    aux.lookup_jar_by_type(JarImpl::<$Configuration>::default())
}

and we need to expose some method like lookup_jar_by_type in JarAux, I think.

[MichaReiser]

I don't think we currently have a test for a tracked fn that has more than one argument (other than db) and thus uses the interner. Could you double check if that's indeed the case and, if so, add a test for it?

[MichaReiser]

Nit:

Suggested change

	/// [ingredient-indices](`IngredientIndex`)for tracked functions that have this salsa struct
	/// as input.
	memo_ingredients: RwLock<FxHashMap<IngredientIndex, Vec<IngredientIndex>>>,
	/// [ingredient-indices](`IngredientIndex`) for tracked functions that have this salsa struct
	/// as input.
	memo_ingredient_indices: RwLock<FxHashMap<IngredientIndex, Vec<IngredientIndex>>>,

I also have a slight preference to the name @nikomatsakis suggest in the mentoring instructions (memo_ingredient_indices)

[MichaReiser]

We could consider using a Vec<Vec<IngredientIndex>> here and directly index into the Vec using the IngredientIndex as an offset. This would result in wasting some memory because not every IngredientIndex is an index for a tracked struct but it would avoid one additional hashing step

[ShoyuVanilla]

I don't think we currently have a test for a tracked fn that has more than one argument (other than db) and thus uses the internet. Could you double check if that's indeed the case and, if so, add a test for it?

Sure! I'll add tests and edit things you commented when I get home. Thanks for the review

[ShoyuVanilla]

I changed salsa struct ingredient lookup as I said here but I had to change this to avoid deadlocks 😢