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>
This required passing a `Context` object to `Summary` and introducing a
new `SeekDimension` trait that allows comparing two dimensions and pass
an additional context object.
All ignore files associated with ancestors of the directory currently being scanned are included in the stack. This allows us to compute ignore status for each entry as we initially scan it. If we encounter an ignored directory, we replace the stack with an "ignore all" variant that simply ignores every descendant of the ignored directory.
This is incomplete. We still need to construct an ignore stack in an appropriate state when rescanning subtrees in response to events. It also doesn't deal with individual ignore files being added, removed, or changed. I think we could potentially use the ignore stack while reconstructing the tree for this purpose.
Antonio ScandurraandMax Brunsfeld
Max BrunsfeldandAntonio Scandurra