# Wasm32 linker flags applied to every `cargo build --target
# wasm32-unknown-unknown` (and `wasm-pack build`) invocation in this
# workspace.
#
# `-zstack-size=8388608` — 8 MiB stack. The default lld wasm stack is
# 1 MiB; the holtburger-session recv loop's `recv_ordered_packet`
# holds two 128 KiB UDP buffers across `.await` points, and on top of
# that the future state machine for the full client-message dispatch
# pipeline accumulates several KiB of locals at each `.await`
# boundary. The combined footprint overflowed the 1 MiB default
# during normal login (CONNECT_REQUEST → CONNECT_RESPONSE → first
# CharacterList), surfacing as `RuntimeError: memory access out of
# bounds` at `holtburger_session::session::receive::Session::
# recv_message::{{closure}}` (verified via CDP probe in K.1
# validation on 2026-05-17). 8 MiB is enough headroom for the
# foreseeable future without inflating the binary; the stack lives
# in wasm linear memory and is allocated lazily by the engine.
[target.wasm32-unknown-unknown]
rustflags = ["-C", "link-arg=-zstack-size=8388608"]

# Cap parallel codegen on this 8GB laptop. cargo defaults to jobs = nproc (4
# here); each rustc + its LLVM codegen threads is multi-hundred-MB to >1GB on
# this graph (tokio "full", reqwest/hyper, web-sys, the 40k-line lib.rs), so 4
# concurrent froze the box. jobs=2 keeps peak build RAM to ~2-3G, leaving room
# for the wasm-opt fork and one headless chrome. Override per-invocation with
# `cargo build -j N` or CARGO_BUILD_JOBS when you know there's headroom.
[build]
jobs = 2
