Do manual trait casting

[Veykril]

This removes occurences of dyn Database internally where only the zalsas are needed for (hopefully) a perf increase.

Lastly it renames downcasting to upcasting, because thats what we are doing, dyn Database --downcast-> Concrete --upcast-->dyn CustomDatabaseTrait

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	8c0ec58
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/688b0099a8be6000084da634

[codspeed-hq]

CodSpeed Performance Report

Merging #922 will improve performances by 5.84%

_{Comparing Veykril:veykril/push-tsxunswownmm (8c0ec58) with master (f3dc2f3)}

Summary

⚡ 1 improvements
✅ 11 untouched benchmarks

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⚡	new[InternedInput]	4.3 µs	4 µs	+5.84%

[Veykril]

Benchmarks look fairly noisy again to me

[MichaReiser]

Not sure, 5% is a bit more than usual.

[Veykril]

Well the increase seems to stem from ingredient fetching which means its likely the IngredientCache missing being more expensive after this

[Veykril]

Okay the regression came from a dumb mistake

[Veykril]

Some context for reviewing aid, there are couple of noisy changes (that I could've split out into separate commits, sorry):

• downcasting being renamed to upcasting
• replacing dyn Database args with Zalsa/ZalsaLocal, this allows getting rid of a few dynamic dispatches, mostly concerns the macro changes

[Veykril]

I am quite annoyed by this but that's a limitation of Rust, a &T of T: ?Sized + SomeTrait cannot be coerced to a &dyn SomeTrait (or a supertrait) due to T possibly being an unrelated unsized type like str

[ibraheemdev]

Can we add the Sized requirement?

[Veykril]

No, specifically this is used solely for attach which needs to take a dyn database of some form.

[ibraheemdev]

The changes to avoid dynamic dispatch make sense to me. I'm not sure about renaming the operation to upcasting. Upcasting would be going from a &dyn DatabaseView to &dyn Database, where Database is a supertrait of DatabaseView. What we're doing is going from a &dyn Database to a &dyn DatabaseView -- the other way around. It's similar to downcasting Any to a concrete type, but instead we're downcasting to a "more concrete" subtrait.

[ibraheemdev]

Can we add the Sized requirement?

[Veykril]

The changes to avoid dynamic dispatch make sense to me. I'm not sure about renaming the operation to upcasting. Upcasting would be going from a &dyn DatabaseView to &dyn Database, where Database is a supertrait of DatabaseView. What we're doing is going from a &dyn Database to a &dyn DatabaseView -- the other way around. It's similar to downcasting Any to a concrete type, but instead we're downcasting to a "more concrete" subtrait.

Hmm fair, I think i focused too much on the second step of the casting procedure, going from concrete back to dyn Trait.