mirror of
https://github.com/storytold/photocraft.git
synced 2026-11-07 10:54:10 +00:00
Hartmut NörenbergandClaude Opus 5.5
e16450d4e2
* fix(plugins): the install error names the format the file actually is (#10362) Plug-ins > Install Plug-in pointed at an old Photoshop plug-in (.8bt) answered with "not a valid plug-in module: not a WebAssembly binary (missing \0asm header)". That was one fixed message for every file that is not wasm: it said what we wanted and nothing about the file the person is holding. format_hint in runtime.rs now reads the magic number and the error says what the file looks like. For a Windows module the message is (one line in the code, wrapped here): not a valid plug-in module: not a WebAssembly binary (missing \0asm header); this file looks like a Windows native executable or library (a .dll, or a Photoshop plug-in such as .8bf/.8bt) - PhotoCraft plug-ins are WebAssembly modules (.wasm) 7F 45 4C 46 says "a Linux native library (ELF)", CE FA ED FE / CF FA ED FE / CA FE BA BE / BE BA FE CA say "a macOS native binary (Mach-O, thin or fat)", 50 4B 03 04 / 50 4B 05 06 say "a zip archive". Any other header keeps today's message byte for byte, so nothing keyed on it changes. The signatures are public format facts, read with starts_with/get so a short or hostile file cannot panic. The error variant, the enum, the ABI check, check_code_section and the wasmi setup are untouched, and native-code loading stays out of scope (PR #7907). Fail-first, before the production change: cargo test -p photocraft-plugins --lib --tests lib: test result: ok. 10 passed; 0 failed abi: test result: FAILED. 19 passed; 1 failed; 0 ignored; 0 measured assertion line: "windows dll or .8bt: not a valid plug-in module: not a WebAssembly binary (missing \0asm header)" (the MZ fixture that was already in the file) cargo test -p photocraft-engine --lib -- plugin test result: FAILED. 7 passed; 1 failed; 0 ignored; 0 measured; 2518 filtered out After: cargo test -p photocraft-plugins lib 10 passed; abi 20 passed; doc-tests 0 cargo test -p photocraft-engine --lib -- plugin test result: ok. 8 passed; 0 failed; 2518 filtered out The new engine test drives the real plugin.install command with a `path` whose file starts with MZ bytes, so it covers the menu path (registry::load_file) end to end, not only the library check. Gates: cargo clippy -p photocraft-plugins --all-targets -- -D warnings and cargo clippy -p photocraft-engine --all-targets -- -D warnings (clean; the only stderr noise is the pre-existing "patch `egui_*` was not used in the crate graph" cargo warnings); cargo xtask layers ("OK: 31 crates, no layering violations."); cargo xtask wasm (" ok 24 crates", " ok photocraft- codecs --features heif", no FAIL line); cargo fmt -p photocraft-plugins -- --check and cargo fmt -p photocraft-engine -- --check (silent, exit 0). The whole engine --lib suite is not run here: it fails on clean main in this checkout for font/i18n reasons (no CRAFT_FONTS_DIR). No doc quoted the old message (git grep "WebAssembly binary" finds only this crate), so nothing to update there. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(plugins): one install-error test per recognised format, tempfile in the engine test (#10362) Review feedback on #10633. The single looped test in abi.rs is now one test per signature (PE/COFF MZ, ELF, Mach-O in all four byte orders, zip), one for an empty or unrecognised file (including signatures cut short, which keep the old message byte for byte) and one showing a valid WebAssembly module still loads. The engine test uses tempfile::tempdir (already a dependency of photocraft-engine) so the directory is removed on a panic, and asserts the message does not contain the temp path: the hint is static text, so the message adds no path. Gates: cargo test -p photocraft-plugins --lib --tests (10 lib, 26 tests); cargo test -p photocraft-engine --lib -- plugin (8 passed); clippy -D warnings on both crates; cargo fmt --all -- --check; cargo xtask layers (OK). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(engine): keep the non-wasm install-error test off wasm32, as tempfile is (#10362) tempfile is a non-wasm32 dependency of photocraft-engine, so the test that uses it is gated like the crate's other file-system tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>