| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
This will allow testing more of the code base, as well as enable UI-
specific testing.
Debug mode builds are prohibitively slow for the tests, mostly
because of the concurrency write tests. So there is now a profile for
integration tests that sets the optimization level to 2 for a few helix
crates, and lowers the number of rounds of concurrent writes to 1000.
|
| |
|
|
|
|
| |
When force quitting, we need to block on the pending writes to ensure
that write commands succeed before exiting, and also to avoid a crash
when all the views are gone before the auto format call returns from
the LS.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
If a document is written with a new path, currently, in the event that
the write fails, the document still gets its path changed. This fixes
it so that the path is not updated unless the write succeeds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way that document writes are handled are by submitting them to the
async job pool, which are all executed opportunistically out of order. It
was discovered that this can lead to write inconsistencies when there
are multiple writes to the same file in quick succession.
This seeks to fix this problem by removing document writes from the
general pool of jobs and into its own specialized event. Now when a
user submits a write with one of the write commands, a request is simply
queued up in a new mpsc channel that each Document makes to handle its own
writes. This way, if multiple writes are submitted on the same document,
they are executed in order, while still allowing concurrent writes for
different documents.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
