Closed nikomatsakis closed 1 month ago
Name | Link |
---|---|
Latest commit | 1bce41f5d68903ca03c7e1222977c5c8f7df24d1 |
Latest deploy log | https://app.netlify.com/sites/salsa-rs/deploys/66af3a088db6e50008713708 |
Comparing nikomatsakis:spindle2
(1bce41f) with master
(7bdf51c)
✅ 1
untouched benchmarks
@MichaReiser I've been AFK for a bit...hopefully will be getting more reliable internet access soon. I've been thinking it over and I think I can produce a variation of this branch where we have the old setup (i.e., you define a struct that contains the Storage), which should address the various concerns you've raised.
No worries. I hope you're having a great time. I don't have a strong preference over either approach. I think both is fine. The only real blocking item right now is that I don't know how to implement Upcast
.
@MichaReiser I retooled it now, take a look. I think you convinced me that the old approach was better. We now have:
Database
trait and DatabaseImpl
struct.#[salsa::db]
; the struct must have storage: salsa::Storage<Self>
as one of its fields.I went ahead and pushed some other commits I had that make things miri-safe again (at least I think they do, let's see what CI has to say about it).
Prototype new database design. See the final commit for a write-up. This is ready to land but I was planning to do a bit more work, in particular removing the use of thread-local state.
Update: I've removed the thread-local state now.
KEY CHANGES
Handle
-- just clone the database; when you try to make mutation, it will cancel other clonessalsa::DatabaseImpl
as a default database if you don't need customizationssalsa::db
is unchanged, you can still define your own database traits and types