search

JoJoJet / bevy-trait-query

adds trait queries to the bevy game engine
Apache License 2.0
65 stars 11 forks source link

update to bevy 0.14 #59

Open RobWalt opened 2 weeks ago

RobWalt commented 2 weeks ago

As far as I can tell this crate is going to have a hard time to upgrade to bevy 0.14.

When impl-ing WorldQuery we're currently relying on the fact that we get world acces in init_state and get_state to init/get the trait registry internally and get the relevant data. The API of WorldQuery changed to only ComponentInitializer or Components respectively.

I'm not seeing any easy way of resolving this, hence I wanted to open this issue for discussion here. Ideas are welcome. I'll try hacking around a bit now 🔧

RobWalt commented 2 weeks ago

Here's some thread I could trace a bit on discord. Let's try to establish a bit of transparency here:

WrongShoe It's because systems can have active borrows on more than one query. To be clear I don't think this usage would cause UB, but we probably shouldn't violate our own safety constraints internally in the engine. Can you make get_state take Components instead of &World? That's how I had it in my original PR

Victoron I see. Looking at all get_state() impls in the engine, it either only accesses Components via component_id(), or doesn't use world at all, so it would be doable. Though since get_state() is a trait method on WorldQuery, I wonder if any user impls use more aspects of World?

Giooschi bevy-trait-query appears to fetch a Resource with it

WrongShoe I don't think this is safe. What if you transmute a trait query and have a ResMut<TraitImplRegistry> in the system? That would have a mutable reference and a shared referece to the reource live at the same time.

Giooschi Well, from the point of view of bevy-trait-query it gets a &World so it's perfectly safe to access that resource.

WrongShoe It's ub, so our api's are incorrect.