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
54f51254df
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 |
||
|---|---|---|
| .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.