Subsecond fails to pick up new symbols on Windows

[stefnotch]

Problem

On Windows systems, a subsecond::call(my_hot_fn) call can fail to pick up on the new my_hot_fn if its return type changes.

Steps To Reproduce

Start with code like the following

fn main() {
    dioxus_devtools::connect_subsecond();
    loop {
        subsecond::call(hot_tick);
        std::thread::sleep(Duration::from_millis(500));
    }
}
fn hot_tick() -> f64 {
    println!("Initial state");
    3.
}

Then run it with dx serve

This will print "Initial state" over and over again in the console.
You can now edit the println! to anything like println!("Something else");. This will change what is printed.

To reproduce the bug, edit the hot_tick function to

fn hot_tick() -> u64 {
    println!("Please update");
    3
}

On Windows, and probably Windows alone, this will cause the hot function to revert back to the initial one. It will now print "Initial state" again.

Expected behavior

It should print "Please update" in the console.

Fixing it

The future is bright and it contains more Rust! For some reason, switching to the v0 mangling scheme by adding this to .cargo/config.toml solves the issue

[build]
rustflags = ["-Csymbol-mangling-version=v0"]

The nicest experience would probably be if Dioxus automatically added that rustflag on Windows and documented this behaviour? The second best option would be if Dioxus warned me about Windows screwery and told me to do that.

Screenshots

Environment:

• Dioxus version: dioxus 0.8.0-alpha.0 (3464af7) and the corresponding version of subsecond
• Rust version: rustc 1.96.0 (ac68faa20 2026-05-25)
• OS info: Windows 11
• App platform: Desktop