Investigate native Windows ARM64 access violations across Wave cases

[LunaStev]

Evidence

After #486 supplies the native ARM64 libxml2 link dependency, the Windows ARM64 cases job builds the release compiler but reports 0 passes / 123 failures:

• 113 commands exit with 3221225477 (0xC0000005, Windows access violation), generally without stderr.
• 10 commands exit with 1 and the explicit HOME/std-discovery diagnostic; that is tracked separately in Resolve the native Windows std directory when HOME is absent #492.

The first access violation is shared/test1.wave; test2, test3 and many other basic cases fail the same way. The log reaches Finished release profile and verifies 44 ARM64 libxml2 objects. The separate native build job also passes its three Rust unit tests. The original LNK1181 xml2s.lib failure is no longer the stopping point.

Investigation scope

Use #486 head 6fb6ed7 on windows-11-vs2026-arm with the workflow's native LLVM 21.1.8 MSVC SDK and ARM64 llvm-mingw linker. Run the case harness's command for shared/test1.wave, then isolate frontend checking, IR emission, object emission, linking and generated-program execution. Capture a native debugger stack or crash dump at the first access violation before selecting a fix.

The current logs do not establish whether this is LLVM/compiler execution, target object generation, linking support or the generated program. Do not assume that setting HOME, changing libxml2 versions or using an x64 compiler resolves it.

Acceptance

• Identify the crashing process and phase and record a stack trace with toolchain versions.
• Reduce at least one failing basic case to a small reproducer.
• Fix the root cause and add a regression at the appropriate compiler/runtime layer.
• Native Windows ARM64 cases pass with ARM64 compiler/dependencies; retain existing shared cases rather than skipping them.
• Keep the HOME/std-directory fix separately identifiable.

Start with tools/run_tests.py, .github/workflows/cases.yml (the windows_arm64 lane) and tests/cases/shared/test1.wave. Related: #482, #486, #292. This requires native debugging and is not a good first issue.

[LunaStev]

The native Windows ARM64 access violation remains visible in PR #520's case job, at 2ae0a91c57fd76323124c0e4dff552adbfadbe1b. For example, shared/test110.wave through shared/test113.wave and shared/test115.wave exit with 3221225477 (0xC0000005), without a diagnostic identifying the failing phase.

The nearby shared/test114.wave failure is different: it exits 1 with E2001 because a newly added local uses reserved byte as its identifier. That testcase defect is being tracked separately and is not an explanation for the repeated access violations.

The existing request for a native debugger stack and compiler/linker/generated-process phase isolation still applies. This update adds observed CI evidence, not a claimed root cause or a new duplicate issue.

[LunaStev]

New native evidence from PR #569 head 834368d33f2595dfb8db1ef48dc2cd9e6850dade:

Native ARM64 build log

The native LLVM 21.1.8 compiler builds and passes Clippy, library tests and frontend driver tests. wavec -V and print default-target succeed. The GNU object command for tests/cases/windows/arm64/test1.wave exits with -1073741819 / 0xC0000005 before artifact inspection.

The final codegen trace is:

initialize targets
create context
create module
create builder
resolve target triple
lookup target
create target machine
set target metadata

Neither finish module nor emit target machine output is reached. This locates the crash in the compiler during module construction, before object emission, linking or generated-program execution. set target metadata marks the beginning of a broad section; it does not identify the exact failing LLVM call.

The native ARM64 cases job also remains failed. Next work should capture a native debugger stack with symbols and reduce a no-import main for explicit GNU and MSVC targets, narrowing metadata/type/function lowering before choosing a fix. The underlying access violation remains unresolved; the new trace and exit checks only expose it. Implementation has been paused for today.

[LunaStev]

PR #574 head ed149e7553c06efc30b5167920cc301563d6afb3 now provides a native debugger stack and a minimal reproducer.

Native ARM64 diagnostic job, Windows ARM64 cases.

Environment: native ARM64 wavec 0.2.1-pre-beta-dev, LLVM/LLDB 21.1.8, Windows build 10.0.26200.9168, windows-11-vs2026-arm. The compiler's ARM64 PE machine is validated. Version/default-target/LLVM/debugger probes succeed. The cases job reports 0 passes / 135 failures, all with exit 3221225477 (0xC0000005).

This no-import input passes wavec check:

fun main() -> i32 {
    return 0;
}

Both commands crash before producing IR:

wavec build minimal.wave --target=aarch64-pc-windows-gnu --emit=ir --out-dir minimal-gnu-ir
wavec build minimal.wave --target=aarch64-pc-windows-msvc --emit=ir --out-dir minimal-msvc-ir

Both stop after release target data layout; set target ABI metadata is not reached. LLDB's minimal MSVC stack includes:

Exception 0xc0000005: Access violation reading location 0x802041208020412
frame #0: wavec.exe`__jit_debug_register_code + 11432368
frame #1: llvm::codegen::ir::build_module() at ir.rs:921
frame #2: llvm::codegen::ir::generate_ir() at ir.rs:706
frame #3: wavec::runner::emit_wave_ir_text() at runner.rs:565

Line 921 is drop(data_layout), after TargetData::get_data_layout() and module.set_data_layout(). Inkwell 0.8.0 creates an owned LLVM string through LLVMCopyStringRepOfTargetData; its destructor invokes LLVMDisposeMessage. This narrows the next investigation to that allocation/disposal path in the native SDK linkage. The large offset from the nearest visible symbol is not evidence that JIT registration is the failing operation, and allocator mismatch remains a hypothesis to verify, not a confirmed root cause. Do not treat leaking this string as a complete fix.

The retained windows-arm64-codegen-diagnostics artifact contains logs, the native compiler, and its PDB (seven-day retention). The imported test1.wave also crashes promptly outside LLDB, but its two debugger runs time out; collector reliability is separately tracked in #581. The diagnostic failure also suppresses independent checks, now tracked in #575.

No compiler fix or issue closure is claimed in this audit.

[LunaStev]

PR #606 head 037baf248a9793be2b0563fb28972b5c4fb9714a provides new native ARM64 validation: build job.

• llvm_messages_and_target_layouts_share_allocator_ownership passes (1 test), including explicit message/layout destruction.
• The diagnostic helper's minimal and imported fixture checks, GNU/MSVC IR emission, and GNU/MSVC object emission all exit 0.
• Native unit/frontend tests and the MSVC companion-artifact regression also pass.

The previously captured drop(data_layout) access violation is no longer reproduced by these probes with the static-CRT change. Full native case validation is still blocked: #608 tracks the separate psapi build failure in the cases workflow, and #609 tracks compiler stack overflow when compiling the async executor fixture in the build workflow. The latter occurs before generated-program execution and is a different symptom from the original access violation.

This is a validation update, not an issue closure or a claim that all native cases passed.