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.
I'm using [convert_case](https://crates.io/crates/convert_case)
underneath the hood, which has over 35 million downloads and feels
solid.
Release Notes:
- Added commands to convert between variable name styles
([#1821](https://github.com/zed-industries/community/issues/1821)).
- `convert to kebab case`
- `convert to snake case`
- `convert to upper camel case`
- `convert to lower camel case`
- `convert to title case`
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
This element is used for the update state as well for some reason so
while we don't normally ever see this state, it is used when the status
is acting as the restart to update button
Release Notes:
- Fixed an inconsistency in the status bar update button font size.
This element is used for the update state as well for some reason so
while we don't normally ever see this state, it is used when the status
is acting as the restart to update button
I got tired of having to hack in a panic hook bypass whenever I wanted a
backtrace with line numbers. Now a dev channel build will behave more
like the default panic hook, printing a pretty traditional backtrace
message and exit with an error code instead of aborting to avoid the
annoying "Zed crashed" dialog.
I have plans to modify our panic reporting to be able to have line
numbers reported without breaking the de-duping but I haven't done that
yet.
Additionally I slightly improved what we do in threads which panic as a
result of another thread's panic.
Release Notes:
- N/A
