Update crates - #79
Merged
Merged
Conversation
danifunker
commented
Aug 8, 2026
danifunker
commented
Contributor
- Updated all crates except "glow" as part of iris core
- tested against full release flow
Moves the whole graph to latest: bitfield 0.14->0.19, cpal 0.15->0.18, env_logger 0.10->0.11, png 0.17->0.18, rfd 0.15->0.17, socket2 0.5->0.6, spin 0.10->0.12, libchdman-rs 0.288->0.289, windows-sys 0.52->0.61, and in iris-gui dirs 5->6, if-addrs 0.13->0.15, toml 0.8->1 (matching the root). Only 5 source lines had to move: - cpal 0.18 (hal2): SampleRate is now a plain `type = u32` alias, all error types collapsed into cpal::Error, build_output_stream takes StreamConfig by value (it's Copy, so the f32-then-i16 fallback still passes it twice), and DeviceTrait::name() is gone in favour of the Display impl. - socket2 0.6 (net): set_ttl -> set_ttl_v4, disambiguated from the IPv6 hop limit. The NAT ICMP socket is IPV4, so it's a straight substitution. - png 0.18 (iris-gui): output_buffer_size() returns Option<usize>. - rfd 0.16 dropped the async-std/tokio executor features; xdg-portal now pulls its own pollster. Also declares windows-sys Win32_Foundation, which iris needed all along and never asked for. thread_affinity's SetThreadAffinityMask/GetCurrentThread name Foundation::HANDLE, but Win32_System_Threading doesn't imply that feature — the Windows build only ever worked because rfd/socket2/ anstyle-wincon resolve to the same windows-sys and enable it themselves. Feature unification is not a contract; drop any one of them and Windows breaks in a way that reproduces nowhere else. egui/eframe stay at 0.35 and the windowing stack they share (winit, glutin, glutin-winit, glow, raw-window-handle) is untouched — winit especially, since it's patched to third_party/winit-0.30.13 for the App Store private-API fix. iris's own glow 0.13 is therefore still a second copy alongside eframe's 0.17; png used to be split the same way and is now unified. Verified: check clean across default, lightning+rex-jit+jit+chd+camera+pcap+ ultra64, r5k+r5ksc_triton+idle-pause, and iris-gui default/pcap/premiere/ appstore; 453+28 tests and 2 doctests pass; one fat-LTO release build of iris-gui --features premiere,pcap links. The chd_disk tests genuinely create and flatten compressed CHDs, so libchdman 0.289 is exercised, not just compiled. dirs 5->6 was checked to leave config_dir()/data_dir() identical on all three platforms, so gui.json doesn't move. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Cargo.lock is gitignored, so every CI run re-resolves the whole graph and a build that was green yesterday can go red today because some transitive crate five levels down shipped a new minor. Nothing in the diff shows it, and bisecting doesn't help — checking out an old commit doesn't restore that commit's dependency set. build-manifest.sh records what a specific build actually resolved: git commit + dirty state, host triple, rustc/cargo versions, the cargo selection flags, and every crate version in the graph. Ship it as a release artifact and that class of failure becomes a diff of two manifests. It takes the build's own selection flags after `--`, because the resolve is feature-dependent — the default build pulls 154 crates, lightning+jit+chd+ camera+pcap+ultra64 pulls 208. Run it after the build, in the same job, or it describes a resolve that never shipped. Two details worth keeping: - The trailing sha256 is over the crate list alone, so it's a stable identity for the dependency graph. Same fingerprint across two releases => deps are provably identical and the regression is elsewhere. - Non-registry sources get their own section. A version number alone doesn't identify the code that shipped when [patch.crates-io] is in play, and it is here: winit resolves to third_party/winit-0.30.13, not the crates.io 0.30.13. Workspace members and cargo's (proc-macro) marker are filtered out so that section shows only genuine overrides. Not wired into any workflow — release.yml lives on main by the file-ownership rule, so the pipeline change goes there separately. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
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.