2 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	995cac5d03	fix(vdisplay): the three hardest FFI calls were exempt from the crate's own unsafe-proof rule ... `#![deny(clippy::undocumented_unsafe_blocks)]` cannot see an unsafe operation that sits directly in an `unsafe fn` body — in edition 2021 `unsafe_op_in_unsafe_fn` is allow-by-default, so a bare call inside such a body needs no block and therefore carries no proof. The file headers claim "every unsafe block carries a SAFETY proof", and that was true; it just did not cover the calls that needed it most. Turning the lint on named exactly three: `DeviceIoControl` and the `ioctl` wrapper in pf_vdisplay.rs — the whole host<->driver control channel — and `restore_displays_ccd` in manager.rs, the call the teardown path depends on to give the operator their physical panels back. Each now carries a real proof, and `ioctl` and `set_render_adapter` grew the `# Safety` heading their callers were owed. Also teaches scripts/wincheck.sh to cover pf-vdisplay, which is what let the above be compile-verified rather than reasoned: the crate's Windows half is ~3,400 lines that Linux CI never compiles. That needed a stub pf-encode (the real one drags ffmpeg-sys, and the admission gate calls exactly one predicate from it) and CompositorPref on the stub core. Verified non-vacuous with a planted type error. pf-win-display's half of the same lint is a separate change — it flags 62 further operations, and they want proofs written one at a time, not in bulk. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:45:11 +02:00
enricobuehlerandClaude Opus 5	28bbaa5250	tools: check and lint Windows-only Rust from a Linux dev box (scripts/wincheck.sh) ... Linux CI never compiles `#[cfg(target_os = "windows")]` code, so a Windows-side edit was unverifiable until the Windows CI job ran or someone tested on a real box. The pf-capture sweep's Phases 3–6 used an ad-hoc version of this harness in a scratch directory; committing it means the next Windows change does not have to rediscover the recipe. The obvious in-tree command fails, and not because of the Windows code: cargo check --target x86_64-pc-windows-msvc -p pf-capture dies in build scripts that compile C for the target — audiopus_sys (cmake wants a VS generator), then ring (needs an MSVC C compiler plus the Windows SDK headers). Both enter through punktfunk-core's `quic` feature. So the script generates a workspace whose members are Cargo.toml copies with `src` SYMLINKED at the real crate directories — nothing to keep in sync, no copies to go stale — plus a ~30-line stub punktfunk-core carrying only `Mode` and `quic::HdrMeta`, which is provably all the Windows capture stack uses. rustls, ring and opus never enter the graph. Every path dep that is not a generated member points at the real crate. Covers pf-frame, pf-win-display and pf-capture with --all-targets, so the Windows `#[cfg(test)]` modules are type-checked too. ~10 s cold, ~1 s warm, into target/wincheck (gitignored). Verified non-vacuous: a deliberate type error planted in a windows-only file (idd_push/stall.rs) is caught and fails the run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 12:07:22 +02:00