If you're lucky, you don't need to change anything. However, some users may experience issues with their path length. If that happens, move your crate closer to your drive, e.g. C:\my_crate. If that is not enough, set the following in your ~\.cargo\config.toml:

[profile.dev]
codegen-units = 1

Note that this may increase compile times significantly if your crate is very large. When changing this number, always run cargo clean before rebuilding. If you can verify that this solved your issue, try increasing this number until you find a happy middle ground. For reference, the default number for incremental builds is 256, and for non-incremental builds 16.

You also cannot set linker = "rust-lld.exe", as subsecond currently crashes when linker is set.

You're in luck! Everything should work out of the box if you use the default system linker.

Execute the following:

readlink -f "$(which cc)"

If this points to clang, you're good. Otherwise, we'll need to symlink it. Read the path returned by the following command:

which cc

and cd into it. For example,

$ which cc
/usr/bin/cc
$ cd /usr/bin

Assuming you have clang installed, run the following commands:

mv cc cc-real
ln -s "$(which clang)" cc

Note that the above commands may require sudo.

Now everything should work. If not, install lld on your system and add the following to your ~/.cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
rustflags = [
  "-Clink-arg=-fuse-ld=lld",
]

If you prefer to use mold, you can set it up like this:

[target.x86_64-unknown-linux-gnu]
#linker = clang
rustflags = [
  "-Clink-arg=-fuse-ld=mold",
]

Note that the linker key needs to be commented out. You will also need to replace your system ld with mold.

cd /usr/bin
sudo mv ld ld-real
sudo ln -s mold ld

On NixOS you can do this in a shell by replacing:

pkgs.mkShell {
    # ..
}

with:

pkgs.mkShell.override {
    stdenv = pkgs.stdenvAdapters.useMoldLinker pkgs.clangStdenv;
} {
    # ..
}

"rust-analyzer.procMacro.ignored": {
    "bevy_simple_subsecond_system_macros": [
        "hot"
    ]
},
"rust-analyzer.diagnostics.disabled": [
    "proc-macro-disabled"
]

lspconfig.rust_analyzer.setup({
  capabilities = capabilities,
  settings = {
    ["rust-analyzer"] = {
      procMacro = {
        ignored = {
          bevy_simple_subsecond_system_macros = { "hot" },
        },
      },
      diagnostics = {
        disabled = { "proc-macro-disabled" },
      },
    },
  },
})

• Annotating a function relying on local state will clear it every frame. Notably, this means you should not use #[hot(rerun_on_hot_patch)] or #[hot(hot_patch_signature)] on a system that uses any of the following:
  • EventReader
  • Local
  • Queries filtering with Added, Changed, or Spawned
• Some signatures are not supported, see the tests. Some have #[hot(rerun_on_hot_patch)] or #[hot(hot_patch_signature)] commented out to indicate this
• All hotpatched systems run as exclusive systems, meaning they won't run in parallel
• For component migration:
  • While top level component definitions can be changed and renamed (and will be migrated if using HotPatchMigrate), changing definitions of the types used as fields of the components isn't supported. It might work in some cases but most probably will be an undefined behaviour

UI is often spawned in Startup or OnEnter schedules. Hot-patching such setup systems would be fairly useless, as they wouldn't run again. For this reason, the plugin supports automatically rerunning systems that have been hot-patched. To opt-in, replace #[hot] with #[hot(rerun_on_hot_patch = true)]. See the rerun_setup example for detailed instructions.

Replace #[hot] with #[hot(hot_patch_signature = true)] to allow changing a system's signature at runtime. This allows you to e.g. add additional Query or Res parameters or modify existing ones.