`crates/benchmarks/Cargo.toml` requested `settings`'s `test-support` feature directly so `display_map.rs`, `editor_render.rs`, and `markdown_renderer.rs` could each call `SettingsStore::test` to build the global `SettingsStore` they render against. `test-support` is a much wider surface than that one call needs: it also enables `gpui/test-support` and `fs/test-support`, and (per `settings`'s own crate) exposes settings-file mutation APIs meant for interactive tests, not benchmarks. This removes that direct edge by giving `settings` a narrow `benchmarks` feature that exposes exactly the initializer these three benchmarks need, with the same settings content as before.
`settings::src::settings_file.rs` already built its `test_settings()` content (default settings overridden with a deterministic monospace font, `empty-theme`, and `format_on_save: on`) entirely from production APIs (`default_settings()`, `parse_json_with_comments`, `util::merge_non_null_json_value_into`); the only reason it needed `test-support` was the `#[cfg(...)]` gate on the function itself. I extracted that body into a private `deterministic_font_and_theme_settings()` helper and added a sibling `benchmark_settings()` accessor that calls the same helper, gated on `feature = "benchmarks"` instead. `SettingsStore` gets a matching `SettingsStore::benchmarks(cx)` constructor next to `SettingsStore::test`, built the same way from `benchmark_settings()`. `settings`'s new `benchmarks = []` feature enables nothing else, so it cannot re-enable `gpui/test-support` or `fs/test-support` transitively, and it exposes no mutation API (`update_user_settings` stays gated to `test`/`test-support` only).
Because `benchmark_settings()` and `test_settings()` call the exact same helper function, their content is guaranteed byte-identical rather than merely intended to match, so switching `display_map`/`editor_render`/`markdown_renderer` over does not change the font, size, or theme fallback those benchmarks measure. I confirmed this is a true no-op for the theme in particular: `empty-theme` is never registered under the `LoadThemes::JustBase` these benchmarks use, so `theme_settings::configured_theme` already fell back silently to the same default theme it would use for any unrecognized name; only the font settings (Courier/Courier New at 14px) are load-bearing, and those are now sourced identically to before. `crates/settings/src/settings_store.rs` gains a `#[cfg(feature = "benchmarks")]` test, `test_benchmark_settings_match_test_settings`, that asserts the string equality directly and reads back `buffer_font_family`/`buffer_font_size`/`ui_font_family`/`ui_font_size`/`theme` from a real `SettingsStore::benchmarks(cx)` to confirm the representative settings a rendering benchmark reads still resolve as expected.
`crates/benchmarks/Cargo.toml` now requests `settings`'s `benchmarks` feature instead of `test-support`, and the three bench files call `SettingsStore::benchmarks(cx)` instead of `SettingsStore::test(cx)` — their only change. `cargo tree -p benchmarks --edges features --invert settings` before this change showed `benchmarks` as a direct dependent of `settings feature "test-support"`; after this change that direct edge is gone, and `benchmarks` instead is a direct dependent of `settings feature "benchmarks"`.
`settings/test-support` is not fully gone from `benchmarks`' resolved graph, and cannot be in this scope: `language/test-support` (needed directly by `markdown_renderer.rs`'s `LanguageRegistry::test`/`language::rust_lang`, with no production equivalent) enables `settings/test-support` itself, so it still resolves transitively through `language`. This is the same shape as the existing `theme`/`util` debt this script already tracked, so I folded `settings` into that same loop (`for foundational_crate in theme util settings`) instead of inventing a new check shape, and updated its comments to describe `language`/`multi_buffer` as the remaining crates keeping `test-support` populated in the graph. I also added a second, positive assertion that `benchmarks` still resolves `settings feature "benchmarks"`, so a future edit can't silently drop that feature request and have these three benchmarks start reading unrelated plain-default settings without any isolation check catching it. `edit_file_tool_benchmarks` (the sibling package `edit_file_tool.rs` lives in, added in #63048) is unchanged and explicitly excluded from all of this: it still needs `settings/test-support` for `SettingsStore::update_user_settings`, which has no production-capable equivalent for mutating already-loaded settings content, and the script's existing sanity check for that package's continued existence is untouched.
Testing performed:
- `cargo tree -p settings --no-default-features --features benchmarks -e no-dev --edges features`: no `test-support` edge anywhere, confirming the `benchmarks` feature alone enables nothing test-only.
- `cargo tree -p benchmarks --edges features --invert settings` before/after: the direct `test-support` edge from `benchmarks` is gone; only the transitive edge through `language feature "test-support"` remains. A direct edge to `settings feature "benchmarks"` is now present instead.
- `cargo check -p settings --no-default-features --features benchmarks`: compiles cleanly standalone.
- `cargo test -p settings --lib` (default features) and `cargo test -p settings --features benchmarks --lib`: 32 and 33 tests pass respectively, including the new `test_benchmark_settings_match_test_settings`.
- `cargo check -p benchmarks --benches` and `cargo check -p edit_file_tool_benchmarks --benches`: both compile cleanly.
- `cargo bench -p benchmarks --bench display_map/--bench editor_render/--bench markdown_renderer -- --test` (quick mode): all cases across all three targets report Success, including the headless-renderer-backed `editor_render`/`markdown_render` cases.
- `script/check-gpui-bench-feature-isolation`: passes; manually confirmed it fails (correctly) when `settings`'s Cargo.toml entry is reverted to `test-support` and separately when its `benchmarks` feature request is dropped entirely.
- `script/shellcheck-scripts` and `cargo fmt --check` (whole repo) both pass.
- `./script/clippy -p settings -p benchmarks -p edit_file_tool_benchmarks` (release, all features, deny warnings) passes, including `cargo shear --locked --deny-warnings`.
Remaining debt, tracked honestly rather than hidden: `language` and `multi_buffer` still request `test-support` directly (for `LanguageRegistry::test`/`language::rust_lang` and `MultiBuffer::build_simple`/`build_random`, none of which have a production equivalent), which keeps `settings/test-support` and `gpui/test-support` resolved transitively in `benchmarks`' graph regardless of this change. `edit_file_tool_benchmarks` is unaffected and continues to depend on `test-support` from `agent`, `editor`, `language`, `language_model`, `lsp`, `project`, and `settings` for its fake-project agent-tool harness, as documented since #63048.
Release Notes:
- N/A
crates/benchmarks/Cargo.toml requested test-support directly from seven
application crates (agent, editor, language, language_model, lsp, project,
settings) so its edit_file_tool.rs bench could drive the agent's edit-file
tool through TestAppContext, FakeFs, FakeLspAdapter, FakeLanguageModel, and
Project::test. Because Cargo unifies features per package, those test-only
builds applied to the whole benchmarks package, including display_map.rs,
editor_render.rs, and markdown_renderer.rs, which render production code
paths and have no inherent need for most of that test-only surface.
This moves edit_file_tool.rs into a new sibling package,
edit_file_tool_benchmarks (crates/edit_file_tool_benchmarks), with its own
Cargo.toml requesting exactly the dependencies and test-support features
that one benchmark needs. It reuses benchmarks::bench_utils (for
random_rust_file/rust_identifier/rust_file_line_count) via a plain
workspace dependency on benchmarks rather than duplicating that generator,
since bench_utils itself needs no test-support feature. The bench file's
content, name, and behavior are unchanged; only its package changed, so
`cargo bench -p edit_file_tool_benchmarks --bench edit_file_tool` replaces
`cargo bench -p benchmarks --bench edit_file_tool`.
With edit_file_tool.rs gone, crates/benchmarks/Cargo.toml drops its direct
test-support edges to agent, editor, language_model, and project entirely:
`cargo tree -p benchmarks --edges features --invert <crate>` now shows none
of those four anywhere in the graph, not merely as a direct edge (agent and
language_model aren't dependencies of benchmarks at all any more).
Two edges do not go away, and this is a real finding, not an oversight:
- settings/test-support remains, because display_map.rs, editor_render.rs,
and markdown_renderer.rs all call SettingsStore::test directly to build a
global settings store for their benchmarks, independent of
edit_file_tool. This also keeps gpui/test-support resolved (settings'
test-support feature enables it directly), which is what display_map.rs's
direct use of TestAppContext/TestDispatcher relies on.
- language/test-support remains, because markdown_renderer.rs calls
LanguageRegistry::test and language::rust_lang directly to build a
language registry for its Markdown benchmark, also independent of
edit_file_tool. language's test-support feature enables lsp/test-support,
so lsp/test-support still resolves transitively too, despite benchmarks
no longer depending on lsp directly at all.
- multi_buffer/test-support is now a new *direct* edge (it used to resolve
only transitively through editor's test-support): display_map.rs and
editor_render.rs call MultiBuffer::build_simple/build_random, which are
only compiled under multi_buffer's own test-support feature, with no
production equivalent.
None of this is edit_file_tool-specific, so moving that one benchmark out
cannot remove it without changing what display_map/editor_render/
markdown_renderer actually exercise (e.g. swapping SettingsStore::test for
settings::init would change the settings values feeding those benchmarks).
That is out of scope here.
script/check-gpui-bench-feature-isolation gains a check that walks the whole
resolved graph (not just a direct edge, since nothing else in benchmarks has
a legitimate reason to reach test-support through any of them) for agent,
editor, language_model, and project, confirming they are fully absent from
benchmarks' test-support surface now that edit_file_tool moved out. The
existing theme/util direct-edge check gains updated comments reflecting
that language, multi_buffer, and settings are the crates still populating
the graph, and the script gains a sanity check that
edit_file_tool_benchmarks still exists and resolves, documenting rather than
hiding its continued test-support dependency.
Validation performed:
- `cargo check -p benchmarks -p edit_file_tool_benchmarks --benches`: both
packages compile cleanly together.
- `cargo bench --offline -- --test` (quick mode) for all four bench
targets: display_map, editor_render, and markdown_renderer under
benchmarks, and edit_file_tool under edit_file_tool_benchmarks. All cases
report Success with the same benchmark names/groups as before the split.
- `cargo tree -p benchmarks --edges features` before/after comparison
confirms agent, editor, language_model, and project are gone from the
graph entirely, while language, multi_buffer, and settings remain for the
reasons above.
- `script/check-gpui-bench-feature-isolation` passes; manually confirmed it
fails (correctly) when a test-support edge to agent is reintroduced.
- `cargo shear --locked`: no unused dependencies in either package.
- `cargo fmt --check` (whole repo) and `./script/clippy -p benchmarks -p
edit_file_tool_benchmarks` (deny warnings) both pass.
- `bash script/shellcheck-scripts` and `bash script/check-licenses` both
pass for the modified/new files.
Remaining test-support debt, tracked honestly rather than hidden:
edit_file_tool_benchmarks still depends on test-support from agent, editor,
language, language_model, lsp, project, and settings, unchanged from before
this split. This PR only isolates that dependency to its own package so it
stops contaminating the three production-rendering benchmarks; giving
edit_file_tool_benchmarks a production-capable harness (or accepting it as
a permanently test-shaped benchmark) is future work.
Release Notes:
- N/A
crates/benchmarks/Cargo.toml requested test-support directly from eight
application crates (agent, editor, language, language_model, lsp, project,
settings, theme, util) to build fixtures its benches exercise. This trims
two of those: theme and util no longer need a direct test-support edge from
benchmarks.
theme needed no test-only API at all. The two benchmark-visible calls
(theme::LoadThemes::JustBase and theme_settings::init) are both plain
production APIs; theme's test-support feature only gates
ThemeRegistry::register_test_themes/register_test_icon_themes, which no
bench uses. Declaring theme's test-support in benchmarks' manifest was
already a no-op edge.
util needed exactly one test-only API: util::RandomCharIter, a synthetic
multi-byte-aware text generator used by the display_map and editor_render
benches to build random buffer contents. It has no production analogue (it
exists purely to generate adversarial test/benchmark input), so rather than
inventing a production-capable substitute, this vendors an equivalent
generator into benchmarks::bench_utils::RandomCharIter, matching the
existing precedent of benchmarks::bench_utils::random_rust_file for
markdown_renderer. Both benches now import it from there instead of util.
settings, agent, editor, language, language_model, lsp, and project remain
untouched and cannot be trimmed further in this scope:
- edit_file_tool.rs (the one bench target this PR leaves alone) calls
SettingsStore::update_user_settings, which only exists under
cfg(any(test, feature = "test-support")) with no production equivalent for
mutating already-loaded settings content, plus TestAppContext, FakeFs,
FakeLspAdapter, FakeLanguageModel, and Project::test: a deeply test-double
harness for benchmarking the agent's edit-file tool against a fake
project. None of that has a narrow production-capable substitute; building
one is the "larger architectural change" out of scope for this PR.
- Because edit_file_tool.rs stays in the same benchmarks package as the
other three bench targets, Cargo's feature unification means settings
(and by extension agent/language/language_model/lsp/project) stay enabled
with test-support for the whole package regardless of what the other three
targets need on their own.
- theme and util's test-support features still resolve elsewhere in the
benchmarks dependency graph after this change, because editor's own
test-support feature (needed for edit_file_tool.rs, editor_render.rs, and
display_map.rs, and out of scope here) requires theme/test-support and
util/test-support directly, independent of anything benchmarks itself
requests. This PR only removes the edge it controls: benchmarks' own
direct request.
Before this change, `cargo tree -p benchmarks --edges features --invert
theme` (and the `util` equivalent) showed a direct
`[dev-dependencies] -> benchmarks` edge into each crate's `test-support`
feature, alongside the pre-existing indirect edge through `editor`. After
this change, only the indirect edge through `editor` remains; benchmarks
itself no longer requests either crate's `test-support`.
script/check-gpui-bench-feature-isolation gains a check for this: for
`theme` and `util`, it walks `cargo tree -p benchmarks --edges features
--invert <crate>` and fails if `benchmarks` appears as a direct dependent of
that crate's `test-support` feature. Unlike the existing gpui/gpui_platform
checks in this script, it can't assert `test-support`'s total absence from
the graph, since `editor`/`project` (out of scope) keep it resolved
regardless; it specifically targets the one edge this change controls.
Validation performed:
- `cargo check -p benchmarks --benches`: clean, no warnings.
- `cargo build -p benchmarks --benches` and `--release`: all four bench
targets (display_map, edit_file_tool, editor_render, markdown_renderer)
compile.
- `cargo bench -p benchmarks --bench display_map` and `--bench
editor_render` (quick mode): both run successfully, including the
"unicode" display_map case that exercises multi-byte text from the
vendored RandomCharIter.
- `cargo tree` before/after comparison for `benchmarks` against `theme` and
`util` confirms the direct edge is gone.
- `script/check-gpui-bench-feature-isolation` passes; manually confirmed it
fails (correctly) against the prior Cargo.toml.
- `cargo fmt --check` (whole repo) and `./script/clippy -p benchmarks
--benches` (deny warnings) both pass.
Remaining edges out of scope, in one place: `crates/benchmarks/Cargo.toml`
still requests test-support directly from agent, editor, language,
language_model, lsp, project, and settings. All of them are load-bearing for
edit_file_tool.rs's fake-project agent-tool harness (or, for settings,
blocked by that same target's use of a genuinely test-only settings-mutation
API), which would need a larger, separate rework to give it a
production-capable path.
Release Notes:
- N/A
This mirrors the prior gpui-level fix (#63039, "gpui: Stop bench
feature from pulling in test-support") one layer down, in the platform
split crates that back gpui on macOS.
`crates/benchmarks` previously requested `gpui_platform`'s
`test-support` feature just to reach `current_headless_renderer()`, the
real Metal-backed headless renderer used by `#[gpui::bench]` consumers
to render scenes without a window. That feature also enables
`gpui_platform`'s and `gpui_macos`'s and `gpui_apple`'s interactive
test-double code, none of which a benchmark should compile alongside
its production code.
Each platform crate now exposes a narrower `bench` feature alongside
its existing `test-support` feature:
- `gpui_apple`: `bench = ["gpui/bench"]` gates the same headless Metal
renderer APIs (`MetalHeadlessRenderer`, `render_scene`,
`render_scene_to_image`, and their supporting state) under
`cfg(any(test, feature = "test-support", feature = "bench"))` instead
of only `cfg(any(test, feature = "test-support"))`.
- `gpui_macos`: `bench = ["gpui/bench", "gpui_apple/bench"]` re-exports
`MetalHeadlessRenderer` under the same widened cfg.
- `gpui_platform`: `bench = ["gpui/bench", "gpui_macos/bench"]` gates
`current_headless_renderer()` under
`cfg(any(feature = "test-support", feature = "bench"))` instead of
only `cfg(feature = "test-support")`.
`crates/benchmarks` now depends on `gpui_platform` with `["bench",
"font-kit"]` instead of `["test-support", "font-kit"]`.
`script/check-gpui-bench-feature-isolation` gains a macOS-only check
that walks `cargo tree --invert` for `benchmarks` against
`gpui_platform`, `gpui_macos`, and `gpui_apple` and fails if any of
them still resolve `test-support`, the same shape as the existing
gpui-level check.
Before this change, `cargo tree -p benchmarks --edges features
--invert gpui_platform` (and the `gpui_macos`/`gpui_apple` equivalents)
showed a `test-support` edge from `benchmarks`. After this change, the
same commands show only `bench` edges; `test-support` no longer
appears for any of the three platform crates.
Validation performed on this stack:
- `cargo check -p gpui_apple --no-default-features --features bench`,
same for `gpui_macos` and `gpui_platform`, all bench-only (no
test-support), all pass.
- All four `benchmarks` bench targets compile.
- `cargo tree` before/after comparison for `benchmarks` against each
platform crate confirms the `test-support` edge is gone and replaced
by `bench`.
- `script/check-gpui-bench-feature-isolation` passes, including the new
macOS-only platform-crate loop.
- `gpui_apple` and `gpui_macos` test suites pass.
- `gpui_platform`'s test failure is pre-existing and reproduces on the
base branch, unrelated to this change.
- `cargo fmt --check` and targeted `clippy` pass for the touched
crates.
Remaining edges out of scope: `crates/benchmarks/Cargo.toml` still
requests `test-support` from several application crates (`agent`,
`editor`, `language`, `language_model`, `lsp`, `project`, `settings`,
`theme`, `util`) to build fixtures and harnesses those benchmarks
exercise. Those are unrelated to the gpui platform split this change
addresses and are left untouched.
Release Notes:
- N/A
Enabling gpui's `bench` feature previously enabled `test-support` too,
so every `#[gpui::bench]` consumer transitively compiled gpui's
interactive test-double APIs (fake platform prompts, screen capture
simulation, proptest, etc.) alongside its production code. That defeats
the point of a benchmark: it can silently depend on behavior that only
exists for tests and would never ship.
`bench` still needs a handful of pieces that used to arrive bundled
inside `test-support`: a real multithreaded dispatcher
(`ThreadedDispatcher`), a window backed by a real headless GPU renderer
(`TestPlatform`/`TestWindow`/`PlatformHeadlessRenderer`), and the sprite
atlas plumbing those use. Those are moved onto their own
`cfg(any(test, feature = "test-support", feature = "bench"))` gates so
`bench` can use them without pulling in `test-support` as a whole.
The remaining interactive-only surface of `TestPlatform` (multiple-choice
prompts, path-selection dialogs, and their simulate/inspect helpers) stays
behind `test`/`test-support` only, since benchmarks have no API to answer
a prompt; `bench`-only builds get a minimal stub that resolves such a
prompt as immediately cancelled instead of leaving it pending.
crates/benchmarks continues to compile unchanged: it separately requests
`test-support` on `gpui_platform` (for its own real headless Metal
renderer lookup), so gpui's feature graph still unifies to
`bench + test-support` there today. That's a distinct dependency edge
this change doesn't touch: `gpui_platform`, `gpui_macos`, and `gpui_apple`
each gate their own headless-renderer glue behind their own test-support
feature, and giving `#[gpui::bench]` a real end-to-end path that needs no
crate's test-support would mean mirroring this same split there.
Added script/check-gpui-bench-feature-isolation, which walks gpui's
resolved feature graph with only `bench` enabled and fails if
`test-support` reappears in it.
Release Notes:
- N/A
- Notify the author when their PR has been in draft state with no new
commits for three weeks
- Close the draft PRs that didn't get updated after one more week
- Re-try the cla-bot check on PRs that are still unsigned after a week
- Close the PRs that are still unsigned after the re-try
## Testing
It works on my machine™
```
python script/github-pr-cleanup.py --dry-run
Checking 713 open pull requests
Dry-run mode: no comments or closures will be made
PR #60885: asking the CLA bot to check again
Would comment on PR #60885:
@cla-bot check
PR #61625: asking the CLA bot to check again
Would comment on PR #61625:
@cla-bot check
PR #57239: warning about a stale draft
Would comment on PR #57239:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #57241: warning about a stale draft
Would comment on PR #57241:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61461: warning about a stale draft
Would comment on PR #61461:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61722: warning about a stale draft
Would comment on PR #61722:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61808: warning about a stale draft
Would comment on PR #61808:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61809: warning about a stale draft
Would comment on PR #61809:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
Cleanup complete: 0 unsigned PR closures, 6 draft warnings, 0 draft closures
```
Release Notes:
- N/A
Bundled GLib shadowed the system libraries for host plugins dlopen'd
into the process, like PipeWire's videoconvert on 1.6+, which would
break Wayland screen sharing on newer distros. This PR makes Zed rely on
system GLib instead, since the bundled version pulls from whatever is in
CI (presently Ubuntu 20.04).
Release Notes:
- Removed GLib libraries from Linux release bundle, which could conflict
with system plugins
Release Notes:
- Fixed broken links in the installer Terms of Service dialog (#62677).
---
### Description
Closes#62677
In `script/terms/terms.rtf` and `legal/terms.md` (as well as
`legal/privacy-policy.md` and `legal/third-party-terms.md`), relative
URLs like `/privacy-policy` and `/acceptable-use-policies` caused error
-50 ("The application can't be opened") when clicked from installer
dialogs (such as the macOS installer).
This PR updates the relative URLs to absolute `https://zed.dev` URLs so
they open properly in the browser.
Label | Description
-- | --
area:integrations/git/panel | Feedback for the Git panel UI and
behavior.
area:gpui/graphics/wgpu | Feedback for GPUI's WGPU graphics backend,
including initialization and rendering.
area:breadcrumbs | Feedback for editor path and symbol breadcrumbs.
area:title bar | Issues suitable for title bar.
area:ai/agent thread/checkpoints | Feedback for Agent checkpoint
creation, comparison, restoration, and related Git behavior.
area:ai/agent thread/tools | Feedback for built-in Agent tools,
including execution, permissions, inputs, and outputs.
Release Notes:
- N/A
Our date filter used two qualifiers ("created:>START created:<=END"),
which isn't valid range syntax, so GitHub ignored it and returned every
open issue. Use a single "created:START..END" range. Also fix the window
math, which was a business day too recent and excluded its start day.
Release Notes:
- N/A
# Objective
Prevent successful installations on 32-bit Linux architectures where the
`zed` binary will **fail to execute** post-installation. Rather, fail at
installation time with a proper verdict.
`script/install.sh` maps `uname -m` onto the two architectures Zed
publishes builds for. Two of the matchers named 32-bit userlands and
mapped them onto a 64-bit tarball:
- `linux-armhf` mapped to `aarch64`
- `linux-i686*` mapped to `x86_64`
Neither can execute the binary it selected. Tested on i386 Debian Trixie
container: the installer downloaded, unpacked, symlinked and reported
success, and the failure surfaced later as an exec error -- see
[Showcase](##showcase).
Thus the installer's correct behavior would be to reject the 32-bit
architecture and terminate with an "unsupported" verdict.
## Solution
Remove the case-statement-based mapping of `linux-armhf` to `aarch64`,
and of `linux-i686*` to `x86_64`.
## Testing
Tested in isolation, simulating supported and unsupported platforms, and
supported and unsupported architectures:
| Platform | `uname -m` | Outcome |
| --- | --- | --- |
| Linux | `x86_64` | ✅ Installed — resolves to `x86_64`, symlink created
|
| Linux | `i386` | ❌ Unsupported — `i386` doesn't match glob `x86*` (no
case handles plain i386 anyway |
| Linux | `i686` | ❌ Unsupported — same reason |
| Linux | `aarch64` | ✅ Installed — resolves to `aarch64` |
| Linux | `arm64` | ✅ Installed — resolves to `aarch64` |
| Linux | `armv7l` | ❌ Unsupported — no 32-bit ARM case |
| Linux | `riscv64` | ❌ Unsupported |
| Darwin | `arm64` | ✅ Installed — resolves to `aarch64`, copied to real
`/Applications/Zed.app`, symlink created; |
| Darwin | `x86_64` | ✅ Installed — resolves to `x86_64`, copied to real
`/Applications/Zed.app`, symlink created |
| Darwin | `i386` | ❌ Unsupported — no case for macOS 32-bit |
| FreeBSD | `x86_64` | ❌ Unsupported platform - expected |
This is all correct behavior. Successful installations are expected to
work. Unsupported architectures are detected and rejected as unsupported
during installation.
## Showcase
```plaintext
~# file /usr/bin/dash # a sample executable showing the 32-bit arch
/usr/bin/dash: ELF 32-bit LSB pie executable, Intel i386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=7e2e8652114c8c2ae595b6f78798716a9ba07671, for GNU/Linux 3.2.0, stripped
~# file .local/zed.app/bin/zed
.local/zed.app/bin/zed: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e550eeb1d97f0cdac2460de672bfa36e9e3f6e25, not stripped
~# .local/zed.app/bin/zed
bash: .local/zed.app/bin/zed: cannot execute: required file not found
# It cannot find ELF 64-bit interpreter /lib64/ld-linux-x86-64.so.2 -- this is
# a 32-bit container on a 64-bit host. On a genuine 32-bit host it would fail with:
# `Exec format error`.
```
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Locally conducted tests cover the new/changed behavior
---
Release Notes:
- N/A
GitHub issue search can't express the one filter we want here: "created
at least one business day ago." That's the whole reason the project
board #\87 exists — since we can't save it as a search, we keep a
project's membership in sync to stand in for it.
So: an hourly workflow runs script/github-triage-queue-board.py, which
adds the open issues that fall in the eligibility window to project #\87
and removes the ones that have aged out. Also wires the workflow into
the community automation failure Slack alert, so if it breaks we hear
about it.
Release Notes:
- N/A
Fixes https://github.com/zed-industries/zed/issues/24880
# Objective
"Assisted/analysed by AI"
> The remote_server musl build failed with undefined references to
__isoc23_sscanf and __isoc23_strtol from aws-lc-sys because the default
C compiler used glibc headers while linking against musl libc. Setting
CC_<target>=musl-gcc ensures C dependencies compile with musl headers.
I have tested the fix, and it seems to have fixed the compilation issue
I faced on Fedora 44, without resorting to the [hack noted in
docs](https://zed.dev/docs/development/linux#installing-a-development-build).
Initially reported in this
[issue](https://github.com/zed-industries/zed/issues/24880).
I'd want someone with expertise in the domain to take a look at this
fix, as from what I understand, the process in the doc is a hacky
workaround.
## Solution
Setting CC_<target>=musl-gcc ensures C dependencies compile with musl
headers.
## Testing
- Did you test these changes? If so, how?
<details><summary>Here's my steps to repro:</summary>
1. install [toolbox](https://github.com/containers/toolbox) (or
podman-toolbox)
(I used toolbox as it's easy to reuse the cloned repo, as the whole home
dir is mounted in the devcontainer)
Used the main branch - commit 5d6c88cdb7
2. toolbox create -d fedora -r 44
3. toolbox enter fedora-toolbox-44
4. then run the `scripts/linux` script to install prereqs
5. try compiling remote-server using the commands in
`scripts/install-linux` (I just ran the script wholly)
LDD version:
```
⬢[root@toolbox zed]# ldd --version
ldd (GNU libc) 2.43
```
GCC/MUSL versions:
```
musl-gcc : 1.2.5
gcc : 16.1.1
```
Error:
```
error: linking with `cc` failed: exit status: 1
|
= note: "cc" "-m64"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/rcrt1.o"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crti.o"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crtbeginS.o"
"<747 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic"
"/root/zed/target/x86_64-unknown-linux-musl/release/deps/rustceHhjo8/{libzstd_sys-5c3eb6739555ecf4,libtree_sitter_json-ad90c8af7e8a3750,libtree_sitter-f91a92b688e12e56,libwasmtime-decd3377028506ce,libaws_lc_sys-a051f708b6dafc2a,libring-fcc1b43e3092bc93,libpsm-d967f50c6f2b67a4}.rlib"
"-lunwind" "-lc"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-*.rlib"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/deps/rustceHhjo8/raw-dylibs"
"-Wl,-Bdynamic" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack"
"-nostartfiles" "-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/psm-dc603221f407eabc/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/tree-sitter-28f7b87c1db3fab9/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/wasmtime-f0bb0950e09a7352/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/aws-lc-sys-2a7ca8eafafe18fa/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/ring-d7857a166bac60a6/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/zstd-sys-0e04609af7157148/out"
"-L"
"/root/zed/target/x86_64-unknown-linux-musl/release/build/tree-sitter-json-b1e2eeaba7bbb519/out"
"-L"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained"
"-L" "<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib" "-o"
"/root/zed/target/x86_64-unknown-linux-musl/release/deps/remote_server-3782b255c59d4e14"
"-Wl,--gc-sections" "-static-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1"
"-nodefaultlibs" "-Wl,--disable-new-dtags,-rpath,$ORIGIN/../lib"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crtendS.o"
"<sysroot>/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/crtn.o"
= note: some arguments are omitted. use `--verbose` to show all linker
arguments
= note: /usr/bin/ld.bfd:
/root/zed/target/x86_64-unknown-linux-musl/release/deps/rustceHhjo8/libaws_lc_sys-a051f708b6dafc2a.rlib(f8e4fd781484bd36-bcm.o):
in function `aws_lc_0_40_0_handle_cpu_env':
/aws-lc/crypto/fipsmodule/cpucap/cpu_intel.c:(.text.aws_lc_0_40_0_handle_cpu_env+0x63):
undefined reference to `__isoc23_sscanf'
/usr/bin/ld.bfd:
/root/zed/target/x86_64-unknown-linux-musl/release/deps/rustceHhjo8/libaws_lc_sys-a051f708b6dafc2a.rlib(f8e4fd781484bd36-bcm.o):
in function `pkey_rsa_ctrl_str':
/aws-lc/crypto/fipsmodule/evp/p_rsa.c:692:(.text.pkey_rsa_ctrl_str+0x222):
undefined reference to `__isoc23_strtol'
/usr/bin/ld.bfd:
/aws-lc/crypto/fipsmodule/evp/p_rsa.c:703:(.text.pkey_rsa_ctrl_str+0x261):
undefined reference to `__isoc23_strtol'
collect2: error: ld returned 1 exit status
= note: some `extern` functions couldn't be found; some native libraries
may need to be installed or have their path specified
= note: use the `-l` flag to specify native libraries to link
= note: use the `cargo:rustc-link-lib` directive to specify the native
libraries to link with Cargo (see
https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-link-lib)
error: could not compile `remote_server` (bin "remote_server") due to 1
previous error
```
</details>
- Are there any parts that need more testing? -- Maybe
- How can other people (reviewers) test your changes? Is there anything
specific they need to know? -- Steps listed above
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test? -- Fedora 44
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
## Showcase
> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.
- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!
While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:
<details>
<summary>Click to view showcase</summary>
My super cool demos here
</details>
---
Release Notes:
- Fixed musl error when building remote server from source for the
default musl triple on Linux
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
`priority:*` labels in the github repository are becoming `severity:*`,
and `frequency:*` — `reach:*`. This commit will update the slack
notifications for the first responders accordingly.
Also, delete the github-label-issues-to-triage.py one-off script, which
worked with the old label names and is by now too distant in the past to
be useful as reference or anything.
Release Notes:
- N/A
Rei-mplements the logic from
9552acc2bc/script/bundle-mac (L120-L123)
for Windows bundling so that `run-bundling` label in CI can build
unsigned Windows binaries properly.
Release Notes:
- N/A
## Summary
- Upgrade sccache from 0.10.0 to 0.16.0 on macOS, Linux, and Windows CI
runners.
- Normalize the GitHub workspace with `SCCACHE_BASEDIRS` so identical
builds can reuse cache entries across checkout roots.
- Validate the cached binary version and stop an older server before
replacing it, including on Windows where a running executable cannot be
overwritten.
## Why
The setup scripts configured `SCCACHE_BASEDIR`, which sccache did not
use for cache-key path normalization. Absolute checkout paths therefore
remained part of cache keys and reduced reuse between CI workspaces.
sccache 0.16.0 supports `SCCACHE_BASEDIRS` and includes the Windows
path-normalization fix needed for the Windows runner.
## Validation
- `bash -n script/setup-sccache`
- `git diff --check`
- Upgraded a live local sccache 0.15.0 server to 0.16.0 through the
setup script.
- Compiled identical C sources from two checkout roots and observed one
cache miss followed by one cache hit.
- Confirmed that every release asset referenced by the setup scripts
exists for the supported CI runner targets.
Release Notes:
- N/A
script/linux tried to install dev-util/cmake, which is not the correct
package name, so the script fails. Changing it to dev-build/cmake fixes
this.
Release Notes:
- N/A
Automates the Guild contributor program on project board #74 so the
cohort is recognized and kept unblocked without manual babysitting.
- Move a board issue to In Progress when a Guild member self-assigns it,
and post a friendly heads-up when they are assigned an issue that is not
on the board.
- Flag when a Guild member opens a new PR while another of theirs is
still open, to help them land work before spreading thin.
- Check in on quiet assignments and, if an assignee stays silent, free
the issue back to a to-do column so others can pick it up; a "guild
hold" label lets maintainers pause check-ins after they have followed
up.
- Share a weekly digest of what the Guild shipped.
- Label PRs from Guild members and recognize a Guild contributor tier on
the community PR board.
Release Notes:
- N/A
Although not listed on https://killedbygoogle.com/, the Google
cherry-pick bot was killed some time ago and we now use our own bot for
this. Thus we can safely remove the config here.
Also, fixes the shebang in the cherry-pick script.
Release Notes:
- N/A
Overhauls Zed's pickers to make them resizable and give them a preview.
Closes#8279
### Background
The most requested Zed feature has the last year has been a [Telescope
like search box](https://github.com/zed-industries/zed/issues/8279)
[discussion](https://github.com/zed-industries/zed/discussions/22581).
To understand why this is so popular we need to understand search can
serve thee goals:
- Navigation: fuzzy search is faster & easier then clicking in a file
tree
- Exploration: example, find a function by a word in its doc comment
- Collecting: example, getting a list of functions to change
The project search which shows results in a multibuffer is the perfect
way to operate on a list of items. Navigation and Exploration need a lot
of context around each result and offer fast navigation between them.
For both of these live searching is also critical.
The `telescope UI` is a picker with a preview to the right or below.
It's offered in various editors and IDE's most famously Neovim (through
the Telescope plugin), IntelliJ (natively), Helix (natively) and of
course VScode (plugins) and it's _many_ forks.
While having a UI like that for text search (our project search) is most
requested the UX pattern is applied widely, from `find_all_references`
to `bookmarks`. It enhances most pickers. Note that we have over 50
different picker modals!
The community has tried to build something like this for Zed:
- https://github.com/zed-industries/zed/pull/44530
- https://github.com/zed-industries/zed/pull/45307
- https://github.com/zed-industries/zed/pull/46478
- https://github.com/zed-industries/zed/pull/43790
These all became huge PR's that we could not merge for various reasons.
This is a really hard feature to integrate in Zed!
This PR got started as https://github.com/zed-industries/zed/pull/46478
and supercedes that.
### Design
- Extend pickers to support an optional preview with minimal changes to
the pickers themselves.
- Make pickers resizable.
- Complement the existing search do not replace it by having both UI's
share the underlying search and allow freely switching between them.
- Allow extending the preview to things other then files.
- Maintain a clean design on all the pickers.
### Heigh level Implementation overview
- Adds an `Option<Preview>` to `Picker`
- Gives `PickerDelegate` a method to communicate a preview to the Picker
- Overhaul the way pickers are drawn to allow for resizing them.
Implemented on the `Shape` and `SizeBouds` structs.
- Adds a high level way to draw the `footer` and `editor` so we do not
need to change much to the pickers.
- Adds a new text finder Picker
- Adds a way to take a running search from project search and hand it to
the text finder Picker and the other way round
- Give the file finder a preview
### Next steps
A more detailed list and how to help out will be added to the tracking
issue for [Pickes with
previews](https://github.com/zed-industries/zed/issues/56037)
- Add more previews to more pickers!
- Enable selectioning multiple items in pickers and performing actions
on those
- Open selected items in a multibuffer
- Add a way to restore the last picker
- Make popovers (picker attached to some menu) resizable as well
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
TODO (will be done post merge)
---
Release Notes:
- Added resizing via dragging to all picker modals.
- Added a preview to the File finder, the preview can be to the right or
below.
- Added a Text finder picker with a preview as alternative project
search UI. The search is shared and allowes switch between UIs while
running.
---------
Co-authored-by: ozacod <47009516+ozacod@users.noreply.github.com>
Co-authored-by: ozacod <ozacod@users.noreply.github.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Summary
- Adds Windows agent terminal sandboxing by routing commands through WSL
and Bubblewrap.
- Supports native Windows and WSL project paths, including elevated
write grants for WSL paths.
- Shows a confirmation prompt to turn off sandboxing when WSL sandbox
setup is unavailable.
This builds on the work in the sandbox-linux branch.
Closes AI-376
Release Notes:
- Added Windows terminal sandboxing for agent commands when sandboxing
is enabled.
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Rather than continuing to try to persuade Claude to pretty please only
output json, or to parse json out of Claude's prose, switch to forced
tool calls with a json schema and hope this works better.
And bump the version of the bot to 4 since the model upgrade which was
shipped earlier today is evidently behaving differently enough.
Release Notes:
- N/A
The GitHub workflow was sometimes failing when someone edited the
already-merged PR that had been archived on the board because archived
items can't have their fields changed. The project board fields don't
need to be updated when the PR is already merged or closed.
Release Notes:
- N/A
claude-sonnet-4-20250514 was retired by Anthropic on June 15, 2026,
causing the "Comment on potential duplicate bug/crash reports" workflow
to fail with a 404 from /v1/messages on the first call_claude
invocation.
Switch to the recommended replacement, claude-sonnet-4-6.
Release Notes:
- N/A
This slightly reworks the extension CLI bump workflow - instead of
triggering on label push, it now triggers on workflow dispatch with a
message enforced to be added there.
This primarily allows us to add a message to these bumps to better
communicate what changes with that version of the CLI. Furthermore, we
can soon restrict the label to be only created by that workflow, which
has the advantage that it can only be based off of main. Also, it has
the nice side-effect that we actually only ever update the label if
everything worked properly.
Release Notes:
- N/A
For the ease of finding something that fits the time that reviewers have
and for making it mechanically easier to prioritize the PRs from the
community champions, surface some meta information on the PR board (and
make it updatable). Meta information here means things like size and
whether there's an issue linked to the PR (and what is its type if there
is).
Release Notes:
- N/A
This PR updates the Danger check for touching the Collab schema files to
require attestation that the database schema migrations have been
created and applied.
If there are changes to the schema files without the attestation, Danger
will fail the status check with an error:
<img width="959" height="635" alt="Screenshot 2026-06-03 at 4 58 56 PM"
src="https://github.com/user-attachments/assets/e0857137-b351-4212-a023-13a7d53f5934"
/>
When the attestation clause is present, Danger will report it as such:
<img width="901" height="333" alt="Screenshot 2026-06-03 at 4 59 45 PM"
src="https://github.com/user-attachments/assets/098b0ce4-f86e-4d41-b6af-765bc015fe6e"
/>
Release Notes:
- N/A
Self-Review Checklist:
- [X] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- N/A
## Summary
This moves the remaining first-party AGPL surface to GPL, a less
restrictive license for these components. Apache-2.0 components are
unchanged.
Changes:
- Updates the `collab` crate from `AGPL-3.0-or-later` to
`GPL-3.0-or-later`
- Removes the root AGPL license file and first-party crate AGPL symlinks
- Updates web, documentation, Flatpak, README, and terms references to
reflect the GPL/Apache licensing split
- Updates the open-source component example list in the terms and
regenerates the RTF copy; no other terms changes are intended
- Adds guardrails so first-party crates cannot declare AGPL licensing or
carry `LICENSE-AGPL` files
Release timing: preview during the week of June 1, 2026; stable during
the week of June 8, 2026.
## Residual AGPL/Affero references
- `LICENSE-GPL`: GPLv3's own compatibility clause; unchanged official
license text.
- `crates/json_schema_store/src/schemas/package.json`: generic npm
package-license schema value, not Zed licensing.
- `script/check-licenses`, `script/new-crate`,
`script/licenses/zed-licenses.toml`: guardrails that reject or warn
against reintroducing AGPL.
## Verification
- `script/check-licenses`
- `script/generate-licenses`
- `script/generate-terms-rtf`
- `script/new-crate license_probe_for_gpl`, then discarded generated
crate
- `script/new-crate license_probe_for_agpl agpl` fails as expected
- `mdbook build docs`
- `./script/clippy`
- `git grep -n -I -E "AGPL|Affero"`
- `git diff --check`
Release Notes:
- The `collab` crate, used to implement Zed's collaboration backend, is
now licensed under the GPL instead of the AGPL. The AGPL license is no
longer used in the zed repository.
