The win32-x64 COFF backend is missing what #230 added for darwin-arm64. On Windows 11 with v0.3.4, programs using std.args, std.env, std.fs, std.fmt, std.parse or raise/rescue don't build. main @ 7e1a64d still has the gap, cross-built from linux-x64:
| probe | win32-x64.exe build | linux-x64 build + run |
|---|---|---|
std.args.get(1) | BLD004 IR_VALUE_ARGS_GET | ok |
std.env.has("PATH") | BLD004 IR_VALUE_ENV_GET | ok |
std.fs.writeFile + readFileEquals | BLD004 IR_VALUE_FS_HOST | ok |
std.fmt.u32 | BLD004 IR_VALUE_FMT_U32 | ok |
std.parse.parseU16 | BLD004 IR_VALUE_PARSE_RUNTIME | ok |
rescue value(3) err 1 | BLD004 IR_VALUE_RESCUE | ok |
check of a raising fn | BLD004 IR_INSTR_RAISE | ok |
v0.3.4 on a Windows host gives the same args/env/rescue errors, and "runtime helpers currently require the Mach-O or ELF64 object link plan" for fmt/parse/fs.
On main:
- CHECK and RAISE are only allowed on ELF64 and Mach-O, RESCUE on ELF64 and Mach-O arm64 (
buildability_value_support.c:213-214,buildability.c:101-103).emit_coff.chas no cases for them. - The args/env/fs probes above need
build_backend_is_native_graph_runtime, which is ELF64 || MACHO64 (buildability_value_support.c:3-4,:134-174). - fmt/parse build as COFF objects with unresolved
zero_fmt_u32/zero_parse_op, but the COFF descriptor has no runtime link plan, so exe builds are rejected (target_backend.c:38).
Across all 141 IR value kinds, the support table accepts 93 for ELF64 executables that it rejects for COFF (53 for objects). Those are table decisions, not end-to-end builds.
Target facts hide this. On a Windows host, v0.3.4 zero targets --json lists args/env/fs/net/proc as available: true, source: "manifest". On main the host override (target.c:300-306) still grants args/env/fs/net without checking backend support (proc is now excluded on Windows), and target.c:375 labels every granted capability "manifest". Labeling those "host" would at least make the mismatch visible.
Related: #66, #230.
Activity
0No activity yet.