mirror of
https://github.com/storytold/figcraft.git
synced 2026-10-27 20:06:53 -06:00
Denis GomesandClaude Opus 5.5
7f6a3a4e46
Review on #1309 pointed out that core-text 20.1's get_descriptors retains the array it gets under the create rule a second time, so every scan kept one array of font descriptors alive. Checking that turned up a larger leak: Core Text autoreleases objects while it builds the collection, and the scan runs where no autorelease pool is active (the app's background scan thread, the CLI, the MCP server), so nothing ever drained them. Measured with `figcraft-cli run` of N `text.rescanFonts` steps on macOS 15 (peak memory footprint): | | 10 rescans | 200 rescans | |---|---|---| | main, without this PR | 221 MB | 220 MB | | this PR before the fix | 228 MB | 796 MB | | with the fix | 226 MB | 225 MB | A standalone Swift loop over the same Core Text calls grows from 9 MB to 759 MB over 200 scans without a pool and stays at 20 MB inside one, so the pool is what matters; the core-text bump removes the over-retain on top. - The query runs inside objc2::rc::autoreleasepool. objc2 0.6 is already in the lockfile (winit's), and the function is safe, so the workspace's unsafe_code = "forbid" still holds. - core-text goes to =22.0.0, the first release that takes ownership of the array correctly. It brings core-foundation 0.10, core-graphics 0.25 and core-graphics-types 0.2 beside the older versions other crates use. 22.0 moved framework linking behind a `link` feature that is on by default, so with default features off it is named explicitly. A rescan takes about 0.2 s instead of 0.08 s on that Mac (266 more font files are indexed); it only runs when asked for. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>