Release Notes:
- Fixed an issue where creating a file through the project panel with a
trailing dot in its name would duplicate the entries with and without
the dot
Co-authored by: Smit Barmase <smit@zed.dev>
Gist is we only need to block the foreground thread for reparsing if
immediate language changes are useful to the user. That is usually only
the case when they edit the buffer
Release Notes:
- Improved performance of large project searches and project diffs
Co-authored by: David Kleingeld <david@zed.dev>
The command used to run go subtests was breaking if the test contained
square brackets, for example:
```
go test . -v -run ^TestInventoryCheckout$/^\[test\]_test_checkout$
```
After a bit of testing it appears that the best way to actually resolve
this in a way supported by `go test` is to wrap this command in quotes.
As such, this commit updates the command to, considering the example
above:
```
go test . -v -run '^TestInventoryCheckout$/^\[test\]_test_checkout$'
```
We also tested escape the square brackets, using `\\\[` instead of `\[`,
but that would lead to a more complex change, so we opted for the
simpler solution of wrapping the command in quotes.
Closes#42347
Release Notes:
- Fixed command used to run Go subtests to ensure that escaped
characters don't lead to a failure in finding tests to run
Closed#33759Closed#38166
### Summary
This PR fixes the way `go test` commands are generated for **testify
suite test methods**.
Previously, only the method name was included in the `-run` flag, which
caused Go’s test runner to fail to find suite test cases.
---
### Problem
https://github.com/user-attachments/assets/e6f80a77-bcf3-457c-8bfb-a7286d44ff71
1. **Incorrect command** was generated for suite tests:
```bash
go test -run TestSomething_Success
```
This results in:
```
testing: warning: no tests to run
```
2. The correct format requires the **suite name + method name**:
```bash
go test -run ^TestFooSuite$/TestSomething_Success$
```
Without the suite prefix (`TestFooSuite`), Go cannot locate test methods
defined on a suite struct.
---
### Changes Made
* **Updated `runnables.scm`**:
* Added a new query rule for suite methods (`.*Suite` receiver types).
* Ensures only methods on suite structs (e.g., `FooSuite`) are matched.
* Tagged these with `go-testify-suite` in addition to `go-test`.
* **Extended task template generation**:
* Introduced `GO_SUITE_NAME_TASK_VARIABLE` to capture the suite name.
* Create a `TaskTemplate` for the testify suite.
* **Improved labeling**:
* Labels now show the full path (`go test ./pkg -v -run
TestFooSuite/TestSomething_Success`) for clarity.
* **Added a test** `test_testify_suite_detection`:
* Covered testify suite cases to ensure correct detection and command
generation.
---
### Impact
https://github.com/user-attachments/assets/ef509183-534a-4aa4-9dc7-01402ac32260
* **Before**: Running a suite test method produced “no tests to run.”
* **After**: Suite test methods are runnable individually with the
correct `-run` command, and full suites can still be executed as before.
### Release Notes
* Fixed generation of `go test` commands for **testify suite test
methods**.
Suite methods now include both the suite name and the method name in the
`-run` flag (e.g., `^TestFooSuite$/TestSomething_Success$`), ensuring
they are properly detected and runnable individually.
Part of reworking our installation handling to allow for multiple
different versions to be handled
Release Notes:
- Fixed pre-release lsp fetching setting not having an affect until
restarting Zed
Closes#36420
## Synopsis
The issue in #36420 is caused by #7276, which bound the appropriate
tree-sitter queries to the `@variable.member` color. However, I have
found neither this color's declaration nor its other usages in the
codebase (neither on the latest `main` nor on
79c1003b34).
Other languages use for such situations the `@property` color.
## Solution
Just change the used `@variable.member` color to the `@property` one.
Seems fully inline with the changes illustrated in #7276.
## Screenshots
<img width="856" height="465" alt="Screenshot 2025-08-28 at 13 18 38"
src="https://github.com/user-attachments/assets/9d1f3542-8749-421f-864f-959c1242cc64"
/>
<img width="837" height="462" alt="Screenshot 2025-08-28 at 13 20 08"
src="https://github.com/user-attachments/assets/36a80c22-9de9-46b1-87e3-7fdeaa62978f"
/>
## Changelog
Release Notes:
- go: Fixed highlighting of fields.
This removes around 900 unnecessary clones, ranging from cloning a few
ints all the way to large data structures and images.
A lot of these were fixed using `cargo clippy --fix --workspace
--all-targets`, however it often breaks other lints and needs to be run
again. This was then followed up with some manual fixing.
I understand this is a large diff, but all the changes are pretty
trivial. Rust is doing some heavy lifting here for us. Once I get it up
to speed with main, I'd appreciate this getting merged rather sooner
than later.
Release Notes:
- N/A
- **WIP: reorganize dispositions**
- **Introduce a LocalToolchainStore trait and use it for LspAdapter
methods**
Closes#35782Closes#27331
Release Notes:
- Python: Improved propagation of a selected virtual environment into
the LSP configuration. This should the make all language-related
features such as Go to definition or Find all references more reliable.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Lukas Wirth <lukas@zed.dev>
One killer feature for the Go runner is to execute individual subtests
within a table-test easily. Goland has had this feature forever, while
in VSCode this has been notably missing.
https://github.com/user-attachments/assets/363417a2-d1b1-43ca-8377-08ce062d6104
Release Notes:
- Added support to run Go table-test subtests.
Closes#33106
Instead of directly using `filter_text` in `StringMatchCandidate`, which
yields better results for fuzzy matching but messes up with highlighting
letters in bold, as `positions` list generated by fuzzy crate are now of
`filter_text` and not `label` shown to the user.
This PR fixes it by keeping use of `filter_range` in
`StringMatchCandidate`, which is range w.r.t to `label` shown to user.
And actually generating this `filter_range` at source by using
`filter_range` if exists.
- [x] Tests
Release Notes:
- Fixed issue where incorrect letters are marked as bold in completions.
Now, every JS/TS-related file will get their package.json script
contents added as tasks:
<img width="1020" alt="image"
src="https://github.com/user-attachments/assets/5bf80f80-fd72-4ba8-8ccf-418872895a25"
/>
To achieve that, `fn associated_tasks` from the `ContextProvider` was
made asynchronous and the related code adjusted.
Release Notes:
- Added initial `package.json` scripts task autodetection
---------
Co-authored-by: Piotr Osiewicz <piotr@zed.dev>
Parses project's package.json to better detect Jasmine, Jest, Vitest and
Mocha and `test`, `build` scripts presence.
Also tries to detect `pnpm` and `npx` as test runners, falls back to
`npm`.
https://github.com/user-attachments/assets/112d3d8b-8daa-4ba5-8cb5-2f483036bd98
Release Notes:
- Improved TypeScript task detection
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
- 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>
This is a follow up to https://github.com/zed-industries/zed/pull/14821,
which escaped `$` but not `^`.
This is fine for `bash`, but causes issues with `zsh`. This change
escapes the `^`. I tested this against `bash`, `zsh` and `fish`
I suspect such escaping would probably need to be done at some
shell-specific layer of the code, but for now it seems like the tasks
provided by the `ContextProvider` are supposed to be shell agnostic.
To reproduce the original issue:
1. Create a Go test file in a module that just contains a single test
`TestABC`.
2. Run `zsh -i -c "go test -run ^TestABC\$"` which is what Zed tries to
run when the task for a specific Go test is executed.
3. An error that there are no tests to run will be produced even though
there is a test.
4. Run `zsh -i -c "go test -run \^TestABC\$"` (note the backslash before
^).
5. The test will run successfully.
Example:
``` go
package bar
import "testing"
func TestABC(t *testing.T) {}
```
Release Notes:
- fix: Escape the ^ in the Go test -run regex to improve shell
compatibility (notably with zsh).
This is the core change:
https://github.com/zed-industries/zed/pull/26758/files#diff-044302c0d57147af17e68a0009fee3e8dcdfb4f32c27a915e70cfa80e987f765R1052
TODO:
- [x] Use AsyncFn instead of Fn() -> Future in GPUI spawn methods
- [x] Implement it in the whole app
- [x] Implement it in the debugger
- [x] Glance at the RPC crate, and see if those box future methods can
be switched over. Answer: It can't directly, as you can't make an
AsyncFn* into a trait object. There's ways around that, but they're all
more complex than just keeping the code as is.
- [ ] Fix platform specific code
Release Notes:
- N/A
Fix a bug where a GPUI macro still used `ModelContext`
Rename `AsyncAppContext` -> `AsyncApp`
Rename update_model, read_model, insert_model, and reserve_model to
update_entity, read_entity, insert_entity, and reserve_entity
Release Notes:
- N/A
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>
Part of https://github.com/zed-industries/zed/issues/22606
Before, `tsdk_path` for vtsls and typescript-language-server
unconditionally set a `tsdk`/`tsserver` property for the corresponding
language server, even if there were no such directory at all.
Instead, make the corresponding code to omit such property if it was not
found on the FS.
Release Notes:
- Fixed "The path /.../tsserver.js doesn't point to a valid tsserver
install. Falling back to bundled TypeScript version." pop-up appearing
Based on the python https://github.com/zed-industries/zed/issues/21452
and PR https://github.com/zed-industries/zed/pull/22587
I found the same problem with go on windows.
Describe the bug / provide steps to reproduce it
Language server error: gopls
The system cannot find the file specified. (os error 2)
-- stderr--
[ERROR project::lsp_store] Failed to start language server "gopls": The
system cannot find the file specified. (os error 2)
[ERROR project::lsp_store] server stderr: ""
Environment
Windows 11
Go
Release Notes:
- Windows: Fixed `gopls` path construction on Windows 11.
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Closes#8071
Release Notes:
- Changed the Go integration to check whether an existing `gopls` was compiled for the current `go` version.
Previously we cached gopls (the go language server) as a file called
`gopls_{GOPLS_VERSION}`. The go version that gopls was built with is
crucial, so we need to cache the go version as well.
It's actually super interesting and very clever; gopls uses go to parse
the AST and do all the analyzation etc. Go exposes its internals in its
standard lib (`go/parser`, `go/types`, ...), which gopls uses to analyze
the user code. So if there is a new go release that contains new
syntax/features/etc. (the libraries `go/parser`, `go/types`, ...
change), we can rebuild the same version of `gopls` with the new version
of go (with the updated `go/xxx` libraries) to support the new language
features.
We had some issues around that (e.g., range over integers introduced in
go1.22, or custom iterators in go1.23) where we never updated gopls,
because we were on the latest gopls version, but built with an old go
version.
After this PR gopls will be cached under the name
`gopls_{GOPLS_VERSION}_go_{GO_VERSION}`.
Most users do not see this issue anymore, because after
https://github.com/zed-industries/zed/pull/8188 we first check if we can
find gopls in the PATH before downloading and caching gopls, but the
issue still exists.
After #18447 was merged, I reviewed the PR code as usual. During this
review, I realized that some code was unintentionally removed when I was
resolving merge conflicts in #18447.
Sorry!
Release Notes:
- N/A
This change ensures we always run LSPs with the project environment (in
addition to any overrides they provide). This helps ensure the
environment is
set correctly on remotes where we don't load the login shell environment
and
assign it to the current process.
Also fixed the go language to use the project env to find the go
command.
Release Notes:
- Improved environment variable handling for SSH remotes
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>
In #17108, we updated `go test ./...` to run against the package
directory, to fix cases in which the top-level project is not the go
module root. However, this leads to the confusing behavior of `go test
./...` only running tests in subdirectories of the current package.
Here, we change the behavior to instead walk up the dirtree to find the
closest `go.mod`, and run the `./...` tasks relative to that directory.
This might lead to more predictable behavior for these tasks.
Also see:
https://github.com/zed-industries/zed/pull/19987#issuecomment-2450159099
Release Notes:
- Improved go test and generate `./...` commands to run against the
current go module directory rather than the current package directory
