This PR allows DAPs to define their own schema so users can see
completion items when editing their debug.json files.
Users facing this aren’t the biggest chance, but behind the scenes, this
affected a lot of code because we manually translated common fields from
Zed's config format to be adapter-specific. Now we store the raw JSON
from a user's configuration file and just send that.
I'm ignoring the Protobuf CICD error because the DebugTaskDefinition
message is not yet user facing and we need to deprecate some fields in
it.
Release Notes:
- debugger beta: Show completion items when editing debug.json
- debugger beta: Breaking change, debug.json schema now relays on what
DAP you have selected instead of always having the same based values.
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Cole Miller <m@cole-miller.net>
Co-authored-by: Cole Miller <cole@zed.dev>
https://github.com/zed-industries/zed/issues/30972 brought up another
case where our context is not enough to track the actual source of the
issue: we get a general top-level error without inner error.
The reason for this was `.ok_or_else(|| anyhow!("failed to read HEAD
SHA"))?; ` on the top level.
The PR finally reworks the way we use anyhow to reduce such issues (or
at least make it simpler to bubble them up later in a fix).
On top of that, uses a few more anyhow methods for better readability.
* `.ok_or_else(|| anyhow!("..."))`, `map_err` and other similar error
conversion/option reporting cases are replaced with `context` and
`with_context` calls
* in addition to that, various `anyhow!("failed to do ...")` are
stripped with `.context("Doing ...")` messages instead to remove the
parasitic `failed to` text
* `anyhow::ensure!` is used instead of `if ... { return Err(...); }`
calls
* `anyhow::bail!` is used instead of `return Err(anyhow!(...));`
Release Notes:
- N/A
Extensions cannot look up available port themselves, hence the new API.
With this I'm able to port our Ruby implementation into an extension.
Release Notes:
- N/A
Because we instantiated `ContextServerManager` both in `agent` and
`assistant-context-editor`, and these two entities track the running MCP
servers separately, we were effectively running every MCP server twice.
This PR moves the `ContextServerManager` into the project crate (now
called `ContextServerStore`). The store can be accessed via a project
instance. This ensures that we only instantiate one `ContextServerStore`
per project.
Also, this PR adds a bunch of tests to ensure that the
`ContextServerStore` behaves correctly (Previously there were none).
Closes#28714Closes#29530
Release Notes:
- N/A
This PR renames the variants of the `Extension` enum with delimiters
between the version number components so that it's clearer which version
of the extension API they refer to.
Release Notes:
- N/A
Closes https://github.com/zed-industries/zed/issues/14334, allowing
users to set environment variables for a language server binary like:
```json
"lsp": {
"rust-analyzer": {
"binary": {
"path": "/Users/dbarsky/.cargo/bin/rust-analyzer",
"env": {
"RA_PROFILE": "*>100"
}
},
}
}
```
The newly introduced environment variables are merged with the shell
environment. Perhaps more controversially, I've _also_ removed the
trimming/`stderr:`-prefixing of language server logs. This because
rust-analyzer has some nice, tree-shaped profiling built-in, and it
prevents us from printing profiles like this:
<details>
<img width="1147" alt="Screenshot 2025-03-20 at 12 09 14 PM"
src="https://github.com/user-attachments/assets/b7066651-6394-492b-b745-906c66d3c7b2"
/>
</details>
Release Notes:
- Added the ability to set a language server's environment variables.
- Removed the `stderr`-prefix of a language server's stderr logs.
### DISCLAIMER
> As of 6th March 2025, debugger is still in development. We plan to
merge it behind a staff-only feature flag for staff use only, followed
by non-public release and then finally a public one (akin to how Git
panel release was handled). This is done to ensure the best experience
when it gets released.
### END OF DISCLAIMER
**The current state of the debugger implementation:**
https://github.com/user-attachments/assets/c4deff07-80dd-4dc6-ad2e-0c252a478fe9https://github.com/user-attachments/assets/e1ed2345-b750-4bb6-9c97-50961b76904f
----
All the todo's are in the following channel, so it's easier to work on
this together:
https://zed.dev/channel/zed-debugger-11370
If you are on Linux, you can use the following command to join the
channel:
```cli
zed https://zed.dev/channel/zed-debugger-11370
```
## Current Features
- Collab
- Breakpoints
- Sync when you (re)join a project
- Sync when you add/remove a breakpoint
- Sync active debug line
- Stack frames
- Click on stack frame
- View variables that belong to the stack frame
- Visit the source file
- Restart stack frame (if adapter supports this)
- Variables
- Loaded sources
- Modules
- Controls
- Continue
- Step back
- Stepping granularity (configurable)
- Step into
- Stepping granularity (configurable)
- Step over
- Stepping granularity (configurable)
- Step out
- Stepping granularity (configurable)
- Debug console
- Breakpoints
- Log breakpoints
- line breakpoints
- Persistent between zed sessions (configurable)
- Multi buffer support
- Toggle disable/enable all breakpoints
- Stack frames
- Click on stack frame
- View variables that belong to the stack frame
- Visit the source file
- Show collapsed stack frames
- Restart stack frame (if adapter supports this)
- Loaded sources
- View all used loaded sources if supported by adapter.
- Modules
- View all used modules (if adapter supports this)
- Variables
- Copy value
- Copy name
- Copy memory reference
- Set value (if adapter supports this)
- keyboard navigation
- Debug Console
- See logs
- View output that was sent from debug adapter
- Output grouping
- Evaluate code
- Updates the variable list
- Auto completion
- If not supported by adapter, we will show auto-completion for existing
variables
- Debug Terminal
- Run custom commands and change env values right inside your Zed
terminal
- Attach to process (if adapter supports this)
- Process picker
- Controls
- Continue
- Step back
- Stepping granularity (configurable)
- Step into
- Stepping granularity (configurable)
- Step over
- Stepping granularity (configurable)
- Step out
- Stepping granularity (configurable)
- Disconnect
- Restart
- Stop
- Warning when a debug session exited without hitting any breakpoint
- Debug view to see Adapter/RPC log messages
- Testing
- Fake debug adapter
- Fake requests & events
---
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Anthony <anthony@zed.dev>
Co-authored-by: Piotr Osiewicz <peterosiewicz@gmail.com>
Co-authored-by: Piotr <piotr@zed.dev>
This PR adds support for capabilities for the extension process API.
In order to use the process API, an extension must declare which
commands it wants to use, with arguments:
```toml
[[capabilities]]
kind = "process:exec"
command = "echo"
args = ["hello!"]
```
A `*` can be used to denote a single wildcard in the argument list:
```toml
[[capabilities]]
kind = "process:exec"
command = "echo"
args = ["*"]
```
And `**` can be used to denote a wildcard for the remaining arguments:
```toml
[[capabilities]]
kind = "process:exec"
command = "ls"
args = ["-a", "**"]
```
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This PR fixes a panic that would occur when loading an extension using
v0.2.0 of the extension API after #25357 landed:
```
Thread "<unnamed>" panicked with "called `Result::unwrap()` on an `Err` value: map entry `zed:extension/github` defined twice" at crates/extension_host/src/wasm_host/wit.rs:38:31
10a6cd00e7/src/crates/extension_host/src/wasm_host/wit.rs (L38) (may not be uploaded, line may be incorrect if files modified)
0: backtrace::backtrace::libunwind::trace
at /Users/maxdeviant/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/backtrace/libunwind.rs:116:5
backtrace::backtrace::trace_unsynchronized
at /Users/maxdeviant/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/backtrace/mod.rs:66:5
1: backtrace::backtrace::trace
at /Users/maxdeviant/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/backtrace/mod.rs:53:14
2: backtrace::capture::Backtrace::create
at /Users/maxdeviant/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/capture.rs:292:9
3: backtrace::capture::Backtrace::new
at /Users/maxdeviant/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/capture.rs:257:22
4: zed::reliability::init_panic_hook::{{closure}}
at /Users/maxdeviant/projects/zed/crates/zed/src/reliability.rs:56:29
5: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/alloc/src/boxed.rs:2084:9
std::panicking::rust_panic_with_hook
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:808:13
6: std::panicking::begin_panic_handler::{{closure}}
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:674:13
7: std::sys::backtrace::__rust_end_short_backtrace
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sys/backtrace.rs:168:18
8: rust_begin_unwind
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:665:5
9: core::panicking::panic_fmt
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/panicking.rs:74:14
10: core::result::unwrap_failed
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/result.rs:1679:5
11: core::result::Result<T,E>::unwrap
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/result.rs:1102:23
extension_host::wasm_host::wit::new_linker
at /Users/maxdeviant/projects/zed/crates/extension_host/src/wasm_host/wit.rs:38:5
12: extension_host::wasm_host::wit::since_v0_2_0::linker::{{closure}}
at /Users/maxdeviant/projects/zed/crates/extension_host/src/wasm_host/wit/since_v0_2_0.rs:43:9
13: std::sync::once_lock::OnceLock<T>::get_or_init::{{closure}}
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sync/once_lock.rs:276:50
14: std::sync::once_lock::OnceLock<T>::initialize::{{closure}}
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sync/once_lock.rs:483:19
15: std::sync::once::Once::call_once_force::{{closure}}
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sync/once.rs:217:40
16: std::sys::sync::once::queue::Once::call
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sys/sync/once/queue.rs:183:21
17: std::sync::once::Once::call_once_force
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sync/once.rs:217:9
18: std::sync::once_lock::OnceLock<T>::initialize
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sync/once_lock.rs:482:9
19: std::sync::once_lock::OnceLock<T>::get_or_try_init
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sync/once_lock.rs:364:9
20: std::sync::once_lock::OnceLock<T>::get_or_init
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sync/once_lock.rs:276:15
21: extension_host::wasm_host::wit::since_v0_2_0::linker
at /Users/maxdeviant/projects/zed/crates/extension_host/src/wasm_host/wit/since_v0_2_0.rs:42:5
22: extension_host::wasm_host::wit::Extension::instantiate_async::{{closure}}
at /Users/maxdeviant/projects/zed/crates/extension_host/src/wasm_host/wit.rs:122:17
23: extension_host::wasm_host::WasmHost::load_extension::{{closure}}
at /Users/maxdeviant/projects/zed/crates/extension_host/src/wasm_host.rs:385:14
24: <core::pin::Pin<P> as core::future::future::Future>::poll
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/future/future.rs:123:9
25: async_task::raw::RawTask<F,T,S,M>::run
at /Users/maxdeviant/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.7.1/src/raw.rs:557:17
26: async_task::runnable::Runnable<M>::run
at /Users/maxdeviant/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.7.1/src/runnable.rs:781:18
27: gpui::platform::mac::dispatcher::trampoline
at /Users/maxdeviant/projects/zed/crates/gpui/src/platform/mac/dispatcher.rs:106:5
28: <unknown>
29: <unknown>
30: <unknown>
31: _pthread_mach_thread_np
```
We don't need the added `add_to_linker` calls anymore.
Release Notes:
- N/A
I didn't update it to 0.25 because its Wasm support seems to be
partially broken due to
https://github.com/tree-sitter/tree-sitter/pull/3938: it didn't
introduce a check that the Wasm module's ABI is new enough to include
supertype info while parsing it, and so in the case where it isn't it
ends up interpreting random bytes as the number of supertypes, causing
out-of-bounds memory accesses.
Closes#24489
Release Notes:
- Fixed a rare crash during syntax highlighting
There's still a bit more work to do on this, but this PR is compiling
(with warnings) after eliminating the key types. When the tasks below
are complete, this will be the new narrative for GPUI:
- `Entity<T>` - This replaces `View<T>`/`Model<T>`. It represents a unit
of state, and if `T` implements `Render`, then `Entity<T>` implements
`Element`.
- `&mut App` This replaces `AppContext` and represents the app.
- `&mut Context<T>` This replaces `ModelContext` and derefs to `App`. It
is provided by the framework when updating an entity.
- `&mut Window` Broken out of `&mut WindowContext` which no longer
exists. Every method that once took `&mut WindowContext` now takes `&mut
Window, &mut App` and every method that took `&mut ViewContext<T>` now
takes `&mut Window, &mut Context<T>`
Not pictured here are the two other failed attempts. It's been quite a
month!
Tasks:
- [x] Remove `View`, `ViewContext`, `WindowContext` and thread through
`Window`
- [x] [@cole-miller @mikayla-maki] Redraw window when entities change
- [x] [@cole-miller @mikayla-maki] Get examples and Zed running
- [x] [@cole-miller @mikayla-maki] Fix Zed rendering
- [x] [@mikayla-maki] Fix todo! macros and comments
- [x] Fix a bug where the editor would not be redrawn because of view
caching
- [x] remove publicness window.notify() and replace with
`AppContext::notify`
- [x] remove `observe_new_window_models`, replace with
`observe_new_models` with an optional window
- [x] Fix a bug where the project panel would not be redrawn because of
the wrong refresh() call being used
- [x] Fix the tests
- [x] Fix warnings by eliminating `Window` params or using `_`
- [x] Fix conflicts
- [x] Simplify generic code where possible
- [x] Rename types
- [ ] Update docs
### issues post merge
- [x] Issues switching between normal and insert mode
- [x] Assistant re-rendering failure
- [x] Vim test failures
- [x] Mac build issue
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Joseph <joseph@zed.dev>
Co-authored-by: max <max@zed.dev>
Co-authored-by: Michael Sloan <michael@zed.dev>
Co-authored-by: Mikayla Maki <mikaylamaki@Mikaylas-MacBook-Pro.local>
Co-authored-by: Mikayla <mikayla.c.maki@gmail.com>
Co-authored-by: joão <joao@zed.dev>
This PR factors the tool definitions out of the `assistant` crate so
that they can be shared between `assistant` and `assistant2`.
`ToolWorkingSet` now lives in `assistant_tool`. The tool definitions
themselves live in `assistant_tools`, with the exception of the
`ContextServerTool`, which has been moved to the `context_server` crate.
As part of this refactoring I needed to extract the
`ContextServerSettings` to a separate `context_server_settings` crate so
that the `extension_host`—which is referenced by the `remote_server`—can
name the `ContextServerSettings` type without pulling in some undesired
dependencies.
Release Notes:
- N/A
This PR overhauls extension registration in order to make it more
modular.
The `extension` crate now contains an `ExtensionHostProxy` that can be
used to register various proxies that the extension host can use to
interact with the rest of the system.
There are now a number of different proxy traits representing the
various pieces of functionality that can be provided by an extension.
The respective crates that provide this functionality can implement
their corresponding proxy trait in order to register a proxy that the
extension host will use to register the bits of functionality provided
by the extension.
Release Notes:
- N/A
This PR updates the extension context server registration to go through
the `Extension` trait for interacting with extensions rather than going
through the `WasmHost` directly.
Release Notes:
- N/A
This PR updates the `ExtensionLspAdapter` to go through the `Extension`
trait for interacting with extensions rather than going through the
`WasmHost` directly.
Release Notes:
- N/A
This PR extracts the `ExtensionSlashCommand` implementation to the
`assistant_slash_command` crate.
The slash command related methods have been added to the `Extension`
trait. We also create separate data types for the slash command data
within the `extension` crate so that we can talk about them without
depending on the `extension_host` or `assistant_slash_command`.
Release Notes:
- N/A
This PR decouples the extension `Worktree` resource from the
`LspAdapterDelegate`.
We now have a `WorktreeDelegate` trait that corresponds to the methods
on the resource.
We then create a `WorktreeDelegateAdapter` that can wrap an
`LspAdapterDelegate` and implement the `WorktreeDelegate` trait.
Release Notes:
- N/A
This PR extracts the `ExtensionIndexedDocsProvider` implementation to
the `indexed_docs` crate.
To achieve this, we introduce a new `Extension` trait that provides an
abstracted interface for calling an extension. This trait resides in the
`extension` crate, which has minimal dependencies and can be depended on
by other crates, like `indexed_docs`.
We're then able to implement the `ExtensionIndexedDocsProvider` without
having any knowledge of the Wasm-specific internals of the extension
system.
Release Notes:
- N/A
This PR exposes context server settings to extensions.
Extensions can use `ContextServerSettings::for_project` to get the
context server settings for the current project.
The `experimental.context_servers` setting has been removed and replaced
with the `context_servers` setting (which is now an object instead of an
array).
Release Notes:
- N/A
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
This fixes the issue of multiple language servers showing up as `node`
in the language server logs dropdown.
It does this by changing `language_server.name()` to return the
adapter's name, not the binary name, and changing types to make sure
that we always use this.
Release Notes:
- Fixed language server names showing up only as `"node"`
---------
Co-authored-by: Sam Rose <hello@samwho.dev>
Co-authored-by: Bennet <bennet@zed.dev>
This PR adds support for context servers provided by extensions.
To provide a context server from an extension, you need to list the
context servers in your `extension.toml`:
```toml
[context_servers.my-context-server]
```
And then implement the `context_server_command` method to return the
command that will be used to start the context server:
```rs
use zed_extension_api::{self as zed, Command, ContextServerId, Result};
struct ExampleContextServerExtension;
impl zed::Extension for ExampleContextServerExtension {
fn new() -> Self {
ExampleContextServerExtension
}
fn context_server_command(&mut self, _context_server_id: &ContextServerId) -> Result<Command> {
Ok(Command {
command: "node".to_string(),
args: vec!["/path/to/example-context-server/index.js".to_string()],
env: Vec::new(),
})
}
}
zed::register_extension!(ExampleContextServerExtension);
```
Release Notes:
- N/A
This contains the main changes to the extensions crate from #20049. The
primary goal here is removing dependencies that we can't include on the
remote.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Marshall <marshall@zed.dev>
This PR renames the `extension` crate to `extension_host`.
This is to free up the name so that we can create a smaller-scoped
`extension` crate.
Release Notes:
- N/A
