These tests failed due to an indefinite hang in buffer.condition in the following code:
\`\`\`rust
let buffer = cx
.add_model(|cx| Buffer::new(0, cx.model_id() as u64, text).with_language(language, cx));
buffer.condition(cx, |buf, _| !buf.is_parsing()).await;
`\`\`
In both gpui1 and gpui2 \`.with_language\` spawns a task that notifies the context once it's done. The \`condition\` waits for notifications to be raised. The gist of the problem was that in gpui2, the spawned task was scheduled straight away, so we never really saw the notification with \`condition\`, causing us to wait indefinitely. This is probably a difference in test between schedulers in gpui1 and gpui2, but I kind of sidestepped the issue by spawning a condition before firing off a parsing task with \`set_language\`.
### Summary
This PR fixes a bug that @as-cii and @osiewicz saw when the on-disk
contents of files changed due to running `git checkout` at the command
line. It caused a buffer's contents to diverge from the file's on disk
contents, but the buffer to show an *unmodified* status.
I've also introduced new APIs on gpui's deterministic executor, which
make it possible to write a test that reliably triggered the bug.
### Details
The bug is triggered by the following sequence of events:
1. A buffer's file changes on disk while the buffer is *unmodified*
2. Zed reloads the new content of the file
3. Before updating the buffer itself, Zed computes a *diff* between the
buffer's current contents, and the newly-loaded contents
4. While this diff is being computed, one of two things happens:
1. the buffer changes on-disk *again*.
2. the user edits the buffer, but undoes the edit, so that the buffer
returns to an unmodified state
The bug itself was caused by a few things:
* The buffer diffing algorithm is pretty slow, because we perform a
character-wise diff
* We previously allowed multiple reload tasks to run concurrently
* When discarding an out-of-date diff, we failed to update parts of the
buffer's state (`saved_fingerprint`) which allow us to recognize that
the buffer's content differs from the file.
It was also difficult to reproduce the problem in tests, because under
deterministic execution, because it was extremely unlikely for other
tasks to make progress *after* a file had been reloaded, but *before*
the disk task has resolved. To help with testing, I introduced a pair of
executor APIs:
`spawn_labeled`, - for spawning a background task with a given *label*
`deprioritize_task` - for forcing tasks with a given label to run
*after* all other concurrent tasks.
I also made the `Model::next_event` test helper method more useful, in
that it no longer runs *until* parked in order to wait for the next
event to occur. It just steps the executor one poll at a time until the
model emits an event.
Release Notes:
- Fixed a bug that caused buffers to report incorrect modified/conflict
status when their buffers changed on disk multiple times in rapid
succession.
Antonio ScandurraandJulia Risley
Piotr OsiewiczandAntonio
Max Brunsfeld
Conrad Irwin
Mikayla
Nathan Sobo
Julia
