chore(deps)(deps): bump lz4_flex from 0.13.1 to 0.14.0#315
Closed
dependabot[bot] wants to merge 1 commit into
Closed
chore(deps)(deps): bump lz4_flex from 0.13.1 to 0.14.0#315dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [lz4_flex](https://github.com/pseitz/lz4_flex) from 0.13.1 to 0.14.0. - [Release notes](https://github.com/pseitz/lz4_flex/releases) - [Changelog](https://github.com/PSeitz/lz4_flex/blob/main/CHANGELOG.md) - [Commits](PSeitz/lz4_flex@0.13.1...0.14.0) --- updated-dependencies: - dependency-name: lz4_flex dependency-version: 0.14.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 |
7 tasks
doublegate
added a commit
that referenced
this pull request
Jul 20, 2026
lz4_flex 0.14 (bumped from 0.13 by the PR #315 Dependabot cherry-pick) split its own no_std support into a real alloc-vs-std distinction: compress_prepend_size/decompress_size_prepended (the Vec-returning block API rustynes-core's rewind.rs and zwinder.rs use for per-frame snapshot compression) now live behind the crate's `alloc` feature specifically, not `std`. The workspace's lz4_flex dependency line only requested `safe-encode`/`safe-decode` with default-features off, so a standalone no-std-feature build of rustynes-core (exactly what the CI `no_std build (thumbv7em-none-eabihf)` job runs, and what neither Dependabot's own checks nor my local `cargo build --workspace` catch, since a workspace build pulls in `lz4_flex/std` — which implies `alloc` — via rustynes-core's own default-on `std` feature) failed to compile: E0432, `no compress_prepend_size in block`. Fix: request `alloc` unconditionally in the workspace lz4_flex spec. rustynes-core already links `extern crate alloc;` in every build, std or not, so this costs nothing on the no_std path; `std` still implies `alloc` via lz4_flex's own feature table for the desktop/wasm builds, so nothing changes there either. Verified with the exact CI invocation: cargo build -p rustynes-core --target thumbv7em-none-eabihf --no-default-features plus a full `cargo fmt --check` / `cargo clippy --workspace --all-targets -D warnings` / `cargo test --workspace` re-run.
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. |
doublegate
added a commit
that referenced
this pull request
Jul 21, 2026
Cuts v2.2.2 "Conduit", a build, distribution, and CI-integrity patch. It
carries RustyNES onto RetroArch's own buildbot -- the recipe now builds all ten
platform jobs -- hardens the GitHub Actions supply chain, and collapses the
toolchain to a single pinned source of truth with no `nightly` on any build
path.
Zero emulation-core changes
---------------------------
No file under `crates/rustynes-{cpu,ppu,apu,mappers,core}` is touched, so the
deterministic `#![no_std]` chip stack, save-state / TAS / netplay-replay
formats, and every golden vector are untouched BY CONSTRUCTION rather than by
re-measurement: AccuracyCoin holds 141/141 (100.00%), nestest stays 0-diff, and
`blargg_apu_2005` / `pal_apu_tests` (10/10) / `visual_regression` / the 60-ROM
commercial oracle are unchanged from v2.2.1.
One behavioural improvement reaches a shipped artifact: the libretro tvOS core
is now built with `panic = "abort"` like every other platform, rather than the
`panic = "unwind"` its former `-Zbuild-std` path forced.
Scope (all landed since v2.2.1)
-------------------------------
* Libretro buildbot recipe (issue #311) + core feature completion: memory maps
for rcheevos, an FDS load-path fix plus disk control, native Game Genie
cheats, fast-forward audio gating.
* Buildbot taken from 1/10 to 10/10 across three diagnosis rounds against a
third-party pipeline we can neither push to nor re-run: missing cross targets
(8 jobs), an upstream `rust-libretro` MinGW enum-signedness bug, tvOS MSRV +
`panic_abort`, and `-C ar` removed in Rust 1.97.
* tvOS moved onto the pinned stable toolchain: `aarch64-apple-tvos` is no
longer tier 3, so the template's `+nightly -Zbuild-std` override is obsolete.
Dropping it dissolved three stacked workarounds instead of adding a fourth.
* CI supply-chain hardening: `persist-credentials: false` on all 19 checkouts,
a fail-closed release-tag check, and `dtolnay/rust-toolchain` SHA-pinned off
`@master`.
* One toolchain everywhere: `rust-setup` resolves `[toolchain].channel` from
`rust-toolchain.toml`, leaving zero toolchain version literals under
`.github/`. Nightly survives only in `cargo fuzz` and the dormant
`rustynes-monetization` bindgen, neither of which is a gate.
* Dependency consolidation (Dependabot #313-#315), which surfaced a real
lz4_flex 0.14 `alloc`-feature break that only the standalone `no_std`
cross-compile can catch.
Review round two: a real fail-OPEN in the tag check
---------------------------------------------------
Review caught that the tag-existence filter,
`[.[] | select(.ref == $r)] | length`, returns 0 for a body of `{}` -- `.[]`
iterates an object's VALUES, of which `{}` has none -- and 0 is exactly the
"tag absent" answer, so a malformed response took the RELEASE path. Every other
malformed shape (bare string, null, an object with entries) aborts unaided
because `.[]` or `.ref` errors, which is precisely what made `{}` easy to miss
and why relying on jq to error was not enough. An explicit `type != "array"`
guard now fails closed, re-verified to leave `[]` -> 0, an exact match -> 1,
and a prefix-only match (`v2.2.20` queried as `v2.2.2`) -> 0.
The prior claim in the release notes and CHANGELOG that "a non-array body
aborts the job" was therefore true only for some shapes; both now describe what
the code actually does.
Version and metadata
--------------------
Workspace 2.2.1 -> 2.2.2; `Cargo.lock` diff is exactly 18 insertions and 18
deletions, all workspace-member version lines, with no dependency drift. No
mobile app version change -- Android `versionCode`/`versionName` and iOS
`MARKETING_VERSION` stay frozen at their v2.0.x host-only release points; the
joint mobile store launch remains v2.3.0. README badge, README Current Release,
`docs/STATUS.md`, and AGENTS.md current-release blocks all updated. The
RetroAchievements User-Agent needs no edit: it derives from `CARGO_PKG_VERSION`.
`.gitignore` gains `*.dSYM/` and `*.dSYM.zip`. The Apple libretro jobs and the
iOS xcframework build emit debug-symbol bundles beside the library; `*.dylib`
matched the library but neither the bundle directory nor the archive.
Verification
------------
cargo test --workspace: 1905 passed, 0 failed, 13 ignored (exit 0).
fmt clean; clippy --workspace --all-targets -D warnings clean; rustdoc clean
under RUSTDOCFLAGS=-D warnings; `no_std` thumbv7em cross-compile builds;
`cargo deny check` ok on advisories, bans, licenses and sources; pre-commit
(markdownlint included) clean on every touched file; full PR CI green with all
review threads adjudicated and resolved.
Not verifiable on this host: the tvOS link step. There is no tvOS SDK or linker
here and we cannot run a pipeline on git.libretro.com, so the compile path is
verified and the link step is not. Issue #311 stays open until libretro
confirms a clean pipeline.
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 lz4_flex from 0.13.1 to 0.14.0.
Changelog
Sourced from lz4_flex's changelog.
Commits
1bffdcbMerge pull request #229 from PSeitz/release/0.14.0-changeloga5973e4Update CHANGELOG for 0.14.0 release, bump version to 0.14.043cdb22Merge pull request #228 from PSeitz/0.14.x08fd47eadd release skilla6c6135Merge pull request #225 from fbrozovic/alloc-featureca019ecAdd alloc feature to support no_std without an allocator19194f9Merge pull request #223 from PSeitz/0.13.xDependabot 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)