refactor(deps): drop cocoa/objc for objc2-app-kit - #675
refactor(deps): drop cocoa/objc for objc2-app-kit#675Alex Shabalin (alex-sparus) wants to merge 1 commit into
Conversation
🎨 Storybook previewUpdated for 85f72cc
|
📋 PR Overview
🔬 Coverage
|
|
darkmatteragent please review this PR |
|
darkmatteragent please review this PR now |
darkmatteragent
left a comment
There was a problem hiding this comment.
Review — COMMENT
56dc7e8ecac5 · 1 finding
Behavior-preserving swap of three NSWindow call sites from deprecated cocoa/objc to typed objc2-app-kit; sound to merge. Verified upstream: NSFloatingWindowLevel is exactly 3 (the old literal), every method used is ungated under the declared features (NSResponder+NSWindow+objc2-core-foundation; bitflags comes transitively), and the Cargo.lock deletions prove no other workspace crate consumed cocoa/objc.
One doc-only nit: the new SAFETY comments state the wrong ownership mechanism for the ns_window() pointer.
Findings
Tip
nit · documentation — SAFETY comments misdescribe ns_window() as retained-then-autoreleased; tao actually retains it for the window's lifetime
apps/native/src-tauri/src/peek.rs:494
Gutter 494-496 (and the identical comment at main.rs 945-948) claims "ns_window() hands back a retained-then-autoreleased NSWindow, valid for this scope". That mechanism is wrong: tao's UnownedWindow::ns_window() returns &*self.ns_window as *const NSWindow as *mut _ — a plain borrow of the Retained<NSWindow> tao owns, which stays alive for the window's lifetime and is never autoreleased. T
|
No findings. reviewed: 56dc7e8 — 2026-09-01T16:42Z verdict: approve findings: 0
Run details
|
|
Re the review finding that the SAFETY comments misdescribe
Verified against the registry sources for ping darkmatteragent |
This stack of pull requests is managed by jj-ryu. |
darkmatteragent
left a comment
There was a problem hiding this comment.
Review — APPROVE
56dc7e8ecac5 · 0 findings
Approve: mechanical, behavior-preserving migration of three NSWindow call sites from deprecated cocoa/objc onto typed objc2-app-kit 0.3.2. - Verified against upstream 0.3.2: NSFloatingWindowLevel = 3 matches the removed literal, and the three collection-behavior flags match cocoa's values bit-for-bit. - Declared features cover every gate the used symbols carry (NSWindow class needs NSResponder+NSWindow; alphaValue needs objc2-core-foundation); lockfile removals leave no dangling dependents. - Consolidated helper preserves old call ordering at both sites; the new debug_assert strengthens, not weakens, the main-thread contract.
No findings.
Problem: tooling flags `block 0.1.6` as unmaintained. Nothing uses it directly; it arrives only through `cocoa 0.26`. `cocoa` and `objc 0.2` are deprecated upstream as well — no soundness fixes, no bindings for new macOS SDKs, and untyped `msg_send!` calls no compiler checks. Solution: move the three NSWindow call sites onto `objc2-app-kit`, already in the tree through Tauri, so the lockfile gains nothing. The two identical panel-setup blocks in `peek.rs` collapse into one helper whose main-thread requirement is asserted rather than assumed, and the hardcoded level literal becomes `NSFloatingWindowLevel`. `cocoa`, `cocoa-foundation`, `objc`, `block`, `malloc_buf` and `core-graphics 0.24` leave `Cargo.lock`. Refs #546
56dc7e8 to
85f72cc
Compare





Summary
Problem: tooling flags
block 0.1.6as unmaintained. Nothing uses it directly; it arrives only throughcocoa 0.26.cocoaandobjc 0.2are deprecated upstream as well — no soundness fixes, no bindings for new macOS SDKs, and untypedmsg_send!calls no compiler checks.Solution: move the three NSWindow call sites onto
objc2-app-kit, already in the tree through Tauri, so the lockfile gains nothing. The two identical panel-setup blocks inpeek.rscollapse into one helper whose main-thread requirement is asserted rather than assumed, and the hardcoded level literal becomesNSFloatingWindowLevel.cocoa,cocoa-foundation,objc,block,malloc_bufandcore-graphics 0.24leaveCargo.lock.Refs #546
Test Plan
Docs