bug - Toolchain archive omits stdlib sources for zero-clone starter tests

[dannymeijer]

Thanks for reporting! Please include a minimal reproduction when possible.

Area

• Tooling (CLI/formatter/test runner)
• Runtime / Core crates (stdlib/core/derive)

Summary

Expected: a released toolchain install should include all stdlib source files needed by zero-clone starter projects, so incan new hello, incan run, incan test, and incan build --release work outside a source checkout.

Actual: the v0.4.0-rc3 toolchain archive installs incan and incan-lsp, but incan test cannot load std.testing because stdlib/testing.incn is not present in the installed toolchain layout. The archive packager currently copies only bin/incan and bin/incan-lsp into the release archive, while runtime stdlib lookup expects an installed stdlib source root through installed layouts or INCAN_STDLIB_PATH.

Reproduction steps

1. Install Incan v0.4.0-rc3 from the GitHub release toolchain archive on a clean machine.
2. Ensure the installed incan is on PATH.
3. Run:

workdir="$(mktemp -d)"
cd "$workdir"

incan new hello --yes
cd hello

incan run
incan test
incan build --release

Output / logs

Created project 'hello' at hello

  src/main.incn          Entry point
  tests/test_main.incn   Starter test
  incan.toml             Project manifest

Run it:     incan run
Test it:    incan test
Release it: incan build --release

Cannot resolve source file for 'std.testing'; expected 'stdlib/testing.incn' under stdlib search roots.
Error parsing ./tests/test_main.incn: Failed to load std.testing marker semantics: could not locate std.testing source at relative path `stdlib/testing.incn`

The release packager currently stages only command binaries:

bin/incan
bin/incan-lsp

The installed package should also provide the stdlib source layout required by the runtime loaders, or set a packaged stdlib root consistently during installation.

Environment

OS: macOS
Rust: stable Rust installed by the v0.4 toolchain installer
Incan: 0.4.0-rc3
Command: incan new hello --yes, then incan run, incan test, and incan build --release

[dannymeijer]

Fixed on release/v0.4 in bea1e0af (bugfix - 809 package toolchain support sources).

Root cause: the v0.4.0-rc3 toolchain archive carried only bin/incan and bin/incan-lsp. That broke two zero-clone install contracts:

• stdlib source loaders could not find stdlib/testing.incn, so incan test failed for starter projects.
• generated Cargo manifests still resolved toolchain-owned Rust crates such as incan_stdlib, incan_core, and incan_derive through the compiler build checkout path instead of an installed toolchain path.

Fix:

• package the stdlib source tree plus a minimal installed support-crate workspace under the toolchain archive;
• resolve generated-project support crate paths from the installed executable layout before falling back to the source checkout layout;
• validate required stdlib/support-crate files during install;
• keep Homebrew's formula layout under libexec so the binaries stay next to bundled support files;
• extend the local release smoke to run incan new, incan run, incan test, and incan build --release from the installed archive.

Verification:

cargo fmt --check
cargo test --test toolchain_installer_tests -- --nocapture
cargo test -p incan --lib backend::project::cargo_toml -- --nocapture
TOOLCHAIN_DIST=/private/tmp/incan-809-local-test make toolchain-release-package toolchain-release-assets toolchain-release-smoke-direct
TOOLCHAIN_DIST=/private/tmp/incan-809-local-test make toolchain-release-smoke-homebrew
cargo test --test integration_tests zero_clone_starter_project_runs_tests_and_release_builds -- --nocapture
git diff --check

The packaged starter smoke now builds against installed support crates under the toolchain directory and passes run, test, and build --release.

[dannymeijer]

rc4 exposed one remaining #809 path: direct installs run through the user-facing symlink in the chosen bin dir, and on macOS the stdlib/testing marker path can see that symlink path instead of the real toolchain root. I pushed a follow-up to release/v0.4 in 6efa5905, followed by CI rerun commit eabcc960, that routes executable-relative lookups through a shared layout helper which checks both the reported executable path and its canonical target. This covers stdlib source lookup, frontend stdlib loading, and generated Cargo support-crate paths. I also updated the direct release smoke to exercise the symlinked launcher path and bumped the candidate to 0.4.0-rc5. Local verification passed: cargo fmt --check, make rustdoc-gate-ci, cargo test -p incan toolchain_layout -- --nocapture, cargo test --test toolchain_installer_tests -- --nocapture, cargo test --test integration_tests zero_clone_starter_project_runs_tests_and_release_builds -- --nocapture, git diff --check, and TOOLCHAIN_DIST=/private/tmp/incan-809-rc5-local-test make toolchain-release-build toolchain-release-package toolchain-release-assets toolchain-release-smoke-direct with the network-enabled rerun for Cargo index access. The direct smoke now runs incan new, incan run, incan test, and incan build --release from the installed symlinked launcher. v0.4.0-rc5 is published as a prerelease with GitHub assets, npm, and PyPI jobs green.

[dannymeijer]

Closing as completed for v0.4. The installed-toolchain stdlib packaging path was fixed after the rc3 failure, and RC8 has been validated from the published toolchain package: zero-clone npm install reached incan 0.4.0-rc8, incan new hello --yes created the starter, incan run printed the starter greeting, incan test passed 1 test, and incan build --release completed successfully. The Homebrew tap formula was also updated to install the bundled stdlib through libexec.