20fa2fa80949e94b6eecb48c8a46fbf32b82f1fc
4984
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
20fa2fa809 |
Reduce LLVM IR bloat one last time (#63882)
I think this is the final attempt of mine to do anything about the binary size, as those fixes become relatively intricate and I like them less and less. Each commit has its own improvement stats and mainly reduce generic-code duplication through shared non-generic helpers and `#[inline(never)]` boundaries. Total reduction stats: With sccache disabled, `cargo clean` and `cargo build --release -p zed`: Before: zed binary 396716472 bytes After: zed binary 359416504 bytes (-9.40%, -37.29MB) Release Notes: - N/A --------- Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
|
63d15474c7 |
Use fewer file descriptors on macOS to detect worktree root path changes (#63863)
Previously, on macOS, we set the [WatchRoot flag](https://developer.apple.com/documentation/coreservices/kfseventstreamcreateflagwatchroot) to `FsEventStreamCreate` (via our notify fork). This causes the resulting stream to produce an event when any segment of the watched path changes due to a rename (e.g. `/Users/cole/zed/crates/gpui` -> `/Users/cole/zed2/crates/gpui`). The cost of this is that for each path we watch on macOS, we hold open file descriptors for that path and all its parents (and these are not deduplicated across watched paths). This especially blows up our file descriptor usage with non-visible worktrees from GTD jumps: ``` zed 25415 cole 721r REG 1,14 99826 168007500 /Users/cole/.rustup/toolchains/1.97.1-aarch64-apple-darwin/lib/rustlib/src/rust/library/core/src/option.rs zed 25415 cole 722r DIR 1,14 2432 168008864 /Users/cole/.rustup/toolchains/1.97.1-aarch64-apple-darwin/lib/rustlib/src/rust/library/core/src zed 25415 cole 723r DIR 1,14 128 168008863 /Users/cole/.rustup/toolchains/1.97.1-aarch64-apple-darwin/lib/rustlib/src/rust/library/core zed 25415 cole 724r DIR 1,14 928 168008723 /Users/cole/.rustup/toolchains/1.97.1-aarch64-apple-darwin/lib/rustlib/src/rust/library zed 25415 cole 725r DIR 1,14 128 168008722 /Users/cole/.rustup/toolchains/1.97.1-aarch64-apple-darwin/lib/rustlib/src/rust zed 25415 cole 726r DIR 1,14 96 168008721 /Users/cole/.rustup/toolchains/1.97.1-aarch64-apple-darwin/lib/rustlib/src zed 25415 cole 727r DIR 1,14 704 168004176 /Users/cole/.rustup/toolchains/1.97.1-aarch64-apple-darwin/lib/rustlib zed 25415 cole 728r DIR 1,14 256 168004175 /Users/cole/.rustup/toolchains/1.97.1-aarch64-apple-darwin/lib zed 25415 cole 729r DIR 1,14 224 168004164 /Users/cole/.rustup/toolchains/1.97.1-aarch64-apple-darwin zed 25415 cole 730r DIR 1,14 576 292591 /Users/cole/.rustup/toolchains zed 25415 cole 731r DIR 1,14 224 292480 /Users/cole/.rustup zed 25415 cole 732r DIR 1,14 8576 43880 /Users/cole zed 25415 cole 733r DIR 1,14 160 18221 /Users ``` This PR bumps our notify dependency so that we no longer set that flag, and instead just wake the background scanner loop every 5s to check whether the worktree root path has changed. Note that both before and after this change, the process_events arm of that loop checks the worktree root path in the same way before doing anything else, so there is no risk of descending further into the background scanner code with an incorrect root path. Release Notes: - Made Zed use fewer file descriptors on macOS. |
||
|
|
c8c07aea5c |
Add disable_ai check for "Agent Panel" MenuItem (#63580)
# Objective - Removes Agent Panel menu item when AI disabled toggle is on. - Fixes #63497 ## Solution - Use the global DisableAiSettings - disable_ai check in `app_menus.rs`. To keep the order the same I 1. Check the disable AI setting 2. If true push to the `view_items` vec![] 3. Extend the vec![] with the remaining Menu Items and Separators. ## Testing This can be tested visually: 1. Open Zed with AI settings enabled 2. Click View when Zed is focused 3. Noting where Agent Panel is on the list and to make sure clicking it opens up the Agent Panel. 4. Open settings 5. Navigate to AI settings 6. Toggle disable AI on 7. Click View Expected: Agent Panel is gone from the menu. The opposite is also expected. - This was tested on macOS 26.6.2 (25G83). ## 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 To keep this PR simple, I did not add any testing to this, as there were no tests in this file already. - [x] Performance impact has been considered and is acceptable ## Showcase <details> <summary>Click to view showcase</summary> https://github.com/user-attachments/assets/50db44ac-6c11-4101-a064-fd4e3b285620 </details> --- Release Notes: - Fixed Agent Panel appearing in the "View" menu when disable AI settings is on. --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev> |
||
|
|
ba6b83f89d |
workspace: Add configurable window title formatting (#54379)
## Summary
- Add `window_title_format` and `window_title_separator` settings for
customizing the window title
- Expose `${projectName}`, `${fileName}`, `${filePath}`,
`${relativePath}`, `${fileStem}`, `${remoteName}`, `${remoteHost}`,
`${appName}`, and `${separator}` as the native Zed window-title
variables
- Keep the collab `↗/↙` indicator hard-appended
- Translate VS Code `window.title` / `window.titleSeparator` aliases
into Zed's canonical variables during settings import, including
`${appName}` passthrough support and mapping VS Code's
`${activeEditorMedium}` onto Zed's `${relativePath}`
- Gate path-, remote-, and release-channel-derived lookups on whether
the active template references the corresponding variable, so the
default template avoids the extra work and still uses the existing
`last_window_title` cache to skip redundant platform updates
An alternative approach is at #49638. I went with `${variable}` names
over `$ZED_*`, canonical Zed variable names with VS Code aliases handled
at import time, kept `${separator}` as the only structural token, and
left `${dirty}` out of scope.
## Implementation reasoning and notes
### Variables considered but not included
- **collab/shared indicator variable**: kept hard-appended instead.
Folding it into the template would need whitespace/separator logic the
other variables don't need, and I'd rather not bake those semantics in
without a concrete need for it.
- **dirty variable**: The glyph choice and interaction with OS-level
edited indicators (like macOS's titlebar dot via `set_window_edited`)
felt like a separate design call I wasn't confident making here.
A separator-style config for each of collab/shared/dirty would solve the
above, but I didn't want to add too many additional settings initially.
### Performance
`update_window_title` is on a hot path, so two short-circuits apply:
- Path-, remote-, and release-channel-derived lookups (`absolute_path`,
relative-path string, `file_stem`, `remote_connection_options`,
`ReleaseChannel::try_global`) are gated on `template.contains(...)` via
`WindowTitleNeeds::from_template`, so the default template avoids the
extra work.
- The existing `last_window_title` cache still skips the platform call
when the rendered title is unchanged.
## Screenshots
Settings Editor entries for `window_title_format` and
`window_title_separator`:
<img width="774" height="324" alt="Settings Editor screenshot"
src="https://github.com/user-attachments/assets/b3378ec7-5649-4de3-9de6-164a42bce3fd"
/>
Customized Zed window titles in AltTab app switcher (remote, local,
empty):
<img width="774" height="324" alt="AltTab app switcher screenshot"
src="https://github.com/user-attachments/assets/a189945e-fc68-41b9-aab9-6dc04d5ef4ab"
/>
## 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 is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #14534
Release Notes:
- Added configurable window title formatting with `window_title_format`
/ `window_title_separator`, including `${appName}` / `${remoteName}` /
`${remoteHost}` variables and VS Code `window.title` import support
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
|
||
|
|
ab7afbff39 |
panel: Remove unused panel crate (#63742)
# Objective remove unused crate ## 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 --- Release Notes: - N/A --------- Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com> Co-authored-by: MrSubidubi <finn@zed.dev> |
||
|
|
59b0c714ff |
settings_ui: Fix layout issues with recently created GitHub accounts (#63630)
# Objective Fixes #62169 Accounts which are marked "too young" have layout issues within the LLM settings. Example provided in the linked issue. ## Solution Allow the provider controls to shrink to the available width instead of retaining their content width. Also make the young-account configuration fill that width so the warning wraps correctly without collapsing the provider description. I think the "Upgrade to Pro" looks a little stretched now, but I don't know how to fix it without allocating even more space for the already large setting section. Could we possibly shorten the 30-day requirement explanation? Regardless, it's much better than what it was before :D ## Testing - I added a debug selector to be able to write a regression test for layout issues. Since the UI may change, the tests only enforce the rough layout. - Compiled with `too_young_account` being `true` and `false`, checking that the UI looks okay. ## 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 <details> <summary>Click to view showcase</summary> Before: <img width="639" height="678" alt="image" src="https://github.com/user-attachments/assets/45ed32b0-8987-49d1-8bbd-a12f7917570a" /> After: <img width="640" height="225" alt="image" src="https://github.com/user-attachments/assets/bb39a847-7d36-4597-b16d-6a6ccb872817" /> </details> --- Release Notes: - Fixed layout issues in settings when using recently created GitHub accounts --------- Co-authored-by: MrSubidubi <finn@zed.dev> |
||
|
|
d85eade7ab |
which_key: Add a pending key binding indicator (#63343)
This PR makes Zed's one-second key binding delay visible. Say both ctrl-w and ctrl-w left have bindings. After you press ctrl-w, Zed waits to see whether left follows. The PR shows that wait in the status bar with a countdown. Hovering the indicator shows which bindings can still match. It also adds a setting to hide the indicator. It does not change how Zed resolves key bindings. <img height="100" alt="dyn-db84a840272e2f6250a3f527a59b1efd" src="https://github.com/user-attachments/assets/e42c6a6c-4677-499f-a1d3-835960ebb21a" /> <br/> <img height="100" alt="dyn-8012278d030b41bc8ebfae1540504eff" src="https://github.com/user-attachments/assets/250928d5-f913-40f0-9068-00ccb5cdf59f" /> <br/> <img height="100" alt="file-5e6ffa90944faa294e7870f471b4e65b" src="https://github.com/user-attachments/assets/c250e6eb-a269-4e2c-a5a0-0be9b5006f99" /> Release Notes: - Added a status bar countdown for pending multi-stroke key bindings. --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev> |
||
|
|
ab7d21d444 |
Fix workspace diagnostics polling (#63336)
Closes https://github.com/zed-industries/zed/issues/62391 Workspace diagnostics were polled incorrectly: * Workspace pulls were cancelled and re-sent every 120s. Pyright-family servers hold the request open forever and re-analyze the whole workspace on every new one, so the retry loop leaked memory; the request is now kept open (long-poll), as the spec recommends. * No re-trigger after a server closed a workspace pull. ty closes the request when diagnostics change and expects the client to re-pull * `ServerCancelled` / `retriggerRequest` was ignored. The spec defaults cancellation data to `{ retriggerRequest: true }`, so these errors now retrigger workspace pulls and retry document pulls instead of failing them. * LSP error codes were erased with `anyhow!(message)` Errors now carry a typed `lsp::ResponseError` through the chain, replacing four copies of `ends_with(...)` matching against rust-analyzer's literal message texts. * Workspace partial results were not tied to their request. Stale or numeric-token `$/progress` reports were applied as current data and could poison `previousResultIds` until a server restart; reports are now matched against the exact in-flight token. * `interFileDependencies` was never read. Every edit re-pulled all other open buffers even for servers declaring no inter-file dependencies (e.g. ruff); cross-buffer pulls are now gated on that capability. * Cross-buffer pulls were unpaced. All open buffers were pulled back-to-back after each edit debounce; they are now paced at one document per 500ms. * The failure valve killed workspace pulls permanently. 51 hard errors over a server's lifetime silently stopped its workspace pulls until restart * Concurrent refresh waiters could be dropped instantly. The capacity-1 refresh channel resolved a second concurrent waiter to `false` immediately, and request errors dropped queued refreshes; waiters now queue and carry over to the retried pull. Release Notes: - Fixed basedpyright memory leak caused by incorrect workspace diagnostics polling |
||
|
|
6b5e15ed46 |
Bump more dependencies (#63379)
* 1st commit fixes bumps `quinn-proto` and `serde_with` to fix the dependabot alerts * 2nd commit deduplicates more dependencies `cargo tree -d` listing: 194 -> 187 top-level entries on the host target, 298 -> 287 unique duplicated crate-versions across all targets. <details> <summary>Deduplicated list</summary> ``` accesskit_consumer (v0.35.0, v0.37.0 -> v0.38.0) bindgen (v0.71.1, v0.72.1 -> v0.72.1) nix (v0.28.0, v0.29.0, v0.30.1 -> v0.28.0, v0.30.1) ordered-float (v2.10.1, v4.6.0 -> v5.5.0) quick-xml (v0.30.0, v0.37.5, v0.38.3, v0.39.3, v0.41.0 -> v0.30.0, v0.37.5, v0.39.3, v0.41.0) sysinfo (v0.31.4, v0.37.2 -> v0.31.4, v0.39.6) wasm-encoder (v0.252.0, v0.254.0 -> v0.254.0) wasmparser (v0.252.0, v0.254.0 -> v0.254.0) windows-registry (v0.4.0, v0.5.3, v0.6.1 -> v0.4.0, v0.6.1) ``` `ordered-float v4.6.0` remains in the lockfile only as an inactive optional dependency of `sea-query`; the compiled graph is fully deduplicated to v5.5.0. </details> Release Notes: - N/A |
||
|
|
ff68a64caf |
Bump Zed to v1.20.0 (#63636)
Release Notes: - N/A Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
|
8514ce3ba1 |
Unify language model event stream handling (#63520)
Closes https://github.com/zed-industries/zed/issues/63314 Closes https://github.com/zed-industries/zed/issues/42584 Follow-up to https://github.com/zed-industries/zed/pull/62652 Removes a lot of duplicated code in favor of throwing it into`language_core` as well as removing duplicate struct definitions that were only different because of entirely unused fields. Furthermore, improves error-messages so that these untagged enum errors are no longer a thing in an effort to make this more maintainable in the future. Lastly, includes a small but nice improvement changing a `Value` to a `RawValue` so that we don't have to clone for deserialization in that specific case. Release Notes: - Improved streaming for OpenAI-compatible providers. --------- Co-authored-by: Anant Goel <anant@zed.dev> |
||
|
|
d1446d66e0 |
edit_prediction: Adjust to support Ollama to be used for AI edit prediction (#63519)
# Objective Fix two related bugs in the Ollama edit-prediction provider config (`Settings > AI > Edit Prediction > Configure Providers`): 1. The Ollama model dropdown showed only a single model (the currently-configured one), regardless of what models were actually available on the configured server. 2. Ollama never appeared as a selectable option in the "Active Provider" list, even when fully configured. Both bugs shared the same root cause: several places in the edit-prediction code path read from the Assistant's separate Ollama *language model* provider (`language_models.ollama.*`, used by the AI panel/agent) instead of the edit-prediction-specific `edit_predictions.ollama.*` settings. These are two independent Ollama connections that can point at different servers, so the edit-prediction UI was effectively showing/gating on the wrong provider's state. This changes fixes #47393 ## Solution - **Model dropdown**: Added `edit_prediction::ollama::fetch_models_from_server`, which queries `/api/tags` directly against the edit-prediction's own configured `api_url`, independent of the Assistant's Ollama provider. The dropdown now re-fetches from that URL every time it's opened, so changing the server URL and reopening the dropdown shows the new server's models. - **Model filtering**: Fetched models are filtered to those Zed can infer a completion prompt format for (`infer_prompt_format`), so chat-only and embedding models (e.g. `nomic-embed-text`, `llama3:70b`) no longer clutter the list. This function was extracted from `edit_prediction_registry.rs` (previously private, used only for prompt-format resolution) into `edit_prediction::fim` so it can be shared between the dropdown filter and the existing routing logic — same behavior, no duplication. - **Provider visibility**: `get_available_providers` now gates Ollama's visibility on `edit_predictions.ollama.is_some()` (i.e. whether the user has configured a model), matching the existing pattern already used for the OpenAI-Compatible provider, instead of checking the unrelated Assistant provider's authentication state. Removed the now-dead `ollama::is_available`/`ensure_authenticated` functions and the startup call that existed solely to make that broken check eventually pass. ## Testing - Added unit tests for `infer_prompt_format` covering all known model families (qwen/codellama/deepseek-coder/starcoder/codestral/glm/zeta/sweep) and confirming unsupported models (chat/embedding) correctly return `None`. - Added an async test for `fetch_models_from_server` using a fake HTTP client, verifying it filters to FIM-capable models and returns them sorted. - Added a regression test, `test_ollama_provider_routes_to_fim_model`, verifying that Ollama + a known model (`qwen2.5-coder:3b`) resolves to `EditPredictionProviderConfig::Zed(EditPredictionModel::Fim { format: Qwen })` — this exercises the exact routing path underlying the provider-visibility fix. - Manually verified end-to-end against a real local Ollama server: configured a custom `api_url`, confirmed the model dropdown populated with the server's actual models, selected one, and confirmed Ollama appeared in and could be selected from the Active Provider list, with predictions successfully returned. - Ran `cargo check` and `./script/clippy` on all touched crates (`edit_prediction`, `settings_ui`, `edit_prediction_ui`, `zed`); no warnings. - Not tested: the `get_available_providers` gating change itself has no direct test (it's a one-line settings check whose underlying resolution is covered by the `zed`-crate regression test above); Windows/Linux were not tested, only macOS. ## 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 <details> <summary>Click to view showcase</summary> Now when we open the dropdown model selector on Ollama section we will see the available models in the current server that we are trying to use <img width="903" height="755" alt="image" src="https://github.com/user-attachments/assets/873c662b-3624-4530-811c-6f07ab518e35" /> Now Ollama will be displayed as provider in the edit prediction providers dropdown <img width="903" height="755" alt="image" src="https://github.com/user-attachments/assets/9dfe737d-6527-4ecd-9803-3d0959075c34" /> </details> --- Release Notes: - Fixed Ollama edit predictions not appearing as a selectable provider and the model dropdown showing only a single model instead of the models available on the configured server |
||
|
|
a49de953a8 |
gpui_linux: Prevent panic while reporting Wayland errors (#63159)
`wayland-backend` falls back to `eprintln!` when its optional `log` feature is disabled. If a Wayland connection fails while standard error is unavailable, that fallback panics while trying to report the original error. Closes ZED-8BW Enable the existing `log` feature on `gpui_linux`'s direct `wayland-backend` dependency. `gpui_linux` already depends on the `log` facade, so this introduces no new logging system; it routes backend errors through the configured logger and avoids the secondary standard-error panic. Testing performed: Release Notes: - Fixed a Linux crash when reporting a Wayland connection error while standard error is unavailable. |
||
|
|
ee6badf4b0 |
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> |
||
|
|
a60addb9a9 |
gpui_macos: Migrate PlatformWindow::prompt to objc2 on MacOS (#59572)
# Objective Rust 1.96 emits a warning when compiling the `block` crate, that it will no longer compile past some future version of Rust. The `block` crate provides `ConcreteBlock` and `RcBlock`, which are stack- and heap-based functions often passed as callbacks to MacOS. The old `objc` crate family is deprecated and no longer maintained. The goal of the PR is to replace one call to `block::ConcreteBlock` by migrating a standalone portion of code to the objc2 crate family. A full migration to `objc2` by Zed has been long on the horizon (#22408) Additional benefits: The new code is completely typed, uses automatic memory management, and reduces lines of unsafe Rust from 50+ to 1. The lingering unsafe converts a raw pointer stored by `self` to the respective `objc2` type, since the rest of the window implementation does not use the new crates yet. ## Solution Migrate `PlatformWindow::prompt`'s MacOS implementation to `objc2`. ## Testing Direct platform code is quite fragile and hard to test, however you can exercise the codepath by running the following `gpui` example and clicking on the prompt buttons. ```sh cargo run -p gpui --example window ``` I've also built Zed with these changes and tried codepaths which activate prompts, such as deleting a file. ## 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 - [x] Performance impact has been considered and is acceptable --- Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
|
ef075910c9 |
gpui_web: Let applications provide fonts (#63493)
`gpui_web` currently embeds IBM Plex Sans and Lilex into every browser application during platform construction. Applications such as Delta already provide their own fonts, so those binaries contain overlapping font bundles and register the same faces twice. This change starts the web platform with an empty font database, matching the ownership boundary used by native applications: the application selects and registers its fonts before opening a window. Delta already follows that sequence. GPUI's browser-capable examples now load the former eight-face bundle explicitly through shared example support, while the standalone `hello_web` example demonstrates registering a minimal application font directly. Testing performed: - `cargo check -p gpui --examples --target wasm32-unknown-unknown` - `cargo check -p gpui --examples` - `cargo check -p gpui_web --target wasm32-unknown-unknown` - `cargo check --manifest-path crates/gpui_web/examples/hello_web/Cargo.toml --target wasm32-unknown-unknown` - `./script/clippy -p gpui_web --target wasm32-unknown-unknown` - `cargo fmt -p gpui -p gpui_web --check` Release Notes: - N/A |
||
|
|
adc72a5a49 |
Support CSV preview in project-less set-ups (#63350)
Closes https://github.com/zed-industries/zed/issues/63265 Release Notes: - Fixed CSV preview not showing in project-less set-ups |
||
|
|
24254879b7 |
Stop re-resolving editorconfig sections on every language settings lookup (#63323)
Closes https://github.com/zed-industries/zed/issues/59689
Symbolicating the reporter's profile (21s of typing, Windows) showed
`Window::draw` taking 63% of the main thread at ~62 redraws/s (p95 draw
= 40ms), and 30.9% of the *entire* main thread inside
`EditorconfigStore::properties()`:
every `LanguageSettings` lookup — several per frame via
`DisplayMap::tab_size`, `MultiBuffer::language_settings`, indent guides,
and `LspStore::supports_range_formatting` — re-ran the full editorconfig
resolution (ancestor walk plus `ec4rs::Section::apply_to` over every key
of every section) and then cloned the whole `LanguageSettings` struct.
Real-world `.editorconfig` files carry hundreds of irrelevant keys
(`dotnet_*`, `ij_*`, ...), so the per-call map assembly dominated:
`RtlAllocateHeap` 7.3%, `memcmp` 7.0%, `memcpy` 6.6%,
`Properties::find_idx` 5.9% self time.
## Commit 1: resolve only the editorconfig properties Zed reads
- `EditorconfigStore::properties()` now applies only the 7 keys Zed
consumes (`indent_style`, `indent_size`, `tab_width`, `end_of_line`,
`max_line_length`, `insert_final_newline`, `trim_trailing_whitespace`)
instead of materializing every key of every matching section.
- Worktrees with no editorconfig at all now return `None` early instead
of allocating an empty `Properties` and forcing a `LanguageSettings`
clone on every lookup.
- Adds an `editor_render_with_editorconfig` benchmark: maximized window,
file-backed buffer at `src/app/components/editor_pane.ts`, a root
`.editorconfig` shaped after [the second
report](https://github.com/zed-industries/zed/issues/59689#issuecomment-5475124891)
(no `root = true`, a `[*]` section with ~3200 keys, 25 sections with
large `{...}` alternation lists) plus a 4-level nested chain, and a
typing workload (insert/delete + cursor moves).
```
main (
|
||
|
|
770aac345c |
cloud_api_client: Add yield point to prevent background task hangs (#63105)
Follow-up: https://github.com/zed-industries/zed/pull/62874 # Objective After having Zed open for a while I'm getting some foreground and background hang warnings, like this one. ``` 2026-08-19T11:25:45+02:00 INFO [zed::reliability::hang_detection::logging] New foreground hang detected: Tasks(s) that ran too long 215.24375ms - crates/cloud_api_client/src/websocket/native.rs:34:23 ``` ## Solution My solution is to add yield points so a single task doesn't block the executor thread for too long. ## 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 - [x] Performance impact has been considered and is acceptable Release Notes: - N/A |
||
|
|
9dbc9e76c1 |
Stop prompting to migrate settings that contain no deprecations (#62818)
## Objective Zed can report that a settings file uses deprecated settings even when it contains no deprecations. A context server configured with only a `url` is enough to trigger the prompt, although the backup Zed offers to write is identical to the current file. Fixes #24967. ## Solution Two text-edit migrations cancel each other on `context_servers` entries: one adds a `source` key and a later one removes it. The round trip reindents the entry, and the migrator mistakes the leftover whitespace for a migration. Remove `m_2025_06_16` rather than comparing around that whitespace. It wrote `source` and `settings` into every entry, but `ContextServerSettingsContent` contains neither field today. `settings` is worse than inert: an empty entry such as `{ "settings": {} }` matches neither the `Stdio` nor `Http` variant of the untagged enum. Update `m_2025_06_27`, the only remaining consumer of the generated `"source": "custom"`, to detect legacy entries from the shape of `command` itself. This continues to flatten settings written before `source` existed. It also deliberately flattens an object `command` beside `"source": "extension"`, which the old migration skipped. The command shape is invalid regardless of the declared source, and a test pins the new behavior. `m_2025_11_25` remains unchanged because it still removes `source` from settings that genuinely carry it. This deletes one migration and edits another despite the warning at the top of `migrator.rs`. That warning protects later migrations that depend on earlier output, but this output has no remaining consumer. I left the policy unchanged rather than adding an exception in the same PR that relies on it, but I can document the exception if preferred. ## Testing - `cargo test -p migrator` passes, 86 tests. The suite loses the three tests that only exercised the deleted migration and gains `test_flatten_context_server_command_alongside_source`, covering a legacy entry that carries both `source` and an object `command`. - Restoring the `source` requirement on `m_2025_06_27` with the deletion in place turns `test_flatten_context_server_command` red. Its input is a pre-`source` entry, which is what makes the relaxation load-bearing rather than incidental. - To check by hand: add `"context_servers": { "grep": { "url": "https://mcp.grep.app" } }` to user settings and confirm no migration prompt appears. Add `"show_inline_completions": true` alongside it and confirm the prompt returns and leaves the context server block untouched. - I have not run those steps in a built editor. The tests call `migrate_settings`, which is all `should_migrate_settings` checks before raising the prompt, so that call is the whole untested gap. It’s all platform-independent text processing, so I did not test Linux or Windows. ## 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 --- Release Notes: - Fixed the migration prompt appearing for settings that contain no deprecations. Context servers configured with only a `url` no longer trigger it. --------- Co-authored-by: MrSubidubi <finn@zed.dev> |
||
|
|
49469000f0 |
Ensure that multibuffer anchor ordering is stable over time and consistent with resolution (#62636)
Digging into ZED-7G6 ("buffer snapshot not found for excerpt boundary",
171 events) revealed some bugs in the implementation of multibuffer
anchors that landed in #52364. Specifically:
- In the presence of multibuffer excerpt changes, it was possible for
two anchors to satisfy `a1 < a2` but `a1.to_offset() > a2.to_offset()`.
This happened in particular when a `PathKey` was reused for two
different buffers at different times, and could cause crashes in code
that sorted anchors by `cmp` and expected the resulting offsets to be
sorted.
- Changes of diff base and normal buffer edits could cause two anchors
to sort `a1 < a2` against one snapshot and `a2 < a1` against a later
snapshot. This could also cause crashes in downstream code that
(reasonably) expected anchors to have a stable ordering.
This PR adds a property test asserting that multibuffer anchor ordering
is stable over time and consistent at every moment in time with the
ordering obtained from resolving the anchors, and fixes the bugs in
anchor resolution and comparison that are revealed by that test. It also
includes tests downstream for specific cases that previously crashed.
Closes ZED-7G6
Release Notes:
- Fixed a crash that could occur when inlay hints were present while a
multibuffer replaced the contents of a file, such as a diff view whose
base changed.
- Fixed crashes that could occur when a file's contents were replaced in
a multibuffer (such as a diff view refreshing) while highlights, inlay
hints, or other positions still referenced the old contents.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
|
||
|
|
669bede5c5 |
editor: Add language detection for untitled buffers (#61412)
# Objective Closes #4868. Reintroduce automatic language detection for user-created untitled buffers without allowing it to override language choices made by users or owning surfaces. More details: + https://github.com/zed-industries/zed/pull/61201 + https://github.com/zed-industries/zed/pull/61351 ## Solution VS Code distinguishes between inferred and explicitly selected languages, and only continues automatic detection in the former state. This change introduces a buffer-local opt-in flag with the same purpose. It defaults to disabled and is enabled only for user-created untitled buffers and restored untitled buffers that did not persist a language. Choosing a language through the language picker disables detection, while automatically detected languages remain eligible for later redetection. Buffers whose language is assigned by their owning surface, such as Channel Notes, never opt in. Rather than adding persisted state or changing the database schema, restoration reuses the existing optional serialized language. An opted-in buffer that remains Plain Text is serialized without a language and resumes detection after restoration. Once automatic detection has selected a language, that language is serialized normally and restoration leaves detection disabled, effectively treating it as an explicit selection. This also matches VS Code's effective default after restoration. Candidate selection adopts VS Code's confidence-group filtering. Results below the minimum confidence are discarded, and candidate groups are accepted only after a clear confidence gap. The detector then selects the first available Zed language without eagerly loading every candidate. I then added a separate switching rule: Zed keeps the current language unless another candidate has a clear confidence advantage, reducing language changes as model scores fluctuate during editing. Model inference runs off-thread on a bounded sample, and stale results are discarded. I also evaluated penalizing YAML and using stricter global switching thresholds, but neither reliably resolves the ambiguity between Markdown and YAML. In the reproduction from #61351, Betlang assigns YAML more than 80% confidence during editing and peaks around 90%. This is reasonable from the content alone: `#` denotes a YAML comment, while `-` denotes a sequence item. Adding ordinary prose or a fenced code block shifts the model strongly toward Markdown. A fixed penalty would overfit this example and risk suppressing legitimate YAML detection. Since known-language buffers do not opt in and manual language selection takes precedence, I consider this level of ambiguity acceptable and prefer not to introduce language-specific score tuning. Model inference itself is fast. As noted in #61201: > In release builds on Linux with an Intel Core i5-13600KF, the `betlang::detect` call alone typically completes within 3 ms when processing the maximum sampled input. The main concern is the work surrounding inference. Without debouncing, rapid typing creates a snapshot and launches a background detection task on every keystroke, while the detected language may change before the user has finished typing. This change therefore adds a 200 ms debounce delay, allowing detection to run and update the language only after the user pauses. ## Testing Automated coverage verifies that short inputs remain Plain Text, sufficient Rust content is detected as Rust, replacing it with Go content triggers redetection, and manually selecting Plain Text prevents subsequent automatic changes. Restoration coverage verifies that a stored language keeps detection disabled, while an empty language-less untitled buffer resumes detection. Beyond the automated tests, I manually tested automatic language detection while editing untitled buffers. ## 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 https://github.com/user-attachments/assets/103fc731-e12e-48d6-ae89-03978f1c9d74 --- Release Notes: - Added automatic language detection for untitled buffers. --------- Co-authored-by: Max Stevens <maxstevens2708@gmail.com> Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com> |
||
|
|
a6ffd72192 |
Delay-load ETW profiling DLLs (#62647)
Since we're here, improve the UX by prompting for a path when you save rather than when recording begins. Fixes #62334 Release Notes: - N/A |
||
|
|
01acd0ee8e |
Improve outline fonts and colors (#63325)
Closes https://github.com/zed-industries/zed/issues/58580 * Outline modal and panel now use buffer fonts for the contents: <img width="1728" height="1117" alt="modal" src="https://github.com/user-attachments/assets/5e0ef6e3-be39-4949-bc32-7087a51a02ec" /> <img width="1728" height="1092" alt="panel" src="https://github.com/user-attachments/assets/5cf9edbf-5ff3-402d-a2ca-bc915bd10e8e" /> * Gutter colors are now fall-backed to tree-sitter better, if no semantic tokens could be retrieved due to multi buffer shenanigans: <img width="1728" height="426" alt="gutter" src="https://github.com/user-attachments/assets/a175b2c8-843e-4632-b030-3edfbd350982" /> Release Notes: - Improved outline fonts and colors |
||
|
|
8166e3d7b8 |
Add folder_indicator setting to show chevron and folder icon together (#62393)
# Objective - Enable panels to show chevron and icon at the same time. - Closes #8661 ## Solution - Replaces `folder_icon` with a new `folder_indicator` which converts from a boolean to enum (`both`, `chevron`, `icon`) for the three display cases ## Testing - gpui and migration tests had been applied ## 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 ### project panel both | chevron | icon --- | --- | --- <img width="400" alt="both_project_panel" src="https://github.com/user-attachments/assets/4c21e1a1-a7a4-4471-b7de-fe867373ddbd" /> | <img width="400" alt="chevron_project_panel" src="https://github.com/user-attachments/assets/a626a82e-e5b7-470d-9d93-ed5787dc83d6" /> | <img width="400" alt="icon_project_panel" src="https://github.com/user-attachments/assets/20f9c55e-87c4-477a-b4c9-b070d6e5a1db" /> ### git panel both | chevron | icon --- | --- | --- <img width="400" alt="both_git_panel" src="https://github.com/user-attachments/assets/3dc166dd-9e63-4943-b803-df3f167876b6" /> | <img width="400" alt="chevron_git_panel" src="https://github.com/user-attachments/assets/8dfd2c10-3a68-439a-8019-4951b72e17d1" /> | <img width="400" alt="icon_git_panel" src="https://github.com/user-attachments/assets/d78a9938-91e7-4d39-a3c8-04647da67768" /> ### outline panel both | chevron | icon --- | --- | --- <img width="400" alt="both_outline_panel" src="https://github.com/user-attachments/assets/1b58c679-0bea-4600-a8ac-e800b0e8d24c" /> | <img width="400" alt="chevron_outline_panel" src="https://github.com/user-attachments/assets/0a9358e4-ec89-40d8-8d5e-a53b784ed30a" /> | <img width="400" alt="icon_outline_panel" src="https://github.com/user-attachments/assets/d8bf5199-5a8c-4de0-b516-00247e6531a5" /> --- Release Notes: - Added a `folder_indicator` setting that can show the disclosure chevron and folder icon at the same time in the project, outline, and git panels. --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev> |
||
|
|
1e2e422c7b |
Fix settings schema missing extension-provided LSP settings on remote (#62355)
## Objective Fixes an issue where language servers provided by extensions are not included in the settings schemas served by remote servers. When connecting to a remote server via the `open_remote_project_with_existing_connection` flow (dev servers, multi-workspace reopen, git worktree picker), setup-N servers never received any extension sync, so their schemas omitted extension-provided language servers, breaking language support for remote development. ## Solution Three changes ensure that language servers provided by extensions are included in the settings schemas served by remote servers: 1. **Register connections opened via `open_remote_project_with_existing_connection` with the extension store**: dev servers, multi-workspace reopen, and the git worktree picker now register their connections with the extension store so that extensions are synced to those servers. Previously only the `open_remote_project` flow did this, so setup-N servers never received any extension sync and their schemas omitted extension language servers. 2. **Emit `ExtensionsInstalledChanged` from `HeadlessExtensionStore` after sync and install complete**: this allows the remote process to invalidate its cached settings schemas. The local `ExtensionStore` already emitted this event; without it, the remote schema cache stayed stale for the lifetime of the server process. 3. **Include available LSP adapters in the project settings schema**: this matches the user settings schema (this was fixed for `settings` in #46766 but never applied to `project_settings`). ## Testing - Manually verified that after connecting to a remote server via the `open_remote_project_with_existing_connection` flow (including dev servers and the git worktree picker), extension language servers appear in the schema served by the remote server. - Verified that `ExtensionsInstalledChanged` is emitted after sync and install complete, and that the remote schema cache is correctly invalidated and rebuilt. - Verified that the `project_settings` schema includes the available LSP adapters, matching the behavior of the user settings schema. - Reviewers should focus on the multi-workspace reopen and git worktree picker flows (the two previously unregistered flows) to confirm that extension language servers are correctly synced and appear in the schema. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [ ] 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 **Server / Project** — before the fix <img width="1061" height="749" alt="image" src="https://github.com/user-attachments/assets/d6c5459f-58fb-4769-a701-f6fb317adc37" /> **Local** <img width="1119" height="449" alt="image" src="https://github.com/user-attachments/assets/fb30a1e2-74f0-4439-a25f-1022ed164074" /> --- Release Notes: - Fixed an issue where language servers provided by extensions were missing from settings schemas served by remote servers. --------- Co-authored-by: vancez <vancez@users.noreply.github.com> Co-authored-by: Kirill Bulatov <kirill@zed.dev> |
||
|
|
ec312b2701 |
Add LSP call hierarchy modal (#53239)
<img width="1128" height="953" alt="image" src="https://github.com/user-attachments/assets/b2017c0a-e25a-49d7-9342-d074014d085c" /> Closes #14203 Release Notes: - Initial Call Hierarchy support in Zed --------- Co-authored-by: Alexey Olshanskiy <gh@aohoy.dev> Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Kirill Bulatov <kirill@zed.dev> |
||
|
|
12ef40c316 |
lsp: Add client support for LSP 3.18 markdown diagnostic messages (#61030)
LSP 3.18 allows servers to send [`MarkupContent` diagnostic messages](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#diagnostic), guarded by the client capability `textDocument.diagnostic.markupMessageSupport`. - Advertise `markup_message_support` only while pull diagnostics are enabled because `textDocument.diagnostic` is the pull-model capability. LSP 3.18 currently has no equivalent capability for push diagnostics: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#diagnosticClientCapabilities https://github.com/microsoft/language-server-protocol/issues/2246 - Handle `string | MarkupContent` messages in both push and pull diagnostic paths: markdown-kind messages populate the existing `Diagnostic::markdown` field (rendered in hover popovers and the diagnostics panel), plaintext-kind markup remains plain text, and plain string messages keep going through the adapter's `diagnostic_message_to_markdown`. - Preserve server-provided markup for code actions sent back to the originating server, avoid forwarding markup diagnostics to other servers, and render diagnostic metadata without altering the server-provided markdown. - Carry the markup kind over RPC via a new optional `LspDiagnostic.markup_message_kind` proto field so remote/collab projects round-trip `MarkupContent` messages. Depends on the lsp-types change that turns `Diagnostic.message` into a `DiagnosticMessage` enum (`string | MarkupContent`): https://github.com/zed-industries/lsp-types/pull/15 Once merged, Cargo.toml can point to the upstream commit. Note that Zed already rendered some plain-string diagnostics as Markdown through language-specific adapter hooks, including `rust-analyzer`. This adds protocol-level support for diagnostics explicitly sent as LSP 3.18 `MarkupContent`, while preserving the existing adapter fallbacks. As a result, this does not introduce a new diagnostics rendering pipeline. Server-provided Markdown is routed through the existing `Diagnostic::markdown` path, with small fixes to handle Markdown-only updates and block content correctly. ## Showcase Example from [JETLS.jl](github.com/aviatesk/JETLS.jl) (a Julia language server): > Before <img width="924" height="160" alt="Screenshot 2026-07-15 at 16 05 40" src="https://github.com/user-attachments/assets/b19fe9e3-50e3-44e4-9b4d-ac8bd438d3d6" /> > After <img width="924" height="160" alt="Screenshot 2026-07-15 at 14 13 05" src="https://github.com/user-attachments/assets/359c3382-118d-4fa6-aa91-6bd3661d3d28" /> --- Release Notes: - Added support for rendering LSP 3.18 Markdown diagnostic messages from language servers. --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Kirill Bulatov <mail4score@gmail.com> |
||
|
|
7ecab315fb |
Fix project search holding a reference to closed unsaved files (#61677)
# Objective Fixes #28398 ## Solution This issue was occurring because `ProjectSearch` stored `Entity<MultiBuffer>` with has reference counted pointers to underlying buffers The function `remove_deleted_buffers` is renamed to `remove_stale_buffers` and it now also checks for buffers which do not have a file associated with them and are closed. Then, it removes them from `Entity<MultiBuffer>` stored in ProjectSearch. This function is also called in again when workspace is upgraded. ## Testing Bug being fixed was manually verified. ## 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 - [x] Performance impact has been considered and is acceptable Release Notes: - Fixed project search retaining results from closed untitled buffers. --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev> Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
|
ac099b4a80 |
Bump Zed to v1.19.0 (#63253)
Release Notes: - N/A Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
|
34241d5fc8 |
Reduce LLVM IR bloat (#63232)
Cuts serde monomorphization in settings_content: both parse entry points
now share one deserializer instantiation, and the flatten-heavy settings
structs deserialize through a small manual routing macro instead of
serde's Content buffering.
Parsed values seem to be unchanged; JSON schema and serialization
derives are untouched.
`cargo llvm-lines -p settings_content`:
Before (
|
||
|
|
c595091b0a |
Bump dependencies to dedupe the crate graph (#63231)
Deduplicates crates with different versions from the graph, drops unused features. `cargo tree -d duplicate` listing: 160 -> 112 lines. <details> <summary>Deduplicated list</summary> ``` base64 (v0.22.1, v0.21.7 -> v0.22.1) convert_case (v0.11.0, v0.10.0, v0.8.0 -> v0.11.0, v0.10.0) core-foundation (v0.10.0, v0.9.4 -> v0.10.0) cssparser (v0.36.0, v0.35.0 -> v0.37.0, v0.36.0) fancy-regex (v0.18.0, v0.16.2 -> v0.19.0) fixedbitset (v0.5.7, v0.4.2 -> v0.5.7) h2 (v0.4.12, v0.3.27 -> v0.4.12) heck (v0.5.0, v0.4.1, v0.3.3 -> v0.5.0, v0.4.1) html5ever (v0.39.0, v0.35.0 -> v0.39.0) hyper (v1.7.0, v0.14.32 -> v1.7.0) hyper-rustls (v0.27.9, v0.24.2 -> v0.27.9) mach2 (v0.6.0, v0.5.0, v0.4.3 -> v0.6.0, v0.5.0) markup5ever (v0.39.0, v0.35.0 -> v0.39.0) phf (v0.13.1, v0.12.1, v0.11.3 -> v0.13.1, v0.11.3) phf_codegen (v0.13.1, v0.11.3 -> v0.13.1) phf_generator (v0.13.1, v0.12.1, v0.11.3 -> v0.13.1, v0.11.3) phf_macros (v0.13.1, v0.12.1, v0.11.3 -> v0.13.1, v0.11.3) phf_shared (v0.13.1, v0.12.1, v0.11.3 -> v0.13.1, v0.11.3) prost (v0.12.6, v0.9.0 -> v0.14.4) prost-build (v0.12.6, v0.9.0 -> v0.14.4) prost-derive (v0.12.6, v0.9.0 -> v0.14.4) prost-types (v0.12.6, v0.9.0 -> v0.14.4) rustix (v1.1.4, v0.38.44 -> v1.1.4) rustls (v0.23.40, v0.21.12 -> v0.23.40) rustls-native-certs (v0.8.3, v0.6.3 -> v0.8.3) rustls-pemfile (v2.2.0, v1.0.4 -> v2.2.0) rustls-webpki (v0.103.13, v0.101.7 -> v0.103.13) security-framework (v3.5.1, v2.11.1 -> v3.5.1) socket2 (v0.6.3, v0.5.10 -> v0.6.3) string_cache (v0.9.0, v0.8.9 -> v0.9.0) string_cache_codegen (v0.6.1, v0.5.4 -> v0.6.1) strum (v0.28.0, v0.27.2 -> v0.28.0) strum_macros (v0.28.0, v0.27.2 -> v0.28.0) tendril (v0.5.1, v0.4.3 -> v0.5.1) tokio-rustls (v0.26.4, v0.24.1 -> v0.26.4) tungstenite (v0.28.0, v0.27.0 -> v0.28.0) web_atoms (v0.2.6, v0.1.3 -> v0.2.6) which (v6.0.3, v4.4.2 -> v8.0.5) ``` </details> Release Notes: - N/A |
||
|
|
1475887faf |
Enable project search on type by default (#62506)
Closes https://github.com/zed-industries/zed/issues/9318 Most of the diff is tests. Notable behavior changes during this mode, compared to current mode: * unsaved changes in multi buffer won't spawn any "save or not" pop-ups during typing — submitting the query still does it, as before. Unsaved files will stay so after being sorted out on typing: we cannot save them by default as file-less buffers need a save modal; Zed should already be able to persist and restore such changes on restart. * gutter may jump during search, if new excerpts with large line numbers appear during query input — yet it would not shrink back to avoid excessive flickering and rewraps Release Notes: - Enabled project search on type by default (use `{ "search": { "search_on_type": false } }` to restore the previous behavior) |
||
|
|
4ca9005579 |
Bump tree-sitter to 0.27 and wasmtime to 48.0 (#63169)
Release Notes: - N/A |
||
|
|
5a2039b2fd |
Preserve language model provider rejection details (#63095)
Language model providers can reject a request inside an otherwise successful response stream. Those failures were represented by overlapping completion-error variants and provider-specific code enums, and OpenAI Responses errors such as `cyber_policy` fell through to `Other`. Agent sessions consequently retried permanent provider rejections and user interfaces lost the provider's actionable message. This gives every provider-originated failure one shared representation. `ProviderRejection` preserves the provider, exact message, retry delay, raw provider code, and an HTTP status only when one was actually reported. `ProviderErrorCategory` supplies the normalized meaning used by shared UI and policy code. Provider adapters map their native wire errors into that category explicitly, so typed SDK exceptions and errors embedded in successful streams no longer fabricate HTTP statuses. Retry selection is independent from error construction. `LanguageModelCompletionError::retry_delay` owns transient classification and a bounded schedule of 5, 10, 20, then 40 seconds. A provider-supplied `retry_after` overrides that schedule. The scheduling layer adds positive jitter of up to 10%, while interactive requests and evaluation runs retain their own attempt budgets. Permanent status-less errors such as `cyber_policy` do not retry. OpenRouter also keeps its numeric body code distinct from an optional HTTP status, including for errors embedded in a stream. Testing performed: - `corgi test -p language_model_core` - `corgi test -p anthropic` (33 tests) - `corgi test -p open_ai` (77 tests) - `cargo nextest run -p open_router -p copilot_chat -p language_models_cloud -p language_models` (125 tests) - `cargo nextest run -p agent -p agent_ui` (1,153 tests; 11 skipped) - `cargo check -p open_router -p copilot_chat -p language_models_cloud -p language_models -p agent -p agent_ui` - `./script/clippy -p language_model_core -p anthropic -p open_ai -p open_router -p copilot_chat -p language_models_cloud -p language_models -p agent -p agent_ui` completed the release Clippy phase; Cargo Shear then reported the repository's existing warnings - `cargo fmt --all --check` Suggested .rules additions None. Release Notes: - Fixed permanent language model provider rejections being retried and displayed without their actionable provider message. |
||
|
|
6e2fae619c |
Update Wasmtime WASI to fix filesystem sandbox escape (#63140)
`wasmtime-wasi` was locked to 36.0.12, which resolved the vulnerable `cap-primitives` 3.4.4 release. That version is affected by a trailing-slash symlink handling issue that can bypass capability filesystem confinement. Raise the workspace's minimum `wasmtime-wasi` version to 36.0.14 and refresh the Wasmtime dependency family. This resolves `cap-primitives` to the patched 3.4.6 release while remaining on Wasmtime's existing 36.x line. Verified with `cargo check --locked -p extension_host` and by confirming the reverse dependency tree resolves `cap-primitives` 3.4.6 through `wasmtime-wasi` 36.0.14. See https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-vqjp-4c8c-hfgg Release Notes: - Fixed a potential filesystem sandbox escape when running extensions. |
||
|
|
a7e23df67b |
markdown: Restore fallback language highlighting for untagged code blocks (#63023)
Restores fallback highlights lost in https://github.com/zed-industries/zed/pull/28217 Release Notes: - N/A |
||
|
|
51a3ac29de |
extension_cli: Add basic validation for extension manifest (#59189)
This PR adds some validation for the extension manifest. Mostly, - it tests that name and description are set and non-empty - the authors-list is non-empty - the repository URL is actually a parseable URL and reachable with a 200 code Release Notes: - N/A |
||
|
|
ec18126b1d |
mermaid_render: Update merman to 0.8.0-alpha.5 (#62931)
Release Notes: - Fixed an issue where labels in mermaid diagrams would not soft-wrap correctly |
||
|
|
fe9556a11e |
gpui: Map ztracing events to browser performance APIs on web (#62898)
Makes `ztracing` spans work on the web, by mapping them to browser `performance` APIs. Since calling into JS from wasm has fairly high overhead, we instead have a dedicated reporter task that threads send timing information to. This approach significantly decreases the performance overhead of the span-capturing thread (which is usually the performance sensitive one), at the expense of: - erasing thread information for spans in the browser devtools - potentially dropping events if the bounded queue becomes full The first issue can be mitigated by some slightly more sophisticated capturing, along with a fixup script, which will come in a later PR --- Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
|
b0e37a6c18 |
Fix language server path displayed in LSP status tooltip (#62919)
# Objective Closes #52822 When hovering over the LSP status tooltip for a running language server, the binary path is displayed. Currently, this tooltip shows `LanguageServerBinary.path`. However, many language servers are executed through runtimes such as Node or Python. For example, Zed-managed `Basedpyright` produces a `LanguageServerBinary` like: ```Rust LanguageServerBinary { path: "/usr/bin/node", arguments: [ "/home/xin/.local/share/zed/languages/basedpyright/node_modules/basedpyright/langserver.index.js", "--stdio", ], env: ... } ``` In this case, only `"/usr/bin/node"` is displayed, which doesn't convey useful information about the actual language server script being executed. ## Solution There was a PR #53076 in which I was involved, and the solution there was to populate every language server adapter with a special marker for the path to be shown in the tooltip. That solution is accurate, but in order to make this solution work for extension-provided servers, the final diff became huge for a simple fix. So here, as commented in https://github.com/zed-industries/zed/pull/53076#pullrequestreview-4204849892, a guess is performed by a newly introduced function `tooltip_for_server_binary()` to get the real path to be shown. It may have some edge cases, but works for current cases and is simple to implement. ## Testing Added new unit tests, built and tested locally, with the comparision attached in the Showcase section. ## 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 For the mentioned `Basedpyright` language server case, the comparision is shown below: | Before | After | |:--:|:--:| | <img width="431" height="187" alt="before" src="https://github.com/user-attachments/assets/0611f2fe-687b-4d67-ba78-380d89ed0212" /> | <img width="582" height="185" alt="after" src="https://github.com/user-attachments/assets/6ad08720-ac53-4b2d-a72c-3febb441e2f1" /> | --- Release Notes: - Improved the LSP status tooltip to display the target script path for runtime-managed language servers |
||
|
|
282f47a544 |
Switch from cargo-machete to cargo-shear (#62643)
This results in ~110 crates being removed, and some orphaned files also. --- Release Notes: - N/A Signed-off-by: Neel <neel@zed.dev> |
||
|
|
cef06d351b |
worktree: Yield during large file decoding (#62831)
# Objective Closing a project while a large local text file is loading can be delayed because file-reading and UTF-8 streaming loops have no await points. Partially addresses #27283. ## Solution Yield between 1 MiB blocks while: - streaming UTF-8 files into a Rope - reading files handled by the fallback decoder, including BOM, UTF-16, and other non-UTF-8 encodings Release Notes: - Improved responsiveness when closing projects that are loading large text files. |
||
|
|
1861e58f98 |
gpui: Journal foreground work between frames and report hang incidents (#62779)
Zed's hang telemetry could say a hang happened, but not what the app was doing. This PR adds a foreground journal to gpui (behind the `profiler` feature): the main thread records task polls, action handlers, input dispatches, window draws, and frame presentations into a fixed-size ring, and boundary entries — a newly drawn frame's presentation, or the foreground going idle — partition that stream into activity intervals. Recording is designed to be cheap enough to ship enabled: sub-threshold task polls fold into a counter instead of individual entries, and the ring is drained in bounded chunks off the main thread. A `HangDetector` drains the journal and reports an incident for any interval containing a single event at or above the hang threshold (100ms in release), or whose cumulative foreground spend reaches a frame budget (8ms in release) — catching both one long stall and many small pieces of work that together drop a frame. Incidents serialize with phase (startup/steady), stall and active durations, busy fraction, dirty-to-present time, and up to 8 contributors in start order with nesting depth: task polls carry their spawn location, actions their names, inputs their kind. Zed batches the top 10 incidents by stall per 30 minutes plus a total incident count into a "Hang Incidents" telemetry event, flushes the remainder on quit, and drops the old per-location "Hang Report" histograms this replaces. Release Notes: - N/A |
||
|
|
582e6a5789 |
language_core: Represent supported queries using an enum (#62707)
Refactors our query loading to instead have an enum of supported queries and load the query files themselves in parallel, where possible. We will use this to warn extension authors when unsupported queries are present, as we no longer want to ship those as part of the extension. It also now enforces one file per supported query - only one extension currently utilizes this feature and was undocumented previously, so I decided in favor of removing it here, since this will help with enforcing extensions to just ship query files we actually support in the future. The extension has also been migrated so that it does not break with this effort Side-effect of this change is that we now load both embedded and external languages up to at least 10%/5% faster, since the files are now read in parallel as opposed to sequentially one by one. Release Notes: - N/A |
||
|
|
0a4a4a950f |
Bump Zed to v1.18.0 (#62882)
Release Notes: - N/A Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
|
fa00dccc42 |
Fix project path handling when connecting from Unix to Windows remotes (#62038)
# Objective Follow-up of #61374. Zed now supports Windows as a remote target, but when connecting from a Unix platform to Windows, some path handling still uses the native client's path style (Unix) to construct paths, which causes weird path displays in different areas. One of them is the project path stored in the `settings.json` file, which is related to the open path picker in the codebase: https://github.com/zed-industries/zed/blob/5e1fd392f67e27fa1da91bad43eef7db1a5dec23/crates/open_path_prompt/src/open_path_prompt.rs#L668-L679 For example, if I have a remote project at `D:\code\test_python` and want to open it in remote development, I usually use path completions, with `D:\code\` as the parent path and `test_python` as the selected candidate. Zed directly joins them using `Path::join` on the Unix platform, which results in `D:\code\/test_python`. A second thing I found is the displayed name for the git repo. The related source code is: https://github.com/zed-industries/zed/blob/5e1fd392f67e27fa1da91bad43eef7db1a5dec23/crates/title_bar/src/title_bar.rs#L262-L268 Also taking `D:\code\test_python` as an example: the passed-in `common_dir_abs_path` is `D:\code\test_python\.git`, and `repo_identity_path()` directly uses `Path::file_name()` and `Path::parent()` from the standard library to handle this: https://github.com/zed-industries/zed/blob/5e1fd392f67e27fa1da91bad43eef7db1a5dec23/crates/project/src/git_store.rs#L9956-L9965 Ideally, this function should return `D:\code\test_python`. But due to the platform mismatch, `D:\code\test_python\.git` is returned; after further processing in the title bar, we get `D:\code\test_python\` as the displayed name, while the expected display name is `test_python`. In the past, only Unix-like systems could serve as remote servers, and their path separator (`/`) is valid on Windows, so everything looked fine. But Unix does not support `\` as a valid separator — that's the root cause. We need to use `PathStyle`, which is designed for processing paths across platforms, to deal with these cases. ## Solution - Added new APIs `PathStyle::parent()` and `PathStyle::file_name()`, which serve as replacements for `Path::parent()` and `Path::file_name()` to process paths cross-platform. - Adopted the new APIs in `repo_identity_path()`, and updated the relevant call sites. - For the open path picker, use `PathStyle::join_path()` instead of `Path::join`. ## Testing The added `PathStyle::parent()` and `PathStyle::file_name()` are covered by detailed unit tests. These tests verify that the behavior matches the corresponding methods in `Path`, just independent of the host platform. For the path display issues, I built and tested manually; a comparison is attached in the Showcase section. ## 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 - [x] Performance impact has been considered and is acceptable ## Showcase <details> <summary>Click to view showcase</summary> | Content | Before | After | |:--:|:--:|:--:| |title bar|<img width="486" height="272" alt="title_bar_before" src="https://github.com/user-attachments/assets/d14d0e37-a1b8-43ab-b51b-fe9dd1b977eb" /> | <img width="406" height="274" alt="title_bar_after" src="https://github.com/user-attachments/assets/fc9193f4-d42c-47a8-a254-4ed08c806a11" /> | |path storage| <img width="337" height="264" alt="project_path_before" src="https://github.com/user-attachments/assets/3352add3-20df-43b9-8a20-10ee7d96e703" />| <img width="319" height="262" alt="project_path_after" src="https://github.com/user-attachments/assets/fa3d7feb-f393-416a-868d-85eb0af5cfb8" />| |open remote| <img width="554" height="135" alt="open_remote_before" src="https://github.com/user-attachments/assets/62983eca-22ad-472f-8333-8561cfc17357" />|<img width="562" height="176" alt="open_remote_after" src="https://github.com/user-attachments/assets/22528a6b-0e73-4a12-a825-673ba57a63da" /> | </details> ## Other things to note This PR also did a little refactoring: it moved the `PathStyle`-related tests from the `util` crate to the `path` crate, and updated the documentation to reflect that Windows can serve as a remote platform. The recent project picker also suffers from the same cross-platform bug, but it is not fixed here, because a clean fix requires dealing with database storage, unlike the direct API changes made here. I will address it in a follow-up PR. This PR looks very large, but most of the changes are the test migration and the new API implementation. I hope the unit tests and comments can offload some of the burden for reviewers. --- Release Notes: - Fixed project paths being built incorrectly when connecting from Unix machines to Windows remote servers. |
||
|
|
fa852694f4 |
Enable CSV preview for all users (#62773)
Closes #58145 Remove the `tabular-data-preview` feature flag and register CSV preview actions and the quick action bar button for every user. Also remove the now-unused `feature_flags` dependency from the CSV preview crate. Release Notes: - Added CSV preview access for all users |
||
|
|
2040e0de59 |
treesitter: Worker-pinned treesitter parsing (#62784)
Bumps the treesitter version to include https://github.com/tree-sitter/tree-sitter/pull/5851 Also makes some changes to `cx.spawn_dedicated` to make it work on web: - remove the blocking `recv` on the main thread - adds a new variant `TaskState::Rendezvous` to allow this code to synchronously return a task `TaskState::Rendezvous` is needed because of how `spawn_dedicated_thread` works: - the caller provides a callback that produces a non-`Send` `Future` on the dedicated thread - the callback is sent to the dedicated thread, executed, and the resulting `Task` is sent back to the main thread - this all happens synchronously, so that `spawn_dedicated_thread` returns a synchronous `Task` However, the blocking `recv` on the main thread traps on the main worker in the browser. This PR replaces that with a call to `recv_async`, but this requires a new `Rendezvous` variant on `TaskState` which represents "a task that it still waiting to receive the underlying handle from the dedicated thread". It also enables the `flume/spin` feature on the web, which is needed to avoid a synchronous lock acquisition in `send` (it's replaced with a spinlock). Note that `send_async` wouldn't work here because it acquires the same lock, and it's unnecessary because `send` only blocks when the channel is full, but it's an unbounded channel. --- Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
|
87324045be |
Switch to async-tar fork (#62821)
This switches to `async-tar` to point to our fork, which has a fix for a bug that is causing the Cursor ACP agent fail to download in Zed, due to Pax attributes. We will switch back as soon as https://github.com/dignifiedquire/async-tar/pull/73 is merged. Closes #62655 Release Notes: - Fixed an issue where the Cursor ACP agent would fail to start |