If that happens, move your crate closer to your drive, e.g. C:\my_crate.

If that is not enough, create or edit either a global ~\.cargo\config.toml or a local .\.cargo\config.toml with this config:

[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.

Create or edit either a global ~/.cargo/config.toml or a local ./.cargo/config.toml with this minimal config

[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = [
  "-C",
  "link-arg=-fuse-ld=lld",
]

⚠️ WARNING In the past we recommended symlinking mold over /usr/bin/ld Please make sure to undo this to avoid issues with your installation cause by incompatibilities, such as DKMS failing to load modules

• Use nightly Rust
• Install mold and clang through your package manager
• Install cranelift with rustup component add rustc-codegen-cranelift-preview --toolchain nightly
• Put the following config in your global ~/.cargo/config.toml or local ./.cargo/config.toml:

[unstable]
codegen-backend = true

[profile]
incremental = true

[profile.dev]
codegen-backend = "cranelift"
debug = "line-tables-only"

[profile.dev.package."*"]
codegen-backend = "llvm"

[profile.test.package."*"]
codegen-backend = "llvm"

[profile.release]
codegen-backend = "llvm"

[profile.web]
codegen-backend = "llvm"

[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = [
  "-Clink-arg=-fuse-ld=mold",
  "-Zshare-generics=y",
  "-Zthreads=8",
]

If you run into trouble, replace mold with lld.

This repo also includes ./.cargo/config_faster_builds.toml which contains more advanced compile-time improving configs known to work with subsecond.

"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.