Due to using anyhow here, we otherwise lose the relevant error and just
surface a fairly useless error message.
Intentionally not doing this for `extension.json` parsing since that is
deprecated.
Release Notes:
- N/A
Closes #ISSUE
Improves the efficiency of our interactions with the Zed language
server. Previously, on startup and after every workspace configuration
changed notification, we would send >1MB of JSON Schemas to the JSON
LSP. The only reason this had to happen was due to the case where an
extension was installed that would result in a change to the JSON schema
for settings (i.e. added language, theme, etc).
This PR changes the behavior to use the URI LSP extensions of
`vscode-json-language-server` in order to send the server URI's that it
can then use to fetch the schemas as needed (i.e. the settings schema is
only generated and sent when `settings.json` is opened. This brings the
JSON we send to on startup and after every workspace configuration
changed notification down to a couple of KB.
Additionally, using another LSP extension request we can notify the
server when a schema has changed using the URI as a key, so we no longer
have to send a workspace configuration changed notification, and the
schema contents will only be re-requested and regenerated if the schema
is in use.
Release Notes:
- Improved the efficiency of communication with the builtin JSON LSP.
JSON Schemas are no longer sent to the JSON language server in their
full form. If you wish to view a builtin JSON schema in the language
server info tab of the language server logs (`dev: open language server
logs`), you must now use the `editor: open url` action with your cursor
over the URL that is sent to the server.
- Made it so that Zed urls (`zed://...`) are resolved locally when
opened within the editor instead of being resolved through the OS. Users
who could not previously open `zed://*` URLs in the editor can now do so
by pasting the link into a buffer and using the `editor: open url`
action (please open an issue if this is the case for you!).
---------
Co-authored-by: Michael <michael@zed.dev>
std commands can block for an arbitrary duration and so runs risk of
blocking tasks for too long. This replaces all such uses where sensible
with async processes.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes https://github.com/zed-industries/zed/issues/38690Closes#37353
### Background
On Windows, paths are normally separated by `\`, unlike mac and linux
where they are separated by `/`. When editing code in a project that
uses a different path style than your local system (e.g. remoting from
Windows to Linux, using WSL, and collaboration between windows and unix
users), the correct separator for a path may differ from the "native"
separator.
Previously, to work around this, Zed converted paths' separators in
numerous places. This was applied to both absolute and relative paths,
leading to incorrect conversions in some cases.
### Solution
Many code paths in Zed use paths that are *relative* to either a
worktree root or a git repository. This PR introduces a dedicated type
for these paths called `RelPath`, which stores the path in the same way
regardless of host platform, and offers `Path`-like manipulation APIs.
RelPath supports *displaying* the path using either separator, so that
we can display paths in a style that is determined at runtime based on
the current project.
The representation of absolute paths is left untouched, for now.
Absolute paths are different from relative paths because (except in
contexts where we know that the path refers to the local filesystem)
they should generally be treated as opaque strings. Currently we use a
mix of types for these paths (std::path::Path, String, SanitizedPath).
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Peter Tripp <petertripp@gmail.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
This PR removes the `/docs` slash command.
We never fully shipped this—with it requiring explicit opt-in via a
setting—and it doesn't seem like the feature is needed in an agentic
world.
Release Notes:
- Removed the `/docs` slash command.
Fixes an issue that caused Windows to fail when removing extension's
directories, as Zed had never stop any related processes.
Now:
* Zed shuts down and waits until the end when the language servers are
shut down
* Adds `impl Drop for WasmExtension` where does
`self.tx.close_channel();` to stop a receiver loop that holds the "lock"
on the extension's work dir.
The extension was dropped, but the channel was not closed for some
reason.
* Does more unregistration to ensure `Arc<WasmExtension>` with the `tx`
does not leak further
* Tidies up the related errors which had never reported a problematic
path before
Release Notes:
- N/A
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Smit <smit@zed.dev>
Closes#33039
This PR fixes a bug which causes the newest versions of the Biome and
Tombi extensions to not work with older Zed versions.
The bug occurs because in #32822, the type of the debug adapter and
debug locators was changed from a Vec to a BTreeMap. However, these
fields were already introduced much earlier in Zed, which now causes the
de-serialization of the `extension.toml` to fail for older Zed versions.
Any extension compiled with the newest extension CLI bumped in
https://github.com/zed-industries/extensions/pull/2866 will not work
with older Zed versions prior to v0.191.
By adding this change and bumping the extension CLI again, this could be
prevented. On de-serialization, we would just fallback to either a Vec
for versions prior to v0.190 or a BTreeMap after. Feel free to let me
know what you think here.
Release Notes:
- N/A
We'll now clean up DAP locators for unloaded extensions and load schemas
proper
I can now load a custom Ruby extensions with all bells and whistles and
use it as my debugger.
Release Notes:
- N/A
- DAP schemas will be stored in `debug_adapters_schemas` subdirectory in
extension work dir.
- Added Debug Config integration and such.
Release Notes:
- N/A
Cleans things up now that wasm32-wasip2 is a supported target.
Before we merge, I will need to test against the current extensions to
make sure this is fine.
However, since our wit world isn't using any wasi package imports, this
shouldn't be a breaking change.
Release Notes:
- N/A
We now actually call dap_schema provided by extensions instead of
defaulting to a null `serde_json::Value`. We still need to update the
Json LSP whenever a new dap is installed.
Release Notes:
- N/A
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
Precursor to other optimizations, but this already gets us a big
improvement.
Wasm compilation can easily be parallelized, and with all of the cores
on my M4 Max this already gets us an 86% improvement, bringing loading
an extension down to <9ms.
Not all setups will see this much improvement, but it will use the cores
available (it just uses rayon under the hood like we do elsewhere).
Since we load extensions in sequence, this should have a nice impact for
users with a lot of extensions.
#### Before
```
Benchmarking load: Warming up for 3.0000 s
Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 6.5s, or reduce sample count to 70.
load time: [64.859 ms 64.935 ms 65.027 ms]
Found 8 outliers among 100 measurements (8.00%)
2 (2.00%) low mild
3 (3.00%) high mild
3 (3.00%) high severe
```
#### After
```
load time: [8.8685 ms 8.9012 ms 8.9344 ms]
change: [-86.347% -86.292% -86.237%] (p = 0.00 < 0.05)
Performance has improved.
Found 2 outliers among 100 measurements (2.00%)
2 (2.00%) high mild
```
Release Notes:
- N/A
Replace dynamic downloading of WASI adapter with the provided crate.
More importantly, this makes sure we are using the same adapter version
as our version of wasmtime, which includes several fixes.
Arguably we could also at this point update to wasm32-wasip2 target and
remove this dependency as well if we want, but that might need further
testing.
Release Notes:
- N/A
- Languages now define their preferred debuggers in `config.toml`.
- `LanguageRegistry` now exposes language config even for languages that
are not yet loaded. This necessitated extension registry changes (we now
deserialize config.toml of all language entries when loading new
extension index), but it should be backwards compatible with the old
format. /cc @maxdeviant
Release Notes:
- N/A
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Anthony <anthony@zed.dev>
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 updates the snake_case check for grammar names to use `heck`
instead of `convert_case`.
`heck` correctly handles values like `d2`.
Fixes https://github.com/zed-industries/zed/issues/28583.
Release Notes:
- Updated snake_case check for grammar names in extensions.
This bumps `wasi-sdk` to version 25 and adds target architecture
conditionals.
Closes#18492
Release Notes:
- Fixed compiling dev extensions with Tree-sitter grammars on Linux
aarch64.
This adds a "workspace-hack" crate, see
[mozilla's](https://hg.mozilla.org/mozilla-central/file/3a265fdc9f33e5946f0ca0a04af73acd7e6d1a39/build/workspace-hack/Cargo.toml#l7)
for a concise explanation of why this is useful. For us in practice this
means that if I were to run all the tests (`cargo nextest r
--workspace`) and then `cargo r`, all the deps from the previous cargo
command will be reused. Before this PR it would rebuild many deps due to
resolving different sets of features for them. For me this frequently
caused long rebuilds when things "should" already be cached.
To avoid manually maintaining our workspace-hack crate, we will use
[cargo hakari](https://docs.rs/cargo-hakari) to update the build files
when there's a necessary change. I've added a step to CI that checks
whether the workspace-hack crate is up to date, and instructs you to
re-run `script/update-workspace-hack` when it fails.
Finally, to make sure that people can still depend on crates in our
workspace without pulling in all the workspace deps, we use a `[patch]`
section following [hakari's
instructions](https://docs.rs/cargo-hakari/0.9.36/cargo_hakari/patch_directive/index.html)
One possible followup task would be making guppy use our
`rust-toolchain.toml` instead of having to duplicate that list in its
config, I opened an issue for that upstream: guppy-rs/guppy#481.
TODO:
- [x] Fix the extension test failure
- [x] Ensure the dev dependencies aren't being unified by Hakari into
the main dependencies
- [x] Ensure that the remote-server binary continues to not depend on
LibSSL
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
### 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>
Because of #26562, it is now possible to subscribe to extension update
events within the LSP store, where we can then update the Schemas sent
to the JSON LSP resulting in dynamic updates to the auto-complete
suggestions and diagnostics in settings. Notably, this means newly
installed languages and (icon) themes will auto-complete correctly as
soon as the extension is installed.
Closes#15436
Release Notes:
- Fixed an issue where autocomplete suggestions and diagnostics for
languages and (icon) themes in settings would not update when the
extension with which they were added was installed or uninstalled
This PR adds a new `ExtensionEvents` event bus that can be used to
listen for extension-related events throughout the app.
Today you need to have a handle to the `ExtensionStore` (which entails
depending on `extension_host`) in order to listen for extension events.
With this change subscribers only need to depend on `extension`, which
has a leaner dependency graph.
Release Notes:
- N/A
This PR updates the `ExtensionBuilder` to require that grammar names are
written in snake_case.
The grammar names are used to construct identifiers, so we need them to
be valid C identifiers.
Release Notes:
- N/A
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 makes it so we don't log errors for missing themes or icon
themes until after the extensions have been loaded.
Currently, if you are using a theme that is defined in an extension it
is common to see one or more "theme not found" errors in the logs. This
is the result of us having to initialize the theme before the extensions
have actually finished loading.
This means that a theme that _may_ exist once extensions load is
considered non-existent before they have loaded.
To that end, we now wait until the extensions have loaded before we
start logging errors if we can't find the theme or icon theme.
Closes https://github.com/zed-industries/zed/issues/24539.
Release Notes:
- Reduced the number of "theme not found" and "icon theme not found"
errors in the logs for themes provided by extensions.
