Hide platform code entirely behind App for framework users - #12
Merged
Conversation
Add an application menu with a quit command, bound to command-q
If this method is called too early, the menu bar won't be clickable on startup until the window loses focus. Calling it once the application finishes launching seems to fix the issue. See glfw/glfw#1648
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
I don't actually think it was correct to allow the future to borrow a mutable app reference. I went back to passing a wrapper around the refcell to async tests. They'll be a bit more annoying to write but also totally safe.
nathansobo
changed the title
1 task
Anthony-Eid
pushed a commit
to Anthony-Eid/zed
that referenced
this pull request
Aug 7, 2024
* Fix used wrong request args in set breakpoints request Some debug adapters depend on getting the exact data that you passed in `launch` or `attach` request. * Send correct request for stopping debug adapter I changed the name to be more in line with the request name. We now also send the correct request values on the `support_terminate_debuggee` and `support_terminate_debuggee` capabilities. * Send disconnect request for terminate threads if it does not support it * Only send configuration done request if its supported * Add disconnect icon * Only send step over request params when adapter supports it * Only send resume(continue) request params if adapter supports it * Step in only send request args if adapter supports it * Step out only send request args if adapter supports it * Step back only send request args if adapter supports it * Log error using `detach_and_log_err` instead of manually
1 task
Contributor
|
✅ Perf run succeeded! Results:
|
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
Contributor
|
🍒💥 Cherry-pick did not succeed |
rtfeldman
added a commit
that referenced
this pull request
Feb 5, 2026
…fault, cross-layer accumulation docs - Fix #11: commit_message_model doc said 'Default: true' but field is Option<LanguageModelSelection> - Fix #12: agent-settings.md said single_file_review default is false, but it's true - Fix #13: Add cross-layer accumulation docs to always_allow, always_confirm, always_deny
rtfeldman
added a commit
that referenced
this pull request
Feb 5, 2026
…blocks Refactor both migrations to iterate platform/channel keys (macos, linux, windows, dev, nightly, preview, stable) and profiles, matching the pattern used by m_2026_02_04.
6 tasks
osyvokon
added a commit
that referenced
this pull request
Apr 3, 2026
When atlas tiles are rapidly allocated and freed (e.g. watching a shared screen in Collab), a texture can become unreferenced and be removed while GPU uploads for it are still pending. On the next frame, `flush_uploads` indexes into the now-empty texture slot and panics: ``` thread 'main' panicked at crates/gpui_wgpu/src/wgpu_atlas.rs:231:40: texture must exist... #11 core::option::expect_failed #12 gpui_wgpu::wgpu_atlas::WgpuAtlas::before_frame #13 gpui_wgpu::wgpu_renderer::WgpuRenderer::draw ``` Drain pending uploads for a texture when it becomes unreferenced in `remove`, and skip uploads for missing textures in `flush_uploads` as a safety net.
osyvokon
added a commit
that referenced
this pull request
Apr 3, 2026
When atlas tiles are rapidly allocated and freed (e.g. watching a shared screen in Collab), a texture can become unreferenced and be removed while GPU uploads for it are still pending. On the next frame, `flush_uploads` indexes into the now-empty texture slot and panics: ``` thread 'main' panicked at crates/gpui_wgpu/src/wgpu_atlas.rs:231:40: texture must exist... #11 core::option::expect_failed #12 gpui_wgpu::wgpu_atlas::WgpuAtlas::before_frame #13 gpui_wgpu::wgpu_renderer::WgpuRenderer::draw ``` Drain pending uploads for a texture when it becomes unreferenced in `remove`, and skip uploads for missing textures in `flush_uploads` as a safety net.
osyvokon
added a commit
that referenced
this pull request
Apr 3, 2026
When atlas tiles are rapidly allocated and freed (e.g. watching a shared screen in Collab), a texture can become unreferenced and be removed while GPU uploads for it are still pending. On the next frame, `flush_uploads` indexes into the now-empty texture slot and panics: ``` thread 'main' panicked at crates/gpui_wgpu/src/wgpu_atlas.rs:231:40: texture must exist... #11 core::option::expect_failed #12 gpui_wgpu::wgpu_atlas::WgpuAtlas::before_frame #13 gpui_wgpu::wgpu_renderer::WgpuRenderer::draw ``` This change drains pending uploads for a texture when it becomes unreferenced in `remove`, and skips uploads for missing textures in `flush_uploads` as a safety net. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - Fixed occasional crashes when viewing a screen share
rtfeldman
pushed a commit
that referenced
this pull request
Apr 4, 2026
When atlas tiles are rapidly allocated and freed (e.g. watching a shared screen in Collab), a texture can become unreferenced and be removed while GPU uploads for it are still pending. On the next frame, `flush_uploads` indexes into the now-empty texture slot and panics: ``` thread 'main' panicked at crates/gpui_wgpu/src/wgpu_atlas.rs:231:40: texture must exist... #11 core::option::expect_failed #12 gpui_wgpu::wgpu_atlas::WgpuAtlas::before_frame #13 gpui_wgpu::wgpu_renderer::WgpuRenderer::draw ``` This change drains pending uploads for a texture when it becomes unreferenced in `remove`, and skips uploads for missing textures in `flush_uploads` as a safety net. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - Fixed occasional crashes when viewing a screen share
chan-yuu
pushed a commit
to chan-yuu/zed
that referenced
this pull request
Apr 18, 2026
…r get marked for later running
m-bers
pushed a commit
to m-bers/zed
that referenced
this pull request
Apr 19, 2026
…connect-api fix: adapt to upstream connect() API change
piper-of-dawn
pushed a commit
to piper-of-dawn/zed
that referenced
this pull request
Apr 25, 2026
) When atlas tiles are rapidly allocated and freed (e.g. watching a shared screen in Collab), a texture can become unreferenced and be removed while GPU uploads for it are still pending. On the next frame, `flush_uploads` indexes into the now-empty texture slot and panics: ``` thread 'main' panicked at crates/gpui_wgpu/src/wgpu_atlas.rs:231:40: texture must exist... zed-industries#11 core::option::expect_failed zed-industries#12 gpui_wgpu::wgpu_atlas::WgpuAtlas::before_frame zed-industries#13 gpui_wgpu::wgpu_renderer::WgpuRenderer::draw ``` This change drains pending uploads for a texture when it becomes unreferenced in `remove`, and skips uploads for missing textures in `flush_uploads` as a safety net. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - Fixed occasional crashes when viewing a screen share
Zenor27
pushed a commit
to Zenor27/zed
that referenced
this pull request
Jul 4, 2026
) When atlas tiles are rapidly allocated and freed (e.g. watching a shared screen in Collab), a texture can become unreferenced and be removed while GPU uploads for it are still pending. On the next frame, `flush_uploads` indexes into the now-empty texture slot and panics: ``` thread 'main' panicked at crates/gpui_wgpu/src/wgpu_atlas.rs:231:40: texture must exist... zed-industries#11 core::option::expect_failed zed-industries#12 gpui_wgpu::wgpu_atlas::WgpuAtlas::before_frame zed-industries#13 gpui_wgpu::wgpu_renderer::WgpuRenderer::draw ``` This change drains pending uploads for a texture when it becomes unreferenced in `remove`, and skips uploads for missing textures in `flush_uploads` as a safety net. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - Fixed occasional crashes when viewing a screen share
jonx
pushed a commit
to jonx/zed-aros
that referenced
this pull request
Jul 17, 2026
) When atlas tiles are rapidly allocated and freed (e.g. watching a shared screen in Collab), a texture can become unreferenced and be removed while GPU uploads for it are still pending. On the next frame, `flush_uploads` indexes into the now-empty texture slot and panics: ``` thread 'main' panicked at crates/gpui_wgpu/src/wgpu_atlas.rs:231:40: texture must exist... zed-industries#11 core::option::expect_failed zed-industries#12 gpui_wgpu::wgpu_atlas::WgpuAtlas::before_frame zed-industries#13 gpui_wgpu::wgpu_renderer::WgpuRenderer::draw ``` This change drains pending uploads for a texture when it becomes unreferenced in `remove`, and skips uploads for missing textures in `flush_uploads` as a safety net. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - Fixed occasional crashes when viewing a screen share
jolutz
pushed a commit
to jolutz/zed
that referenced
this pull request
Aug 8, 2026
Hide platform code entirely behind App for framework users
audivir
added a commit
to audivir/zed
that referenced
this pull request
Aug 10, 2026
…ention, audit Chrome/Edge parity Adds 4 regression tests closing out TEST_PLAN.md items zed-industries#2, zed-industries#5, and zed-industries#12: corrupted/truncated file load (test_fixtures/corrupted.pdf, a real PDF truncated mid-stream), a dangling bookmark reference (test_fixtures/ dangling_bookmark.pdf, an outline entry whose target page was removed), a render failure being recorded and not retried every frame, and degenerate zoom input staying finite/clamped. Adding these pushed the full suite over gpui's 15-second parking timeout: many tests across pdf.rs/pdf_renderer.rs/pdf_viewer.rs do real PDFium FFI work under allow_parking() and all queue on the single global PDFIUM async mutex when cargo test runs them in parallel. Fixed by adding a crate-wide PDFIUM_TEST_LOCK so these tests serialize instead of contending. Also corrects BUG_REPORT.md/TEST_PLAN.md's overstated "Done" status for search-error-vs-zero-results distinguishability (zed-industries#13) - only the logging half was fixed, the UI still can't tell the two apart - and adds a Chrome/ Edge feature parity audit to FEATURE_ROADMAP.md: no zoom-preset dropdown, rotate, document properties dialog, attachments panel, two-page view, or presentation mode exist yet. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
audivir
added a commit
to audivir/zed
that referenced
this pull request
Aug 10, 2026
…ention, audit Chrome/Edge parity Adds 4 regression tests closing out TEST_PLAN.md items zed-industries#2, zed-industries#5, and zed-industries#12: corrupted/truncated file load (test_fixtures/corrupted.pdf, a real PDF truncated mid-stream), a dangling bookmark reference (test_fixtures/ dangling_bookmark.pdf, an outline entry whose target page was removed), a render failure being recorded and not retried every frame, and degenerate zoom input staying finite/clamped. Adding these pushed the full suite over gpui's 15-second parking timeout: many tests across pdf.rs/pdf_renderer.rs/pdf_viewer.rs do real PDFium FFI work under allow_parking() and all queue on the single global PDFIUM async mutex when cargo test runs them in parallel. Fixed by adding a crate-wide PDFIUM_TEST_LOCK so these tests serialize instead of contending. Also corrects BUG_REPORT.md/TEST_PLAN.md's overstated "Done" status for search-error-vs-zero-results distinguishability (zed-industries#13) - only the logging half was fixed, the UI still can't tell the two apart - and adds a Chrome/ Edge feature parity audit to FEATURE_ROADMAP.md: no zoom-preset dropdown, rotate, document properties dialog, attachments panel, two-page view, or presentation mode exist yet.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a bunch of related changes to improve our App and platform code. The big change is that we no longer interact with platform code at all from main.
Appnow has methods for registering the appropriate application-level hooks, and it calls methods on thePlatform, which was renamed fromplatform::Appfor clarity.We now have two test methods,
App::testandApp::test_async. Thetestmethod is passed a&mut MutableAppContext, buttest_asyncis passed aTestAppContext, which is another wrapper around theRc<RefCell<MutableAppContext>>similar toApp, but with methods specific to testing. Two of these methods areupdateandread. Anupdatemethod exists onApp, but has slightly different semantics in that we don't defer effects to the end ofupdateduring tests. NowApp::updateis private.Appdoes not offer aread.In tests, if you want to update entities, you mostly use the
updatemethod on the handles, which take closures and manipulate the models. If you want to read entities, you'll callTestAppContext::readwith a closure. This will yield you a&AppContextthat you can use with the handles to read their underlying entities.I renamed
ViewHandle::as_refandModelHandle::as_reftoread. It's shorter and clearer and stays away from a name used by a trait in Rust's stdlib that has a different interface. So now you canreadorupdatean entity handle. I think it makes sense.