Get the checks green on beclab-master - #3
Merged
Merged
Conversation
Rust 1.98's clippy refuses `chunks_exact` with a constant size, so all three clippy rows have been failing on the four places that read 16-bit samples: tests/support, examples/support, src/pipeline/tests and xtask's wav reader. `as_chunks::<2>()` gives `[u8; 2]` rather than a slice that happens to hold two, so `from_le_bytes` takes it whole and the indexing goes away. Same handling of a trailing odd byte as before: both forms ignore the remainder. Stable since 1.88.0 -- `slice_as_chunks` -- which is exactly this crate's MSRV, so the 1.88 job still builds. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`cargo deny` has been failing on h2 0.4.15 (RUSTSEC-2026-0258, unbounded empty DATA frames), rustls 0.23.41 (RUSTSEC-2026-0285, TLS 1.3 handshake messages accepted across encryption level boundaries) and der 0.8.0, which was yanked. None is reached by this crate's own code -- they arrive through ureq via hf-hub, and through ort-sys -- so this is a lockfile move and nothing else. `cargo update` picked versions inside the 1.88 floor: h2 0.4.19, rustls 0.23.45, rustls-webpki 0.103.15, der 0.8.2. Verified with the arguments the workflow passes: advisories ok, bans ok, licenses ok, sources ok. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
huangzhenyuan-bytetrade
added a commit
that referenced
this pull request
Sep 15, 2026
…nch could not #3 moved off two RUSTSEC advisories and a yanked crate, and replaced the four constant-size chunks_exact calls Rust 1.98's clippy refuses. All four were in files this branch does not touch, so they were red here with nothing to fix from inside; taking that merge is what turns them green.
huangzhenyuan-bytetrade
added a commit
that referenced
this pull request
Sep 16, 2026
The clippy matrix has three rows and none of them enables all four accelerated features together -- the Linux x86_64 row takes openvino and skips coreml, the macOS row the reverse. A `cfg` that goes false only when all four are on is therefore green everywhere CI looks. One did. A test module's import sat behind `any(not(coreml), not(cuda), not(migraphx), not(openvino))` while two tests beside it were unconditional, so with the full set enabled the import vanished and the module stopped compiling: twelve errors, and every row above stayed green. It was found by hand, not by CI, and nothing would have caught the next one. `cargo check` rather than clippy, on purpose. What this catches is code that does not build; asking clippy would also fail on lints that arrive with a toolchain rather than with a change, which is what #3 had to sort out separately. macOS because coreml builds nowhere else, and load-dynamic because type-checking against a provider does not need the provider's library. Verified locally on the same combination: `cargo check --workspace --all-targets --features "coreml cuda migraphx openvino load-dynamic _metrics"` is clean, and restoring the guard that was removed reproduces the twelve errors, so this job would have caught the thing that prompted it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
解决什么问题
beclab-master上有五个 check 是红的,而它们跟任何一个在飞的 PR 都无关。红着的后果不是「有 bug」,是后面每个 PR 都没法凭 CI 判断自己有没有问题——#1 就是这么过了好几天,作者只能逐条核「这条红是不是我引入的」。两笔,各修一类。
Clippy(三行矩阵全红)
Rust 1.98 的 clippy 不再接受常量大小的
chunks_exact。命中四处读 16 位采样的地方:tests/support、examples/support、src/pipeline/tests、以及 xtask 的 wav 读取。as_chunks::<2>()给的是[u8; 2]而不是「恰好装两个元素的切片」,所以from_le_bytes整个接过去,下标也没了。尾部落单的那个字节处理方式不变——两种写法都忽略余数。slice_as_chunks自 1.88.0 稳定,正好是本 crate 的 MSRV,所以 1.88 那个 job 照旧能编。src/pipeline/clustering.rs里还有一处chunks_exact,没动:它的大小是运行时变量,这条 lint 不管它。Cargo deny
三条:h2 0.4.15(RUSTSEC-2026-0258,无界的空 DATA 帧)、rustls 0.23.41(RUSTSEC-2026-0285,TLS 1.3 握手消息跨加密层被接受)、der 0.8.0 被 yank。
都不是本 crate 自己的代码碰得到的——前两个经 hf-hub 的 ureq 进来,第三个经 ort-sys。所以这一笔只动锁文件。
cargo update选的版本都在 1.88 这条线以内:h2 0.4.19、rustls 0.23.45、rustls-webpki 0.103.15、der 0.8.2。本地照 workflow 传的那套参数验过:
advisories ok, bans ok, licenses ok, sources ok。验证
cargo clippy --workspace --all-targets -- -D warnings:干净(本机 1.90,所以那条 1.98 的 lint 本地不会触发;它是靠「一处chunks_exact常量写法都不剩」保证的,grep 过)cargo test --workspace:76 通过 / 7 失败,与改动前逐条相同——那 7 条要仓库里没有的模型 fixture对现有部署的影响
无。lint 改的是测试与 xtask,锁文件换的三个包都不在本 crate 的调用路径上。
🤖 Generated with Claude Code