Repository navigation
chore(deps)(deps): bump the production-dependencies group across 1 directory with 3 updates - #569
Closed
dependabot[bot] wants to merge 1 commit into
Closed
dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
…rectory with 3 updates Bumps the production-dependencies group with 3 updates in the / directory: [thiserror](https://github.com/dtolnay/thiserror), [cc](https://github.com/rust-lang/cc-rs) and [uniffi](https://github.com/mozilla/uniffi-rs). Updates `thiserror` from 2.0.20 to 2.0.21 - [Release notes](https://github.com/dtolnay/thiserror/releases) - [Commits](dtolnay/thiserror@2.0.20...2.0.21) Updates `cc` from 1.4.7 to 1.5.1 - [Release notes](https://github.com/rust-lang/cc-rs/releases) - [Changelog](https://github.com/rust-lang/cc-rs/blob/main/CHANGELOG.md) - [Commits](rust-lang/cc-rs@cc-v1.4.7...cc-v1.5.1) Updates `uniffi` from 0.32.1 to 0.32.2 - [Changelog](https://github.com/mozilla/uniffi-rs/blob/v0.32.2/CHANGELOG.md) - [Commits](mozilla/uniffi-rs@v0.32.1...v0.32.2) --- updated-dependencies: - dependency-name: thiserror dependency-version: 2.0.21 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: production-dependencies - dependency-name: cc dependency-version: 1.5.1 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: production-dependencies - dependency-name: uniffi dependency-version: 0.32.2 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: production-dependencies ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
Important Review skippedBot user detected. To trigger a single review, invoke the ⚙️ Run configurationConfiguration used: Repository: doublegate/RustyNES/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Antigravity review (Gemini via Ultra)This PR updates the Blocking issuesNone found. SuggestionsNone. This is a trivial automated lockfile update. NitpicksNone. Automated first-pass review by |
Owner
doublegate
added a commit
that referenced
this pull request
Sep 28, 2026
…cheevos 12.5.0, Gradle 9.8.0 (#570) * chore(deps): take the five open Dependabot updates The contents of Dependabot PRs #564, #566, #567, #568 and #569, taken whole from their branches (none of their files had changed on main since each branch was cut), so they land together with the rest of the dependency refresh: - #564 taiki-e/install-action 2.87.15 -> 2.87.20 (security.yml) - #566 androidx.core:core-ktx 1.19.0 -> 1.19.1 - #567 Gradle wrapper 9.7.1 -> 9.8.0. The wrapper jar is a binary executed on every build, so it was checked before use: sha256 238e777f... equals services.gradle.org/distributions/gradle-9.8.0-wrapper.jar.sha256, and the distributionSha256Sum bafd5ce9... equals gradle-9.8.0-bin.zip.sha256. - #568 thiserror 2.0.20 -> 2.0.21 (rustynes-cosim lockfile) - #569 thiserror 2.0.21, cc 1.5.1, uniffi 0.32.2 (workspace lockfile) gradlew.bat keeps this repository's LF line endings (the mixed-line-ending pre-commit hook, --fix=lf); Dependabot's copy used Gradle's CRLF, so the file's content is Gradle's 9.8.0 script with LF line ends, as 9.7.1's was. Verified here: :app:testFossDebugUnitTest BUILD SUCCESSFUL on Gradle 9.8.0. The following commits bump everything else. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * chore(deps): egui 0.36 + wgpu 30, every Rust dependency and Action at its newest Maintainer instruction (2026-09-28): every dependency bump, major and minor, in one PR, with whatever the project needs to accommodate them. This commit is the Rust and GitHub Actions half; rcheevos follows. ## egui 0.35 -> 0.36, wgpu 29 -> 30, naga 29 -> 30 -- and why this is vendored These move together: egui-wgpu 0.36 depends on wgpu 30, and a graph holding wgpu 29 and 30 at once fails every device/queue handoff. The move had been held since 2026-09-18 on one upstream fact, re-measured today by compiling a throwaway crate with this project's egui-winit feature set: egui-winit 0.36.2 (newest release) for wasm32-unknown-unknown error[E0407]: method `bytes` is not a member of trait `egui::DroppedFile` RustyNES ships a web demo, so that is a hard stop. Upstream fixed it on main (PR #8516) without a release. The git-rev patch was refused before because deny.toml denies git sources; instead vendor/egui-winit/ carries the crates.io 0.36.2 package plus a three-site `cfg(not(target_arch = "wasm32"))` guard (the `dropped_file` module, its `use`, and the one construction site), wired through [patch.crates-io] exactly as vendor/rust-libretro-sys already is, and excluded from the workspace. License texts (MIT OR Apache-2.0) are copied from upstream at tag 0.36.2 because the package ships none; NOTICE credits it. VENDORED.md records the fix and the removal steps. Proven: the probe crate, pointed at the vendored path, compiles for wasm32 (verified rebuilt from the path, not cached) and natively. ## The API changes, applied fresh on main The blocked branch chore/egui-0.36-wgpu-30-blocked (left untouched) recorded five deltas; each was re-derived against the 0.36.2 / 30.0.1 sources: - `SurfaceTexture::present()` -> `Queue::present(texture)`: frontend gfx.rs (3 sites -- the third is behind `hd-pack`, which the default build does not compile), detached.rs, Android (1), iOS (2). - `RequestAdapterOptions.apply_limit_buckets = false`, wgpu's Default: the bucketing is a fingerprinting mitigation that would round real limits down. - `SurfaceConfiguration.color_space = SurfaceColorSpace::Auto`, the documented default that reproduces wgpu's historical choice, so the picture is unchanged. - `get_mapped_range()` returns Result: the GPU-timing callback skips a sample on failure instead of panicking for telemetry. - `TexturesDelta.set` is `HashMap<TextureId, SmallVec<[ImageDelta; 1]>>` (one id can carry several ORDERED deltas per frame -- all applied, in order) and `free` is a HashSet. Two helpers in debugger/mod.rs, `upload_texture_sets` and `take_texture_frees`, serve every site. One change the branch did not need: TexturesDelta now implements Drop, and that Drop `debug_assert!`s the delta is EMPTY. A frame whose texture updates are dropped unapplied now panics in debug builds -- it was always a silent bug (egui never resends them). The main-window path already uploaded before the swapchain acquire (v2.7.3 DESK-01) and moves the delta out, so a skipped paint drops an empty delta. The detached-window path had one early return -- the window closed between phase 1 and phase 2 -- that dropped the delta whole; it now clears it explicitly, since no renderer remains to receive it. ## Everything else - bitflags 2.13, realfft 3.5, libc 0.2.189, wasm-bindgen 0.2.129, wasm-bindgen-futures 0.4.79, js-sys/web-sys 0.3.106, plus every compatible lockfile update (workspace, rustynes-cosim, fuzz). - web/Trunk.toml's wasm-bindgen CLI pin 0.2.128 -> 0.2.129. It MUST equal the library in Cargo.lock; a mismatch fails the Pages deploy while wasm clippy still passes. `trunk build --release` run: success. - bincode REMOVED, not bumped: nothing in the workspace uses it (only comments mention it), and bincode 3.0.0's entire source is `compile_error!("https://xkcd.com/2347/")` -- verified by building it. - deny.toml drops the CC0-1.0 allowance: its only user was hexf-parse, which naga 30 no longer pulls in, and cargo-deny flagged it as unmatched. An unused licence allowance only widens the policy. - Actions: gradle/actions/setup-gradle 6.3.0 -> 6.4.0 (additive: job-summary annotations, dependency-graph plugin 1.5.0), taiki-e/install-action 2.87.20 -> 2.87.21. Every major tag was already current; the two SHA pins (actions/checkout v7.0.1, dtolnay/rust-toolchain master) match upstream. - NOT moved, by design: the getrandom 0.2/0.3 `dep:` aliases exist only to turn on the wasm backend of the versions rand_core 0.6 and ahash still resolve; bumping them to 0.4 would add an unused third getrandom and cut the script-wasm build off from its RNG. Android dependencies were all at latest stable already (Glance stays on its newer 1.3.0-alpha02 line). ## Verified fmt; clippy workspace + scripting + scripting,hd-pack + retroachievements + full; wasm32 clippy default, wasm-canvas AND script-wasm; RUSTDOCFLAGS=-D warnings cargo doc; thumbv7em no_std; rustynes-cosim and fuzz check; cargo deny advisories/bans/licenses/sources ok; cargo ndk arm64 check of rustynes-android + rustynes-mobile; Android :app:testFossDebugUnitTest BUILD SUCCESSFUL; --features test-roms --release 2,869 passed / 0 failed / 20 ignored; AccuracyCoin 144/144. NOT verified here: rustynes-ios's gfx_metal.rs (cfg(target_os = "ios"); its build needs the Apple SDK for ring's C). Its three edits mirror Android's, which compile; the first compile is the v2.9.3 device checklist's step B1. No frame has been presented from this build on a display: the present path changed, so a p99 frame-pacing capture on wgpu 30 is owed before any pacing number is trusted. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * chore(deps): rcheevos 12.3.0 -> 12.5.0; the ABI guard catches a grown struct The vendored RetroAchievements C runtime (crates/rustynes-cheevos/vendor/ rcheevos, MIT) moves to the newest release, v12.5.0, as the last library in this dependency refresh. What was replaced, and what was not. The vendor directory holds a SUBSET of upstream (build.rs documents it: no disc/zip/encrypted hashing, no libretro or RAIntegration glue). Every one of those 50 files exists in 12.5.0, so exactly those 50 were replaced -- 27 changed. The two new files in the included directories, a Visual Studio debugger visualizer (.natvis) and rc_client_raintegration.h, are left out, consistent with the documented exclusions. The size guard did its job. ffi::abi_guard::struct_sizes_match_c failed on the first run: rc_client_user_t is 56 bytes in C and the Rust mirror said 48. 12.4 appended `time_t avatar_last_updated`. The mirror gains the field as i64, following the convention rc_client_user_game_summary_t already uses ("time_t is 8 bytes on the targets we build"); the guard pins that per target. Because the guard compares SIZES, a same-size reordering would pass it, so the header diff was read in full: every other change is additive -- a new games-list API and code-note editor API (unused here), the same appended field in the rc_api_user response structs (not mirrored), and a new console id (RC_CONSOLE_PLAYSTATION_3). No mirrored struct moved a field. The client identity follows automatically: RA_USER_AGENT's `rcheevos/<version>` clause is generated from rc_version.h by build.rs; its test passes against 12.5.0. NOTICE, originality-and-provenance.md section 5 and the http.rs example now say 12.5.0; the dated User-Agent examples in older docs stay as written. Also here: the CHANGELOG [Unreleased] entry for the whole refresh. Verified: rustynes-cheevos tests 9/9 (abi_guard included) after the mirror fix; clippy -p rustynes-frontend --features retroachievements clean; the workspace test-roms run (2,869 / 0) included this crate. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * docs(deps): comments that still named wgpu 29, Gradle 9.7.1 and a held egui The version bumps in #570 left comments describing the tree before them. Copilot flagged five; a grep for the old numbers found four more of the same kind. None change behaviour, but each would mislead the next person bumping these crates: - Cargo.toml: the wgpu comment and the long "HELD AT 0.35" block said egui was pinned because egui-winit 0.36 cannot build for wasm. It is no longer held; the block now says egui-winit is vendored and states the condition for removing the vendored copy (a published egui-winit carrying upstream PR #8516). - rustynes-android / rustynes-ios Cargo.toml: "same wgpu major (29)" -> 30. - rustynes-frontend Cargo.toml: the naga comment now says naga moves with wgpu 30. - gradle-wrapper.properties: the checksum-source comment named the 9.7.1 .sha256; it now names gradle-9.8.0-bin.zip.sha256, the file the pinned checksum was verified against. - android/build.gradle.kts: notes the 9.8.0 wrapper move. - gfx_metal.rs (two comments) and docs/ios.md: wgpu 30 does have a CoreAnimationLayer surface target, behind cfg(metal); the UiKit window-handle path is kept because it is what the app already hands over and it needs no new unsafe. The old text said no such variant existed. Verified: cargo metadata resolves; fmt clean. Comment-only otherwise. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * fix(cheevos): mirror rcheevos time_t fields as libc::time_t, not i64 agy's review of #570 flagged the new rc_client_user_t.avatar_last_updated field, declared as i64 for a C time_t. The finding is real, and older than this PR: unlock_time (rc_client_achievement_t) and beaten_time / completed_time (rc_client_user_game_summary_t) had used the same hard-coded i64 since the FFI was written, under a comment claiming time_t is "8 bytes on the targets we build". That holds for the default targets (x86_64 / arm64 desktop, arm64 and x86_64 Android, iOS) and for Windows, where time_t is 64-bit. It fails on 32-bit Android (armeabi-v7a is an opt-in ABI in android/app/build.gradle.kts) and on 32-bit glibc, where time_t is 32 bits. There a fixed i64 widens the field, which misplaces every field after it and grows the struct, so a read through the mirror returns the wrong bytes. Measured, not argued. The existing abi_guard compares each mirror's size_of with the C sizeof from the vendored static_asserts.c. Built and run as i686-unknown-linux-gnu (gcc -m32): before: struct_sizes_match_c FAILED, rc_client_achievement_t 84 vs 80 after: 9 passed, 0 failed (the guard included) The fix uses libc::time_t (libc 0.2.189, already in the dependency graph through the frontend and libretro, so no new crate enters the build). It is a target-only dependency, like ureq, because the crate is empty on wasm32. Assigning 0 in client.rs is unchanged, since a literal infers either width. Also verified: cargo test -p rustynes-cheevos (native, 9 passed); clippy -D warnings on rustynes-cheevos and on the frontend with retroachievements; cargo ndk -t armeabi-v7a check -p rustynes-cheevos. The ARMv7 build compiled but was not run: there is no ARMv7 runner here. i686 is the executed stand-in with the same 32-bit time_t. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * docs(agents): the egui migration branch is compared, found covered, deleted docs/agents/dependencies.md still said `chore/egui-0.36-wgpu-30-blocked` was the ONLY copy of the egui 0.36 / wgpu 30 migration and that deleting it would destroy the work. Since #570 landed the migration, that warning is false. The maintainer asked for the branch to be checked for anything #570 lacked and then deleted; this records the result where the next session will look. The comparison, so nobody needs to re-derive it: - 5 commits ahead of its merge base (v2.3.2 era). The four feature commits (per-byte write attribution, per-pixel causal record, the Pixel Provenance panel, `rustynes verify`) are on main: their files exist there (ppu/src/provenance.rs, debugger/provenance_panel.rs, docs/pixel-provenance.md, the cli.rs verify subcommand). - 69b00e5, the migration itself, touches the same API sites as #570, counted by grep in both trees: color_space 4, apply_limit_buckets 3, get_mapped_range 2, the same Queue::present sites, and per-id delta lists applied in order. Its explanatory comments say the same as #570's. - #570 does more at one site: in DetachedWindows::present the branch's early return for a closed window drops a non-empty TexturesDelta, which trips egui 0.36's debug assertion. #570 clears it first. - Its version pins (egui 0.36, wgpu/naga 30) and Action bumps are superseded by the newer ones in #570. The branch was deleted locally and on GitHub; its tip was 69b00e5, recorded in the doc in case it has to be recovered from the reflog or a clone. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj * docs(vendor): say which vendored egui-winit unsafe blocks RustyNES compiles CodeRabbit's "Safety comment on new unsafe blocks" check flagged vendor/egui-winit/src/clipboard.rs:184 and safe_area.rs:29, which have no adjacent `// SAFETY:` comment. Both are upstream's code. VENDORED.md promises that every file apart from the three marked wasm32 sites is byte-for-byte the crates.io 0.36.2 package, and that promise is what makes the eventual removal a simple delete. Annotating upstream's code would break it, so the answer goes in VENDORED.md instead. Checked rather than assumed (`cargo tree -p rustynes-frontend -e features -i egui-winit`: bytemuck, links, wayland, webbrowser, x11): - the smithay clipboard block exists only with the `clipboard` feature, which is not enabled (the dependency uses default-features = false); - safe_area.rs is cfg(target_os = "ios"), and the iOS app is SwiftUI over rustynes-ios. It does not use egui-winit. So neither block is in any binary this project ships. The note says to review them if that changes, e.g. if `clipboard` is enabled. It makes no claim that upstream's blocks are sound. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Owner
Contributor
Author
|
This pull request was built based on a group rule. Closing it will not ignore any of these versions in future pull requests. To ignore these dependencies, configure ignore rules in dependabot.yml |
dependabot
Bot
deleted the
dependabot/cargo/production-dependencies-dde950e9a3
branch
September 28, 2026 23:50
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
1 participant
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.
Bumps the production-dependencies group with 3 updates in the / directory: thiserror, cc and uniffi.
Updates
thiserrorfrom 2.0.20 to 2.0.21Release notes
Sourced from thiserror's releases.
Commits
b1827eeRelease 2.0.2158037b5Merge pull request #459 from dtolnay/turbofishf82a0cfKeep track of nested turbofish depth72ea492Raise required compiler to Rust 1.7772eea0dResolve io_other_error clippy lint in tests07f09a2Raise required compiler to Rust 1.742715388Update ui test suite to nightly-2026-09-225a306c7Update ui test suite to nightly-2026-09-05ef9383bUpdate ui test suite to nightly-2026-08-228336b84Update ui tests for version 2.0.20Updates
ccfrom 1.4.7 to 1.5.1Release notes
Sourced from cc's releases.
Changelog
Sourced from cc's changelog.
Commits
d279cddchore(cc): release v1.5.1 (#1954)87533b7fix: link the static C++ stdlib with-bundle, once perBuild(#1955)0faaa40Use lp64d ABI for Redox riscv64 (#1953)6b0d8e6chore: release (#1952)b7d59a9fix: don't report the file name cl.exe echoes as a warning in expand() (#1950)fc01fd7fix: ignore MSVC/linkflags with a warning (#1949)b81fc77feat: inherit x86 target features from RUSTFLAGS (#1948)0da3fabci: add additional targets for MSRV testing (#1945)0c74c6aci(deps): bump release-plz/action from 0.5.137 to 0.5.138 (#1947)e2bff2cdocs: document macOS SDKROOT and Xcode CLT for testing (#1943)Updates
uniffifrom 0.32.1 to 0.32.2Changelog
Sourced from uniffi's changelog.
Commits
7bc621echore: Release0f1506dchore: Release69aa9a1Merge pull request #2998 from bendk/bdk/push-xtomqpwpszuv3eb8c2dKotlin: stop emitting unused expressions in generated bindingsDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditions