Our strategy for keeping excerpts in sync between the two sides of the
split diff is generally
- mutate the excerpts on the RHS
- pull out the new excerpts for the affected path from the RHS
- translate those ranges to the LHS
- update the LHS excerpts with those ranges
But this can break down when the translated ranges overlap on the LHS
despite the original ranges not overlapping on the RHS. This can happen,
for example, when a large deletion in a file crosses several excerpt
boundaries. It's rare because normally excerpt boundaries in the project
diff and branch diff are adjusted to keep entire diff hunks in view, but
we defer this for dirty files, so it's not hard to trigger it when using
the agent or editing an individual file while the diff is open in
another tab.
Release Notes:
- Fixed a panic that could occur when editing files while the project
diff or branch diff was open.
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Second attempt at fixing
https://github.com/zed-industries/zed/pull/49047, this also removes some
of the sorting hacks as they should ideally not be necessary anymore
after this fix
Release Notes:
- N/A *or* Added/Fixed/Improved ...
## Bug
**Sentry:**
[ZED-3W3](https://sentry.io/organizations/zed-dev/issues/7085300207/)
(13 events, first seen 2025-12-03)
`summaries_for_anchors` panics with "cannot seek backward" when
iterating selection anchors whose excerpt locators are no longer in
ascending order after an `update_path_excerpts` call.
### Root cause
`update_path_excerpts` merges new excerpt ranges with existing ones.
When an existing excerpt has no overlap with any new range (e.g.
`existing_range.end < new.context.start`), it is removed from the
excerpts tree but is **not** recorded in `replaced_excerpts`. Its stale
locator persists in the `excerpt_ids` tree.
Later, when a new excerpt is inserted for a different path whose locator
falls between the stale locator and another surviving excerpt,
`summaries_for_anchors` can encounter anchors in an order where it needs
to seek the cursor *backward* — violating the forward-only cursor
invariant.
Concretely, the scenario requires:
1. A path with ≥3 excerpts (E_B1, E_B2, E_B3) with anchors in E_B2 and
E_B3.
2. An `update_path_excerpts` call that keeps E_B1, **removes E_B2** (no
overlap → no `replaced_excerpts` entry), and replaces E_B3 with a new
excerpt N.
3. A new path D inserted between paths B and C, whose excerpt E_D gets a
locator between N and E_B2's stale locator.
4. Resolving the old anchors: E_B2's stale locator seeks past E_D, then
E_B3→N tries to seek backward to N — **panic**.
## Fix
In the two branches of `update_path_excerpts` where existing excerpts
are removed without being absorbed into a new range, map the removed
excerpt to the nearest surviving neighbor (the last kept or inserted
excerpt) in `replaced_excerpts`. This ensures stale anchors always remap
to a valid, correctly-ordered locator.
The two branches are:
- `existing_range.end < new.context.start` — existing excerpt falls
entirely before the next new range
- `(None, Some(...))` — no more new ranges for remaining existing
excerpts
## Verification
- A reproduction test
(`test_cannot_seek_backward_after_excerpt_replacement`) that constructs
the exact crash scenario now passes.
- Full `multi_buffer` test suite (48 tests) passes with no regressions.
- Clippy is clean.
Release Notes:
- Fixed a possible crash when updating excerpts in multibuffers
This PR reworks the (still feature-gated) side-by-side diff view to use
a different approach to representing the multibuffers on the left- and
right-hand sides.
Previously, these two multibuffers used identical sets of buffers and
excerpts, and were made to behave differently by adding a new knob to
the multibuffer controlling how diffs are displayed. Specifically, the
left-hand side multibuffer would filter out the added range of each hunk
from the excerpts using a new `FilteredInsertedHunk` diff transform, and
the right-hand side would simply not show the deleted sides of expanded
hunks. This approach has some problems:
- Line numbers, and actions that navigate by line number, behaved
incorrectly for the left-hand side.
- Syntax highlighting and other features that use the buffer syntax tree
also behaved incorrectly for the left-hand side.
In this PR, we've switched to using independent buffers to build the
left-hand side. These buffers are constructed using the base texts for
the corresponding diffs, and their lifecycle is managed by `BufferDiff`.
The red "deleted" regions on the left-hand side are represented by
`BufferContent` diff transforms, not `DeletedHunk` transforms. This
means each excerpt on the left represents a contiguous slice of a single
buffer, which fixes the above issues by construction.
The tradeoff with this new approach is that we now have to manually
synchronize excerpt ranges from the right side to the left, which we do
using `BufferDiffSnapshot::row_to_base_text_row`.
Release Notes:
- N/A
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: HactarCE <6060305+HactarCE@users.noreply.github.com>
Co-authored-by: Miguel Raz Guzmán Macedo <miguel@zed.dev>
Co-authored-by: Anthony <anthony@zed.dev>
Co-authored-by: Cameron <cameron@zed.dev>
Imitating the approach of #41829. Prevents e.g. reverting a hunk and
having that excerpt yanked out from under the cursor.
Release Notes:
- git: Improved stability of excerpts when editing in the project diff.
Tracing code is not included in normal release builds
Documents how to use them in our performance docs
Only the maps and cursors are instrumented atm
# Compile times:
current main: fresh release build (cargo clean then build --release)
377.34 secs
current main: fresh debug build (cargo clean then build )
89.31 secs
tracing tracy: fresh release build (cargo clean then build --release)
374.84 secs
tracing tracy: fresh debug build (cargo clean then build )
88.95 secs
tracing tracy: fresh release build with timings (cargo clean then build
--release --features tracing)
375.77 secs
tracing tracy: fresh debug build with timings (cargo clean then build
--features tracing)
90.03 secs
Release Notes:
- N/A
---------
Co-authored-by: localcc <work@localcc.cc>
It is easy for us to get the two fields out of sync causing weird
problems, there is no reason to have both here so.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Co-authored by: Antonio Scandurra <antonio@zed.dev>
Fixes ZED-2CQ
We were doing the binary search by buffer points, but due to await
points within this function we could end up mixing points of differing
buffer versions.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Prior we were only updating the diagnostics pane when it is either
unfocued, saved or when a disk based diagnostic run finishes (aka cargo
check). The reason for this is simple, we do not want to take away the
excerpt under the users cursor while they are typing if they manage to
fix the diagnostic. Additionally we need to prevent dropping the changed
buffer before it is saved.
Delaying updates was a simple way to work around these kind of issues,
but comes at a huge annoyance that the diagnostics pane is not actually
reflecting the current state of the world but some snapshot of it
instead making it less than ideal to work within it for languages that
do not leverage disk based diagnostics (that is not rust-analyzer, and
even for rust-analyzer its annoying).
This PR changes this. We now always live update the view but take care
to retain unsaved buffers as well as buffers that contain a cursor in
them (as well as some other "checkpoint" properties).
Release Notes:
- Improved diagnostics pane to live update when editing within its
editor
When doing a project wide search in zed on windows for `hang`, zed
starts to freeze for a couple seconds ultimately starting to error with
`Not enough quota is available to process this command.` when
dispatching windows messages. The cause for this is that we simply
overload the windows message pump due to the sheer amount of foreground
tasks we spawn when we populate the project search.
This PR is an attempt at reducing this.
Release Notes:
- Reduced hangs and stutters in large project file searches
