Per conversation with Antonio, I've suggested enabling full LTO; right
now we use a crate-local ThinLTO, which does not inline function calls
across crates.
| Configuration | Current main (788f97e) | Thin LTO | Full LTO |
|------------------|------------------------|-----------|-----------|
| Size in bytes | 158806721 | 155868753 | 111115553 |
| % of `main` size | 100% | 98.14% | 69.96% |
| Size in bytes (no debug info) | 129186657 | 127942929 | 108281345 |
Previously, all static assets were embedded into Zed using a single
`RustEmbed` struct called `Assets`, which was in a crate of its own,
also called `assets`. Many crates depended on this crate. The problem
with this situation was that changing *any* static asset file caused
almost every crate in the codebase to need recompilation (because of
recursive dependencies on `assets`).
Now, most of the assets are embedded only into the top-level `zed`
crate. A few assets (such as settings JSON files and AI prompts) are
needed in lower-level crates such as `settings` and `ai`. For these,
I've created separate `RustEmbed` structs in those specific crates,
which embed those specific sub-folders of `assets`.
The result is that now, when you change a theme file, the only crate
that needs to recompile is `zed`.
Release Notes:
- N/A
Previously, project-specific settings were not discoverable. This PR
adds a `Zed > Preferences > Local Settings` application menu command
that creates a `.zed/settings.json` at the root of your current
worktree. This command works in both local and remote projects.
Limitations:
* Currently, if you have an empty project open, the command just shows a
notification that there are no folders open.
* The JSON-schema-based autocomplete is the same in local settings files
as in your main settings, even though not all settings can be locally
customized.
Release Notes:
- Added an application menu command - `Zed > Preferences > Local
Settings` for creating a folder-specific settings file.
Following https://github.com/zed-industries/zed/pull/2559 the project
panel entries become pretty wide again. This PR tries to mitigate that
and just make some general improvements to visual density in the project
panel.
- Reduces padding around items
- Removes top margin
- Slightly reduces the height of each item
- Fixes an issue where ignored files had the wrong color chevron
Release Notes:
- Improved density of the project panel and tidied up some visual
issues.
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
For whatever reason, the optimizations of panes and workspace have
caused the terminal to notify less often then it should. This PR fixes
that oversight.
