fix(build): stop discarding the bindings/javascript release profile - #2296
Merged
Conversation
bindings/javascript/Cargo.toml declares opt-level="z" and lto=true, but the crate is a non-root workspace member, so cargo discarded both and emitted "profiles for the non root package will be ignored" on every invocation. release.yml publishes this crate to npm via wasm-pack, so the shipped .wasm was built speed-optimized and without LTO. Moving the profile to the workspace root was rejected as a fix: it would apply opt-level="z" to all five other members including the t27c compiler. A per-package override cannot carry lto -- cargo errors with "`lto` may not be specified in a `package` profile". Instead bindings/javascript moves from members to exclude, matching the existing treatment of bindings/python and tools/converter. The crate becomes its own workspace root, so cargo honours its profile verbatim and only there. No profile value is changed. Verified: cargo metadata --no-deps --offline stderr goes 384 bytes -> 0 bytes against pristine origin/master, exit 0 both. Binary size and build time were NOT measured (390 MiB free disk); see the Honesty limits in docs/NOW.md. Closes #2295
gHashTag
enabled auto-merge (squash)
August 20, 2026 04:18
Contributor
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2295
The defect
Cargo prints this on every invocation in this workspace, on
mastertoday:bindings/javascript/Cargo.tomldeclaresopt-level = "z"andlto = true.The crate is in the root
membersarray, so Cargo discards both and builds itwith the default release profile (
opt-level = 3,lto = false).release.ymlpublishes that crate to npm withwasm-pack build --target bundler --release, run from inside the cratedirectory — but
wasm-packresolves the enclosing workspace, so the published.wasmhas been built speed-optimized and un-LTO'd.Correction to the premise I was handed
The task that produced this PR described
bootstrap/Cargo.tomlas the cratedeclaring the orphaned profile. That is not true of
master— it is trueof the branch
feat/wave-547/host-heapsort. Onmaster,bootstrap/Cargo.tomlhas no[profile]section at all, and a scan of everyCargo.tomlin the tree finds exactly one member declaring one:bindings/javascript. Cargo's own warning names the same single file. The bugis real; the crate named in the brief was not.
Why the profile was not moved to the workspace root
Moving
[profile.release]verbatim to the root would applyopt-level = "z"to all five other members, including the
t27ccompiler that 8+ workflowsbuild with
cargo build --release -p t27c. That silently size-optimizes thecompiler — a far bigger behavioral change than the bug.
Scoping it per-package at the root is not possible; Cargo rejects it:
lto,panicandrpathcannot appear in a package profile override.The change
One line pair in the root
Cargo.toml:bindings/javascriptmoves frommemberstoexclude, joiningbindings/pythonandtools/converterwhichwere already excluded. The crate becomes its own workspace root, so Cargo
honours its existing
[profile.release]verbatim and only for that crate.No profile value is added, removed or tuned. The
[profile.release]blockin
bindings/javascript/Cargo.tomlis not touched by this PR.Acceptance test — the warning is gone
Same command, same worktree, pristine
origin/master(98c44f6) vs. thisbranch, stderr captured to a file and byte-counted:
Cargo now reports the crate as its own workspace root, which is what makes the
profile apply:
Honesty limits (BINDING)
t27cor the.wasm. Free disk was 390 MiB and this workspace'starget/reaches ~1.1 GiB, so no release build was attempted. I have notdemonstrated that the published
.wasmgets smaller — only that Cargo nowhonours the profile it previously discarded. Someone with disk should run
wasm-pack build --target bundler --releaseinbindings/javascriptbeforeand after and record both
.wasmsizes.Cargo.lock, and this PR does not add one forbindings/javascript, so itsdependencies resolve freshly at release time and it leaves workspace-wide
cargo build/cargo testcoverage from the root. Nothing in CI depended oneither (
release.ymlcds into the crate; no workflow greps for a cleantree), but unpinned resolution for a published npm artifact is a real gap,
recorded rather than silently accepted.
Files
Cargo.toml— membership only, no profile valuesdocs/NOW.md— new entry at top,Last updated: 2026-08-20, append-only(numstat
134 0)