Fix cargo install --locked wasixcc, release 0.4.5

[Arshia001]

Fixes #72.

What was wrong

.cargo/config.toml was committed, so cargo auto-discovered the WASIX overlay registry on every invocation. Cargo source replacement records the replaced source id, so Cargo.lock ended up pinning 14 X.Y.Z+wasix.N versions that claim to come from crates.io and don't exist there.

The lockfile ships inside the published .crate, and cargo install doesn't read the repo's cargo config — hence the reported failure. Two more consequences of the same cause:

• cargo vendor breaks for downstream consumers (this is what blocks wasinix).
• The 6 native release tarballs were being built against forked libc/ring/rustix/cc/tokio without anyone intending it.

For the record: the published 0.4.3 lock has 0 +wasix entries, 0.4.4 has 20.

On "why do we need wasix patches in the first place?"

LLVM does run inside WASIX — wasmer.toml depends on wasmer/clang and sets WASIXCC_LLVM_LOCATION=/, so wasmer run wasmer/wasixcc is a self-contained WASIX-native C/C++ toolchain and the driver itself has to be a wasm32-wasmer-wasi module. So the target is real.

But that doesn't justify the fork set we had. 10 of the 14 forks existed only because src/download.rs pulls reqwest + rustls + ring + tokio/mio/socket2/h2/hyper — and downloading is dead code inside the Wasmer package, where clang and the sysroot come from wasmer/clang. Only libc/rustix/getrandom (via tempfile/std) are unavoidable.

Changes

• wasix/registry.toml — the overlay config, moved out of .cargo/ and passed explicitly with cargo --config by the Makefile. /.cargo/ is gitignored.
• Makefile — make wasix swaps Cargo.wasix.lock in around cargo wasix build and restores the crates.io lock via trap, even on Ctrl-C. Sets CARGO_WASIX_NO_REGISTRY_CONFIG=1 so cargo-wasix can't re-write .cargo/config.toml behind our back, and refuses to run if one reappears. make wasix-package also handles the wasixccenv.wasm → wasixcc.wasm name wasmer.toml expects (previously a manual rename).
• Cargo.wasix.lock — committed. The overlay serves exactly one version of some crates (cc 1.2.27+wasix.1, reqwest 0.12.22+wasix.1) and hides upstream for forked crates, so unlocked WASIX resolution is one upstream bump away from a cryptic failure.
• download feature (default-on) — gates the entire download stack; the WASIX build uses --no-default-features.
• Dependency diet — dropped regex, getrandom, tower, tower-layer, tower-service (zero uses in src/), and stopped rustls' default features from compiling ~18 MB of aws-lc-sys that download.rs never calls (it installs the ring provider explicitly).
• CI — new lockfile-hygiene job: no tracked cargo config, no +wasix in Cargo.lock, cargo metadata --locked, plus a --no-default-features check. Release builds and publishes with --locked behind a pre-publish guard.
• Version bumped to 0.4.5 in Cargo.toml, wasmer.toml and installer/public/install.sh.

Verification

• cargo build/test --locked — 87 tests pass; both feature configurations compile.
• cargo tree -i aws-lc-sys — no longer in the graph.
• cargo package --locked verification build passes, and the embedded Cargo.lock has 0 +wasix entries.
• Extracted the resulting .crate and ran cargo install --locked on it — succeeds, i.e. the exact failure in cargo install --locked wasixcc fails #72 is gone.
• cargo vendor works again (175 crates).
• make wasix builds the module, leaves Cargo.lock untouched, and the module runs under wasmer (wasixcc 0.4.5).
• Compiled and ran a C hello-world with the native binary.
• Planted a .cargo/config.toml and confirmed make wasix refuses to run.

After merging

Tag v0.4.5, then cargo yank --version 0.4.4 wasixcc — after 0.4.5 is live, not before: 0.4.4 still installs fine without --locked and is the only 0.4.x with the recent compiler fixes.

Note the lock regeneration moves several deps in one hop (tokio 1.47→1.53, libc 0.2.183→0.2.186, clap 4.5→4.6), all semver-compatible. Worth letting the toolchain-test matrix cover macOS/arm before tagging.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes cargo install --locked wasixcc failures by preventing the WASIX overlay registry configuration from “poisoning” the published Cargo.lock, while keeping WASIX builds reproducible via an explicit opt-in config and a separate WASIX lockfile.

Changes:

• Move WASIX overlay registry config out of .cargo/ into wasix/registry.toml, applied explicitly for WASIX builds (via cargo --config).
• Introduce a download feature (default-on) to gate the download/TLS stack; WASIX builds use --no-default-features.
• Add Makefile targets and CI checks to enforce lockfile hygiene and use --locked consistently in release/build workflows.

Reviewed changes

Copilot reviewed 13 out of 16 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
wasmer.toml	Bumps published Wasmer package version to 0.4.5.
wasix/registry.toml	Adds explicit opt-in WASIX overlay registry config.
src/wasixccenv.rs	Gates download subcommands/exports behind the download feature.
src/main.rs	Compiles the download module only when the download feature is enabled.
src/args.rs	Adjusts user-facing LLVM/binaryen hints based on download feature.
README.md	Documents native and WASIX build flows and the overlay/lockfile rationale.
Makefile	Adds make wasix* targets and guardrails to keep overlay opt-in.
installer/public/install.sh	Bumps installer version to 0.4.5.
Cargo.wasix.lock	Adds a dedicated lockfile intended for WASIX overlay builds.
Cargo.toml	Bumps version and introduces download feature + optional download deps.
Cargo.lock	Regenerates crates.io lockfile without +wasix overlay versions.
.gitignore	Ignores /.cargo/ and the Makefile’s scratch lock backup.
.github/workflows/release.yml	Adds a pre-publish guard and publishes with --locked.
.github/workflows/pr-checks.yml	Adds a lockfile-hygiene job and checks --no-default-features.
.github/workflows/build-release-bundle.yml	Builds release artifacts with --locked.
.cargo/config.toml	Removed to stop implicit overlay application and lockfile poisoning.

Suppressed comments (1)

src/args.rs:84

• Same formatting issue as the LLVM warning: the \ line continuation causes {} to be concatenated without whitespace, producing ... Output may be broken.Use ... in logs. Add a space (or newline) before the continuation.

                        default path. Using system binaryen. Output may be broken.\

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.