rksm / hot-lib-reloader-rs

Reload Rust code without app restarts. For faster feedback cycles.
MIT License
577 stars 21 forks source link

TypeId changes after first reload. #34

Closed All8Up closed 6 months ago

All8Up commented 8 months ago

This is an interesting issue which took a while to figure out. While using an ECS which utilizes TypeId to figure out the component types during queries, I ran into the TypeId changing after the first reload. The behavior was so arbitrary and odd though because in one function it changed but another it did not which left me going "HUH" for a day trying to figure it out. So, long bug hunt later, this is what I found and you might want to double check and perhaps document it:

In the 'spawning' function which creates the initial entities, I had something along the lines of:

use crate::ExampleComponent;

[no_mangle]

pub fn setup() -> Result<()> { let world = ...blah blah...; world.spawn((ExampleComponent {counter: 0},)); }

The above produces a stable type id and nothing is wrong there. But later I had a function which was serializing things between reloads:

[no_mangle]

pub fn before_reload() -> Result<()> { use crate::ExampleComponent;

let query = world.query::<&ExampleComponent>()?; ... do serialization ... }

During the initial run before a reload, this all works just fine. But after reload the TypeId is different.

Long story short, move the 'use' function out of the reloaded function and everything is fine and it's stable. After the first reload though, the in function 'use' will be different.

To prevent others from having to track down this goofy behavior this should be documented somewhere perhaps? It certainly had me going in circles with the different behaviors.

rksm commented 6 months ago

Thank you for this note! I have added a reference to this issue to the readme. I really wish Rust would add support for the hot reloading use case proper.