Repository navigation
chore(deps)(deps): bump gradle-wrapper from 9.7.1 to 9.8.0 in /android - #567
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
Bumps [gradle-wrapper](https://github.com/gradle/gradle) from 9.7.1 to 9.8.0. - [Release notes](https://github.com/gradle/gradle/releases) - [Commits](gradle/gradle@v9.7.1...v9.8.0) --- updated-dependencies: - dependency-name: gradle-wrapper dependency-version: 9.8.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
|
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 Gradle wrapper distribution from 9.7.1 to 9.8.0 but appears to bundle outdated shell execution scripts. Blocking issues
Suggestions
Nitpicks
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
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
dependabot
Bot
deleted the
dependabot/gradle/android/gradle-wrapper-9.8.0
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 gradle-wrapper from 9.7.1 to 9.8.0.
Release notes
Sourced from gradle-wrapper's releases.
... (truncated)
Commits
a927be5Add the Develocity plugin back to the Android smoke tests (#39273)eaee500Add the Develocity plugin back to the Android smoke tests189b672Route everything still hitting Maven Central through the mirror (#39257)36b1814Add back mavenCentral to doc snippets2740c2dUpdate Gradle wrapper to version 9.8.0-rc-3 (#39264)2099383Update Gradle wrapper to version 9.8.0-rc-3c80202fRoute everything still hitting Maven Central through the mirror3f6a534Fix when a best practice was introduced (#39253)9efc9edFix when a best practice was introduced459e143Route integration test dependencies through the repository mirror (#39239)Dependabot 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 this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)