mirror of
https://github.com/zed-industries/zed.git
synced 2026-08-23 16:04:45 +00:00
original uri https://github.com/zed-industries/zed
https://zed.dev
73c574beb7
`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 |
||
|---|---|---|
| .agents/skills | ||
| .cargo | ||
| .cloudflare | ||
| .config | ||
| .factory | ||
| .github | ||
| .wezel | ||
| .zed | ||
| assets | ||
| ci | ||
| crates | ||
| docs | ||
| extensions | ||
| legal | ||
| nix | ||
| script | ||
| tooling | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .prettierrc | ||
| .rules | ||
| AGENTS.md | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CLAUDE.md | ||
| clippy.toml | ||
| CODE_OF_CONDUCT.md | ||
| compose.yml | ||
| CONTRIBUTING.md | ||
| debug.plist | ||
| default.nix | ||
| Dockerfile-collab | ||
| Dockerfile-collab.dockerignore | ||
| Dockerfile-cross.dockerignore | ||
| Dockerfile-distros | ||
| Dockerfile-distros.dockerignore | ||
| flake.lock | ||
| flake.nix | ||
| GEMINI.md | ||
| LICENSE-APACHE | ||
| LICENSE-GPL | ||
| livekit.yaml | ||
| lychee.toml | ||
| Procfile | ||
| Procfile.web | ||
| README.md | ||
| renovate.json | ||
| REVIEWERS.conl | ||
| rust-toolchain.toml | ||
| rustfmt.toml | ||
| shell.nix | ||
| typos.toml | ||
Important
Remove this line to confirm you've reviewed this PR before submitting.
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
On macOS, Linux, and Windows you can download Zed directly or install Zed via your local package manager (macOS/Linux/Windows).
Other platforms are not yet available:
- Web (tracking discussion)
Developing Zed
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Also... we're hiring! Check out our jobs page for open roles.
Licensing
Zed source code is licensed primarily under GPL-3.0-or-later, with Apache-2.0 components where marked.
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.
Sponsorship
Zed is developed by Zed Industries, Inc., a for-profit company.
If you’d like to financially support the project, you can do so via GitHub Sponsors. Sponsorships go directly to Zed Industries and are used as general company revenue. There are no perks or entitlements associated with sponsorship.