Lately, I've been finding Rust-analyzer unusably slow when editing large
files (like `editor_tests.rs`, or `integration_tests.rs`). When I
profile the Rust-analyzer process, I see that it sometimes saturates up
to 10 cores processing a queue of code actions requests.
Additionally, sometimes when collaborating on large files like these, we
see long delays in propagating buffer operations. I'm still not sure why
this is happening, but whenever I look at the server logs in Datadog, I
see that there are remote `CodeActions` and `DocumentHighlights`
messages being processed that take upwards of 30 seconds. I think what
may be happening is that many such requests are resolving at once, and
the responses are taking up too much of the host's bandwidth.
I think that both of these problems are caused by us sending way too
many code action and document highlight requests to rust-analyzer. This
PR adds a simple debounce between changing selections and making these
requests.
From my local testing, this debounce makes Rust-analyzer *much* more
responsive when moving the cursor around a large file like
`editor_tests.rs`.
See Linear description for the full explanation of the issue. This PR is
mostly a mechanical change, except for the one case where we do pass in
an explicit `next_id` instead of `model_id` in project.rs.
Release Notes:
- Fixed a bug where some results were not reported in project search in
presence of unnamed buffers.
### Summary
This PR introduces channels: a new way of starting collaboration
sessions. You can create channels and invite others to join them. You
can then hold a call in a channel, where any member of the channel is
free to join the call without needing to be invited.
Channels are displayed in a new panel called the collaboration panel,
which now also contains the contacts list, and the current call. The
collaboration popover has been removed from the titlebar.
For now, the channels functionality will only be revealed to staff, so
the public-facing change is just the move from the popover to the panel.
### To-do
* User-facing UI
* [x] signed-out state for collab panel
* [x] new icon for collab panel
* [x] for now, channels section only appears for zed staff
* [x] current call section styling
(https://zed-industries.slack.com/archives/C05CJUNF2BU/p1691189389988239?thread_ts=1691189120.403009&cid=C05CJUNF2BU)
* [x] Channel members
* Channels
* [x] style channel name editor
* [x] decide on a special "empty state" for the panel, when user has no
contacts
* [x] ensure channels are sorted in a consistent way (expose channel id
paths to client)
* [x] Figure out layered panels UX
* [x] Change add contacts to be the same kind of tabbed modal
* [x] race condition between channel updates and user fetches
(`ChannelStore::handle_update_contacts`)
* [x] race condition between joining channels and channel update
messages `collab::rpc::channel_updated`)
* [x] don't display mic as muted when microphone share is pending upon
first joining call
Release Notes:
- Moved the collaboration dropdown into its own panel.
- Added settings for disabling the AI assistant panel button.
- Switch to lazily initializing audio output sources
(https://github.com/zed-industries/community/issues/1840,
https://github.com/zed-industries/community/issues/1919)
I went to add in `zprofile` to the bash language config to get syntax
highlighting for it. After adding it in, Zed was still not highlighting
the file. I checked and saw that we are using `Path::extension()` in
`language_for_file()`, which [returns `None` when a file's name begins
with a
`.`](https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.extension),
such as in the case of `.zprofile`. This PR adds a custom method, with
some tests, that just tries to grab the last component in the file name
if `Path::extension` returns `None`. Not sure if `ext` is the best name,
but I can't use `extension`.
Maybe this method should be called `extension_or_hidden_file_name()`?
Release Notes:
- Fixed a bug where language detection would fail for files starting
with `.` in their names.
- Added syntax highlighting for `.zprofile` files
When editing rust code, the project diagnostics view sometimes fails to
update, so that you have to close the view and re-open it to see the
correct state.
This PR fixes one possible cause of that problem. There was an async
step in between *receiving* diagnostics from the language server and
updating the diagnostics, due to an async call to
`LspAdapter::process_diagnostics`. This could cause the following
sequence of events to happen:
1. Rust-analyzer sends us new diagnostics for a file `a.rs`
2. We call `process_diagnostics` with those diagnostics
3. Rust-analyzer sends us a `WorkDoneProgress` message, indicating that
the "flycheck" (aka `cargo check`) process has completed
4. We update the project diagnostics view due to this message.
5. The `process_diagnostics` call for `a.rs` completes
6. 💥 We have the new diagnostics for `a.rs`, but do not update the
project diagnostics view again.
This PR fixes this bug by simply making `process_diagnostics`
synchronous. There is no I/O or expensive computation happening in that
method. If we need to make it asynchronous in the future, we need to
introduce a queue that ensures that `publishDiagnostics` and
`workDoneProgress` messages are processed serially.
Release Notes:
- Fixed a bug where the project diagnostics view would sometimes fail to
update properly when using Rust-analyzer.
Instead of returning a usize for the window id, I'm instead returning a
`WindowHandle<V: View>` where `V` is the type of the window's root view.
@as-cii helped me with a cool technique using generic associated types
where methods on `WindowHandle` can return either T or Option<T>
depending on the `BorrowWindowContext::Result` associated type.
Some example usage...
```rs
let window = cx.add_window(|cx| MyView::new(cx));
let my_view = window.root(cx); // If cx is TestAppContext, returns MyView. Otherwise returns Option<MyView>, because the window could be closed.
```
This isn't insanely beneficial on its own, but I think it will help
clean up our testing story. I'm planning on making `window` more useful
in tests for laying out elements, etc.
- [x] Rework tests that call `add_window` 😅 to expect only a window in
return.
- [x] Get tests passing
- [x] 🚬 test
Max Brunsfeld