I am not sure I have caught all the examples of this, but in general
I think we always want to perform a `flush_fs_events` as opposed to
`next_scan_complete` when doing synchronous I/O. Indeed, the file
system may inform us about the events caused by the just-performed
I/O over multiple batches, and `next_scan_complete` may return
before seeing all of them.
Note that this also removes a few assertions which were ensuring
that, on start, a worktree's file handle wouldn't know its deleted
status, even if the file didn't exist for sure on disk. However,
now that `file` is an async API, it's possible that by the time the
`FileHandle` is resolved, `Worktree` has already completed scanning.
We test a similar behavior further along in the test where those
assertions were removed, so it felt okay to proceed without them.
Now when you call spawn in various context, you pass an FnOnce that is called with an AsyncAppContext and returns a static future. This allows you to write async code similar to how our tests work, borrowing the guts of the AsyncAppContext when needed to interact, but using normal async await semantics instead of callbacks.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
Sometimes the scan state could change so quickly that the consumer
wouldn't notice that it ever went to a scanning state before going back
to an idle state, hence never resolving.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
* Don't consider files deleted if they just haven't been scanned yet.
* Consider a buffer dirty if its file has been deleted.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
Fold ranges are exclusive, exactly like the query ranges. So if the end
of a fold coincides with the start of the query range, we shouldn't
report that fold. Analogously, if the start of a fold coincides with the
end of the query range, that fold shouldn't be reported.
Otherwise, the element never goes away because the view never goes away because the element is holding a strong reference.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
Antonio Scandurra
Max BrunsfeldandAntonio Scandurra
Nathan Sobo
