I also fixed two bugs. Where not adding a log message to a standard breakpoint
would remove it (That shouldn't happen) and the breakpoint prompt editor not
always returning focus to the editor
The bug was caused by removing the breakpoint_set associated to a project_paths
when removing the last breakpoint in the set and there were active debug sessions.
Causing Zed to never tell active DAPs that the last breakpoint was removed.
We now only remove breakpoint_set if there's no active sessions. A better solution
would be removing breakpoint_set after sending all breakpoint requests to active DAPs.
Also, we only send initial breakpoint requests for project paths that contain breakpoints now.
Closes https://github.com/zed-industries/zed/issues/19214
Closes https://github.com/zed-industries/zed/pull/22443
Adds `resolved` property into Zed completion item data, to ensure we
resolve every completion item exactly once.
There are 2 paths for singplayer Zed, and corresponding 2 analogues for
multi player code, where resolve may happen:
* completions menu display & selection, that ends up using
`resolve_completions` in `lsp_store.rs`
* applying a completion menu entry, that ends up using
`apply_additional_edits_for_completion` in `lsp_store.rs`
Now, all local counterparts check `enabled` field before resolving and
set it to true afterwards, and reuse the same `resolve_completion_local`
method for resolving the items.
A logic for re-generating docs and item labels was moved out from the
`resolve_completion_local` method into a separate method, as
`apply_additional_edits_for_completion` does not need that, but needs
the rest of the logic for resolving.
During the extraction, I've noted that multiplayer clients are not
getting the item labels, regenerated after the resolve — as the Zed
protocol-based flow is not the exact copy of the local resolving.
To improve that, `resolve_completion_remote` needs to be adjusted, but
this change is omitted to avoid bloating the PR.
Release Notes:
- Fixed autocomplete inserting multiple imports
* WIP introduce debug session model
* Wip more refactor towards session model
* Fix some compile errors
* Move sub menu item into own struct
* Don't show client id inside selected value
* Remove unused session_id from shutdown event
* Remove clients from dap store use from sessions instead
* Fix clippy
* Add client id to received event log
* Move reconnect client work again
* Move sessions to local dap store
* Move ingore breakpoints to session model
* Move next session/client id to local store
* Remove duplicated test support only method
* Show client id first in dap log menu entry
* Show sub menu better
* Sort clients by their id
* Sort sessions by their id
* Fix configuration done race condition with sending breakpoints
@Anthony-Eid I think this fixed the race condition you noticed with the configuration done request.
So the issue is when the task is created it directly start the execution of the task itself.
So the `configuration_done` request is most of the times finished before the breakpoints are send
if you don't have a lot of breakpoints.
So instead of creating both tasks before the task is created we now create the 2 tasks right after eachother,
so we can be sure that the `configuration_done` request is send after the breakpoints are send.
```
[2024-12-25T21:51:09+01:00 DEBUG dap::client] Client 0 received event `Initialized`
[2024-12-25T21:51:09+01:00 DEBUG dap::client] Client 0 send `setBreakpoints` request with sequence_id: 3
[2024-12-25T21:51:09+01:00 DEBUG dap::client] Client 0 send `setBreakpoints` request with sequence_id: 4
[2024-12-25T21:51:09+01:00 DEBUG dap::client] Client 0 send `configurationDone` request with sequence_id: 8
[2024-12-25T21:51:09+01:00 DEBUG dap::client] Client 0 send `setBreakpoints` request with sequence_id: 9
[2024-12-25T21:51:09+01:00 DEBUG dap::client] Client 0 send `setBreakpoints` request with sequence_id: 7
[2024-12-25T21:51:09+01:00 DEBUG dap::client] Client 0 send `setBreakpoints` request with sequence_id: 5
[2024-12-25T21:51:09+01:00 DEBUG dap::client] Client 0 received response for: `setBreakpoints` sequence_id: 3
[2024-12-25T21:51:09+01:00 DEBUG dap::client] Client 0 received response for: `setBreakpoints` sequence_id: 4
[2024-12-25T21:51:09+01:00 DEBUG dap::client] Client 0 send `setBreakpoints` request with sequence_id: 6
[2024-12-25T21:51:09+01:00 DEBUG dap::client] Client 0 received response for: `configurationDone` sequence_id: 8
[2024-12-25T21:51:09+01:00 DEBUG dap::client] Client 0 received response for: `setBreakpoints` sequence_id: 9
[2024-12-25T21:51:09+01:00 DEBUG dap::client] Client 0 received response for: `setBreakpoints` sequence_id: 7
[2024-12-25T21:51:09+01:00 DEBUG dap::client] Client 0 received response for: `setBreakpoints` sequence_id: 5
[2024-12-25T21:51:09+01:00 DEBUG dap::client] Client 0 received response for: `setBreakpoints` sequence_id: 6
```
```
[2024-12-25T21:49:51+01:00 DEBUG dap::client] Client 0 received event `Initialized`
[2024-12-25T21:49:51+01:00 DEBUG dap::client] Client 0 send `setBreakpoints` request with sequence_id: 4
[2024-12-25T21:49:51+01:00 DEBUG dap::client] Client 0 send `setBreakpoints` request with sequence_id: 5
[2024-12-25T21:49:51+01:00 DEBUG dap::client] Client 0 send `setBreakpoints` request with sequence_id: 6
[2024-12-25T21:49:51+01:00 DEBUG dap::client] Client 0 send `setBreakpoints` request with sequence_id: 7
[2024-12-25T21:49:51+01:00 DEBUG dap::client] Client 0 send `setBreakpoints` request with sequence_id: 8
[2024-12-25T21:49:51+01:00 DEBUG dap::client] Client 0 send `setBreakpoints` request with sequence_id: 3
[2024-12-25T21:49:51+01:00 DEBUG dap::client] Client 0 received response for: `setBreakpoints` sequence_id: 4
[2024-12-25T21:49:51+01:00 DEBUG dap::client] Client 0 received response for: `setBreakpoints` sequence_id: 5
[2024-12-25T21:49:51+01:00 DEBUG dap::client] Client 0 received response for: `setBreakpoints` sequence_id: 6
[2024-12-25T21:49:51+01:00 DEBUG dap::client] Client 0 received response for: `setBreakpoints` sequence_id: 7
[2024-12-25T21:49:51+01:00 DEBUG dap::client] Client 0 received response for: `setBreakpoints` sequence_id: 8
[2024-12-25T21:49:51+01:00 DEBUG dap::client] Client 0 received response for: `setBreakpoints` sequence_id: 3
[2024-12-25T21:49:51+01:00 DEBUG dap::client] Client 0 send `configurationDone` request with sequence_id: 9
[2024-12-25T21:49:51+01:00 DEBUG dap::client] Client 0 received response for: `configurationDone` sequence_id: 9
```
* Move capabilities back to dapstore itself
* Fix failing remote debug panel test
* Remove capabilities on remote when client shutdown
* Move client_by_session to local store and impl multi client shutdown
* Remove unused code
* Fix clippyyy
* Rename merge capabilities method
As we don't only merge we also insert if there is no capabilities for the client yet.
* Use resolved label for debug session name
* Notify errors when start client to user
* Notify reconnect error to user
* Always shutdown all clients
We should always shutdown all clients from a single debug session when one is shutdown/terminated.
* Start work on getting dap clients to sync capabilities
* Add notify when syncing capabilities
* Remove client capabilities in handle shutdown debug client
Closes#21505. This should work if the git dir is an ancestor of the
worktree dir or vice versa.
Release Notes:
- Fixed GitHub permalink-to-line actions when worktree dir and Git dir
aren't the same
* Add step back support for DAP
The step back button is hidden because most dap implementations don't support
it.
* Add step back as global action - Thanks Remco for the advice!
* Filter step back action when not avaliable
The command used to activate the venv can still be accessed/scrolled to
if needed.
Release Notes:
- The Python virtual environment activation command is no longer shown
in the terminal output by default.
Co-authored-by: Peter Tripp <peter@zed.dev>
Fixes https://github.com/zed-industries/zed/issues/21972
This fixes two bugs:
**Bug 1**: this bug caused us to only ever load a single environment in
a multi-worktree project, thanks to this line:
```rust
if let Some(task) = self.get_environment_task.as_ref()
```
We'd only ever run a single task per project, which is wrong.
What does code does is to cache the tasks per `worktree_id`, which means
we don't even need to cache the environments again, since we can just
cache the `Shared<Task<...>>`.
**Bug 2**: we assumed that every `worktree_abs_path` is a directory,
which lead to `Failed to run direnv` log messages when opening a project
that had a worktree with a single file open (easy to reproduce: open a
normal project, open your settings, close Zed, reopen it — the settings
faile caused environments to not load)
It's fixed by checking whether the `worktree_abs_path` is an absolute
directory. Since this is always running locally, it's fine to use
`smol::fs` here instead of using our `Fs`.
Release Notes:
- Fixed shell environments not being loaded properly to be used by
language servers and terminals in case a project had multiple worktrees.
- Fixed `Failed to run direnv` messages showing up in case Zed restored
a window that contained a worktree with a single file.
https://github.com/zed-industries/zed/issues/21972
* Initial WIP for impl FollowableItem for DebugPanelItem
* Implment DebuggerThreadState proto functions
* Add Debug panel item variable list definition to zed.proto
* Add more debug panel item messages to zed.proto
* WIP
* Fix compile errors
Co-authored-by: Remco Smits <djsmits12@gmail.com>
* More WIP
Co-authored-by: Remco Smits <djsmits12@gmail.com>
* Further WIP lol
* Start working on fake adapter WIP
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
* Merge with Remco's mock debug adapter client branch
* Fix false positive clippy error
This error was a match variant not being covered when the variant wasn't possible dued
to a feature flag. I'm pretty sure this is a bug in clippy/rust-analyzer and will
open an issue on their repos
* Add todo to change in dap adapter downloads
* WIP Get variable to send during variable list
* Get variable list from/to_proto working
Note: For some reason variable entries aren't rendering even though
everything is being sent
* Fix warning messages
* Fix typo
* Impl stack from list from/to_proto for debug panel item
* Change order of set_from_proto for debug panel item
* Impl Variable list variables to/from proto funcs
* Start work on Set Debugger Panel Item event
* WIP with remco
Co-authored-by: Remco Smits <djsmits12@gmail.com>
* Get SetDebugPanelItem proto message sending and handled
Co-authored-by: Remco Smits <djsmits12@gmail.com>
* Setup UpdateDebugAdapter collab message & send live stack frame list updates
* Use proto enums instead of hardcoded integers
* Use read instead of update
* Send variable list update message each time we build the entries
* Send stack frame message when we selected the active stackframe
* Add more mappings
* Remove debug and rename method to be more inline with others
* Use the correct entries to reset
* Add tests to validate we can go and from proto ScopeVariableIndex
* Rename test
* Create UpdateAdapter ModuleList variant WIP
* Change proto conversion trait to have some types return Result enums
* Get clippy to pass
I removed some proto message we used in DebugPanelItem FollowableItem implmentation
because they were causing clippy errors and will need to be change in the near
future anyway
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
* Add debug panel flow tests
* Wip debug
* Wip fix test
Co-Authored-By: Anthony Eid <56899983+Anthony-Eid@users.noreply.github.com>
* WIP Get test_show_debug_panel to run
while the test now runs without panicing dued to parked with nothing left to run
the debug panel item is not being spawned
* Get test_show_debug_panel to pass & clean up
* Make clippy pass
* Assert debug panel item is removed when client shutdown
* Move send event back to dapstore
---------
Co-authored-by: Anthony Eid <56899983+Anthony-Eid@users.noreply.github.com>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Follow-up of https://github.com/zed-industries/zed/pull/22004
* Reuse center terminals for tasks, when requested
* Extend task templates with `RevealTarget`, moving it from
`TaskSpawnTarget` into the core library
* Use `reveal_target` instead of `target` to avoid misinterpretations in
the task template context
* Do not expose `SpawnInTerminal` to user interface, avoid it
implementing `Serialize` and `Deserialize`
* Remove `NewCenterTask` action, extending `task::Spawn` interface
instead
* Do not require any extra unrelated parameters during task resolution,
instead, use task overrides on the resolved tasks on the modal side
* Add keybindings for opening the task modal in the
`RevealTarget::Center` mode
Release Notes:
- N/A
`CodeContextMenu` is always accessed on one thread, so only `Rc`s and
`Rc<RefCell<_>>` are needed. There should be tiny performance benefits
from this. The main benefit of this is that when seeing code accessing a
`RwLock` it would be reasonable to wonder whether it will block. The
only potential downside is the potential for panics due to overlapping
borrows of the RefCells. I think this is an acceptable risk because most
errors of this nature will be local or will be caught by clippy via the
check for holding a RefCell reference over an `await`.
Release Notes:
- N/A
This fixes#21837, where CompletionsMenu fuzzy match positions were
desynchronized from completion label text. The solution is to not mutate
`match_candidates` and instead offset the highlight positions in the
rendering code.
This solution requires that the fuzzy match text not change on
completion resolution. This is a property we want anyway, since fuzzy
match text changing means items unexpectedly changing position in the
menu.
What happened:
* #21521 updated completion resolution to modify labels on resolution.
- This interacted poorly with the code
[here](341e65e122/crates/editor/src/code_context_menus.rs (L604)),
where the fuzzy match results are updated to include the full label, and
the fuzzy match result positions are offset to be in the correct place.
The fuzzy mach positions were now invalid because they were based on the
old text.
* #21705 caused completion resolution to occur more frequently. Before
this only the selected item was being resolved. This caused the panic
due to invalid positions to happen much more frequently.
Closes#21837
Release Notes:
- N/A
Before this change, we always started a new adapter but this was causing some issues:
- Infinite client starts
- Cannot start client port already in use
- Not able to start a debug session
Co-Authored-By: Anthony Eid <56899983+Anthony-Eid@users.noreply.github.com>
`Inventory::list_tasks()` in `project` crate now is ordered by task
types. Worktree tasks comes first, language tasks second and global
tasks last.
That leads to `spawn_task_with_name()` from `task_ui` crate will find
worktree task first, so it's possible to override global tasks at
project level.
* `Inventory::templates_from_settings()` splitted to
`Inventory::global_templates_from_settings()` and
`Inventory::worktree_templates_from_settings()`.
* In tests function `list_tasks()` renamed to
`list_tasks_sorted_by_last_used()`, because it call's
`Inventory::used_and_current_resolved_tasks()`. Also added
`list_tasks()` which calls `Inventory::list_tasks()`.
Closes#20987
Release Notes:
- Fix task::Spawn to search for task name in project tasks first.
Closes#20060Closes#20720Closes#19873Closes#9445
Release Notes:
- Fixed a bug where tasks would be spawned with their working directory
set to a file in some cases
- Added the ability to spawn tasks in the center pane, when spawning
from a keybinding:
```json5
[
{
// Assuming you have a task labeled "echo hello"
"ctrl--": [
"task::Spawn",
{ "task_name": "echo hello", "target": "center" }
]
}
]
```
Closes#11115
**Context**:
Consider a monorepo setup like this: the root has Prettier installed,
but the individual monorepos do not. In this case, only one Prettier
instance is used, with its installation located at the root. The
monorepos also use this same instance for formatting.
However, monorepo can have its own `.prettierignore` file, which will
take precedence over the `.prettierignore` file at the root level (if
one exists) for files in that monorepo.
<img
src="https://github.com/user-attachments/assets/742f16ac-11ad-4d2f-a5a2-696e47a617b9"
alt="prettier" width="200px" />
**Implementation**:
From the context above, we should keep ignore dir decoupled from the
Prettier instance. This means that even if the project has only one
Prettier installation (and thus a single Prettier instance), there can
still be multiple `.prettierignore` in play.
This approach also allows us to respect `.prettierignore` even when the
project does not have Prettier installed locally and instead relies on
the editor’s Prettier instance.
**Tests**:
1. No Prettier in project, using editor Prettier: Ensures
`.prettierignore` is respected even without a local Prettier
installation.
2. Monorepo with root Prettier and child `.prettierignore`: Confirms
that the child project’s ignore file is correctly used.
3. Monorepo with root and child `.prettierignore` files: Verifies the
child ignore file takes precedence over the root’s.
Release Notes:
- Added `.prettierignore` support to the Prettier integration.
Still TODO:
* [x] Factor out `start_language_server` so we can call it on register
(instead of on detect language)
* [x] Only call register in singleton editors (or when
editing/go-to-definition etc. in a multibuffer?)
* [x] Refcount on register so we can unregister when no buffer remain
* [ ] (maybe) Stop language servers that are no longer needed after some
time
Release Notes:
- Fixed language servers starting when doing project search
- Fixed high CPU usage when ignoring warnings in the diagnostics view
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Cole <cole@zed.dev>
These were silently passing after the delay in updating diagnostics was
added.
Co-Authored-By: Max <max@zed.dev>
cc @someonetoignore
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
* Move process to transport struct itself
* Add test to make sure we can send request and receive a response
* Align other handle methods
* Fix issues inside cargo.toml require test features inside the correct *-dependencies
* Remove comments that are not needed
* Add as_fake instead of downcasting
* Clean up
* Override get_binary method so we don't fail on install
* Fix false positive clippy error
This error was a match variant not being covered when the variant wasn't possible dued
to a feature flag. I'm pretty sure this is a bug in clippy/rust-analyzer and will
open an issue on their repos
* Remove not needed clone
* Panic when we receive an event/reverse request inside the test
* reuse the type of the closure
* Add a way to fake receiving events
* Oops remove fake event from different test
* Clipppyyyy
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
