Problem is, I'm trying to trust the excerpt id of the selection head,
but it's a sentinel value and not the actual excerpt id of the message.
I think we probably need to resolve to offsets instead.
The `start-local-collaboration` script opens two instances of Zed, each
logged in as a different user, and each one taking up half of the
screen. But previously, when joining a remote project as one of the
collaborators, that newly-opened window would be full screen.
Now, each instance of Zed keeps *all* of its windows on its half of the
screen. This is implemented by respecting the `ZED_WINDOW_{SIZE,BOUNDS}`
env vars, even when joining *remote* projects.
Release Notes:
- N/A
Fixes
https://linear.app/zed-industries/issue/Z-1511/thread-main-panicked-at-assertion-failed-left-==-right-left-local-0-1
Previously, when exchanging messages about buffers with a copilot
language server, we identified buffers using their **remote id**. This
caused problems when there were multiple projects open, where one or
more were remote, because buffers' remote ids are only unique within a
given project.
When you have multiple projects open, and one or more of the projects is
remote, it's pretty easy to have two buffers open with the same remote
id. In my testing, when this happened, copilot would stop working in
both buffers. But I believe that depending on the editing patterns that
occur in the two buffers, it could cause the crash reported in the
Linear issue above.
This PR changes our copilot logic to use buffers' local handle ids for
identifying them. This fixed the problems I was able to reproduce when
using copilot in both remote and local projects.
Release Notes:
- Fixed a crash that would sometimes occur when editing buffers after
having collaborated on a remote project.
This PR adds codegen from rustc to track the file and line number of
calls to `log_err()`. I haven't noticed much longer compile times on my
machine, and looking at the
[implementation](https://rustc-dev-guide.rust-lang.org/backend/implicit-caller-location.html)
it essentially adds an extra argument and secret reference pass.
However, this will show a lot more data in our logs on user machines.
Requesting review from @ForLoveOfCats, who usually knows a bunch about
this kind of thing :)
I did \*something\* Friday afternoon which changed something about my
system SDK to break the `media` crate's bindings generation. Some of the
types and consts were not being generated despite being able to prove
that they exist in the source, such as when running the header through
the preprocessor myself and feeding that through the generator. Updating
my OS, XCode, command line tools, and reinstalling Rust as well as
working from fresh clones of the repo had no effect.
Updating rust-bindgen resolved the issue and downgrading the version
back to the original version caused the issue to reappear. I'm still not
sure what happened to change the SDK but at this point with being able
to build the project again I'm not going to look a gift horse in the
mouth.
Release Notes:
- N/A
This was causing IME input to be drawn in the wrong place when there
were splits or panels in the window.
Release Notes:
- Fixed a bug that was causing IME input to sometimes be rendered in the
wrong position.
Quite literally just ran `typos --write-changes` from
https://crates.io/crates/typos. Its pretty impressive - wonder if we
should run it on CI.
Release Notes:
- N/A
* Add an `identifying_backtrace` field that only contains symbols in
*our* own codebase, which can be used for better deduplication.
* In the main backtrace, include file and line numbers for all symbols
in our codebase
* Exclude any stack frames within the panic handling/hooking system
itself, so that the top line of the backtrace is where the panic
originated in our codebase.
This should improve our panic deduplication, and also make panic reports
a bit more readable.
example:
```
{
"thread": "main",
"payload": "wtf",
"location_data": {
"file": "crates/zed/src/zed.rs",
"line": 459
},
"backtrace": [
"zed::open_log_file::{{closure}}::{{closure}}::{{closure}}",
" crates/zed/src/zed.rs:459",
"gpui::app::AppContext::spawn_internal::{{closure}}",
" crates/gpui/src/app.rs:2073",
"gpui::executor::any_local_future::{{closure}}",
" crates/gpui/src/executor.rs:1026",
"<core::pin::Pin<P> as core::future::future::Future>::poll",
"<async_task::runnable::spawn_local::Checked<F> as core::future::future::Future>::poll",
"async_task::raw::RawTask<F,T,S>::run",
"async_task::runnable::Runnable::run",
"<gpui::platform::mac::dispatcher::Dispatcher as gpui::platform::Dispatcher>::run_on_main_thread::trampoline",
" crates/gpui/src/platform/mac/dispatcher.rs:40",
"<() as objc::message::MessageArguments>::invoke",
"objc::message::platform::send_unverified",
"objc::message::send_message",
"<gpui::platform::mac::platform::MacForegroundPlatform as gpui::platform::ForegroundPlatform>::run",
" crates/gpui/src/platform/mac/platform.rs:366",
"gpui::app::App::run",
" crates/gpui/src/app.rs:251",
"Zed::main",
" crates/zed/src/main.rs:118",
"core::ops::function::FnOnce::call_once",
"std::sys_common::backtrace::__rust_begin_short_backtrace",
"std::rt::lang_start::{{closure}}",
"core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once",
"std::rt::lang_start"
],
"release_channel": "dev",
"os_name": "macOS",
"os_version": "12.6.1",
"architecture": "aarch64",
"panicked_on": 1685734744050,
"identifying_backtrace": [
"zed::open_log_file::{{closure}}::{{closure}}::{{closure}}",
"gpui::app::AppContext::spawn_internal::{{closure}}",
"gpui::executor::any_local_future::{{closure}}",
"<gpui::platform::mac::dispatcher::Dispatcher as gpui::platform::Dispatcher>::run_on_main_thread::trampoline",
"<gpui::platform::mac::platform::MacForegroundPlatform as gpui::platform::ForegroundPlatform>::run",
"gpui::app::App::run",
"Zed::main"
]
}
```
Release Notes:
N/A
* Add an 'identifying_backtrace' field that only contains symbols in our
codebase, which can be used for better deduplication.
* In the main backtrace, include file and line numbers for all symbols
in our codebase
