2 Commits

Include renames

Author	SHA1	Message	Date
Conrad Irwin	99f85efa71	corgi: Use globs for extra-inputs (#63558) ... Corgi 0.1.43 changes how `[extra-inputs]` in `corgi.toml` is read: entries are glob patterns rather than plain paths, and they select files rather than directories. Handing corgi a bare directory name used to mean "everything under here, hashed as a tree"; now it matches nothing and reports that appending `/**` is the fix. This updates each directory entry accordingly, and rewords the section comment to describe the new rules. The practical gain is that the readable set and the hashed set are now exactly the same set of files. Each matched file is granted to the sandbox individually and hashed under its workspace-relative path, so adding, removing, or renaming a file that a pattern covers changes the package's source hash even when no file's contents changed. Reading a file that no pattern matches is denied rather than silently allowed because it happened to sit inside a granted directory. Three reads that corgi has been denying all along now have entries. `eval_cli`'s build script reads `crates/zed/Cargo.toml`, `gpui_wgpu` includes its WGSL shaders through `include_str!`, and `zed_extension_api` includes its own `wit` tree through `wit_bindgen::generate!`. Each of those units fails on `main` today under `corgi check --workspace`. The last one could not be declared at all until corgi 0.1.43, because `[extra-inputs]` is keyed by package name and this workspace resolves three packages named `zed_extension_api` — the member at 0.8.0 plus published 0.1.0 and 0.7.0 that extensions depend on — so the declaration reached the published copies and failed the workspace-escape check. Corgi now applies extra inputs only to local packages, which is safe because a registry package is hashed as a whole directory and reads its own root freely. `corgi_version` is pinned to 0.1.43 so everyone picks up the matching corgi automatically; older corgi releases cannot read these entries. Testing: - `corgi check --workspace` passes with no failing units, which it did not do before this change. - `corgi build -p zed` links the binary. - `corgi check --workspace --all-targets` goes from 16 failing units to 13. The remaining 13 are pre-existing undeclared reads in test targets (font files under `assets/`, `test_data` fixtures and similar) that this change does not attempt to fix. Release Notes: - N/A	2026-09-01 15:40:02 +00:00
Conrad IrwinandBen Kunkle	72dc742101	Support building with corgi (#63396) ... [corgi](https://github.com/ConradIrwin/corgi) is a cargo-compatible build tool that runs `build.rs` scripts and proc-macros in a sandbox (no network, no ambient env, reads limited to a package's own `.rs` sources unless declared). This makes Zed buildable under it. Cargo builds (dev and release) are unaffected. ### Changes - **`scratch` patch**: patch `scratch` to a small local copy (`corgi-patches/scratch`) that reads `OUT_DIR` at runtime instead of baking it in at compile time. `cxx-build` writes its shared cxxbridge headers into `scratch::path(...)`; upstream returns a single global dir (outside any action's `OUT_DIR`) that the sandbox can't grant, while this patch gives each build script a private, writable dir in its own entry. webrtc-sys is self-contained, so per-crate scratch dirs are sufficient. Kept local rather than a cxx git fork because a git checkout of cxx needs symlink support that Windows cargo CI lacks. - **Dev asset loading**: add `util::dev_fs_embed!` and switch dev-mode `rust_embed` asset sources (`assets`, `settings`, `grammars`, `agent`, `edit_prediction_cli`) to read from the checkout at runtime, locating the repo root by walking from the executable up to the enclosing `.git`. This avoids baking `CARGO_MANIFEST_DIR` into the binary (corgi rejects artifacts that embed the build-time checkout path, and it's wrong in any other worktree). Release builds still embed via `#[derive(RustEmbed)]`. - **Stop baking checkout paths into artifacts**: drop `gpui::GPUI_MANIFEST_DIR`; resolve `../gpui` from `gpui_apple`'s build script; stage the metal shader into `OUT_DIR` before compiling so the `.metallib` records the output dir, not the checkout; resolve the repo root at runtime in `remote` and `inspector_ui` (removing `inspector_ui`'s `build.rs` / `ZED_REPO_DIR`). - **corgi.toml**: declare the pinned tools (`cmake`, prebuilt libwebrtc via `LK_CUSTOM_WEBRTC`), a release-only `ZED_COMMIT_SHA` probe, and the non-`.rs` / cross-package reads each package performs. ### Validation - `corgi check` + `corgi build`, dev and release, for `zed` (plus `cli`, `remote_server`, `ep`) with a warm C++ cache — clean; built binaries embed no checkout path. - `corgi fmt --check`, `corgi clippy`, and `corgi test` on the changed crates (922 tests pass). - `cargo check -p util` locally; relying on CI for the full cargo build/test matrix. ### Notes for the reviewer - Per the repo rule, the first two lines of `README.md` are the review-confirmation marker; remove them before merging (this is what Danger is failing on). - `remote_server` cross-compilation (linux-musl via zigbuild) is not yet covered by `corgi.toml` — host (macOS arm64) only for now. ### Suggested .rules additions Only if the team wants corgi guidance in `.rules` (it recurred several times here): dev builds must not bake the checkout path into artifacts — no `env!("CARGO_MANIFEST_DIR")` or `file!()`-derived absolute paths in library/binary output. Resolve the repo root at runtime via `util::dev_repo_root()` (walks to `.git`), and use `util::dev_fs_embed!` for dev-mode `rust_embed` sources. Release Notes: - N/A --------- Co-authored-by: Ben Kunkle <ben@zed.dev>	2026-08-31 17:37:00 +00:00