ParparVM: remove dead C# target, add Windows LLVM (clang-cl) build + CI#5137
Merged
Conversation
Removes the abandoned C# output target and lays the groundwork for a Windows build of the portable "clean" C target using LLVM (clang-cl / MSVC ABI), preliminary to a future Windows desktop port. - Remove OUTPUT_TYPE_CSHARP and its empty generateCSharpCode()/ appendMethodCSharp() stubs, arg parsing, help text and Parser write branch. Unrecognized output tokens now route explicitly to handleDefaultOutput instead of silently falling through to the iOS default. - Add a self-contained Win32 POSIX shim (cn1_win_compat.h/.c, gated on _WIN32) mapping the runtime's pthread/usleep/gettimeofday usage onto Win32 primitives (SRWLOCK, CONDITION_VARIABLE, Tls*, _beginthreadex, Get/SetThreadPriority). The header is windows.h-free so it can be pulled into every translated unit via cn1_globals.h; layout-mirrored lock structs are _Static_assert-checked against the real Win32 types. POSIX includes in cn1_globals.h/.m and nativeMethods.m are guarded; handleCleanOutput always emits the shim and writeCmakeProject targets C11. - Make the clean-target test harness Windows-aware: clang-cl + Ninja generator, .exe suffix, and no libm link under MSVC. - Add .github/workflows/parparvm-tests-windows.yml running the vm test suite on windows-latest with the MSVC env, clang-cl and Ninja. Verified on macOS: full vm suite 826 run / 0 failures, including CleanTargetIntegrationTest (13/0) which compiles and runs translated C. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Cloudflare Preview
|
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
Collaborator
Author
|
Compared 122 screenshots: 122 matched. Benchmark Results
Detailed Performance Metrics
|
Collaborator
Author
JavaScript port screenshot updatesCompared 73 screenshots: 64 matched, 9 updated.
|
Collaborator
Author
|
Compared 122 screenshots: 122 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 121 screenshots: 121 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Contributor
✅ ByteCodeTranslator Quality ReportTest & Coverage
Benchmark Results
Static Analysis
Generated automatically by the PR CI workflow. |
The runner was executing the entire vm suite (~1h, and it includes the JavaScript integration tests which need Node that this workflow does not install), so it appeared stuck. Scope it to CleanTargetIntegrationTest, which is what actually proves the clang-cl/LLVM Windows build works (translate Java -> C -> cmake/clang-cl -> run). The rest of the suite is platform-agnostic Java already covered on Linux by parparvm-tests.yml. Add a 45m job timeout as a backstop. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ules With -am, surefire also runs in the upstream ByteCodeTranslator module where -Dtest=CleanTargetIntegrationTest matches nothing, which aborts the build. failIfNoTests does not cover the -Dtest specified-tests case in surefire 3.x; surefire.failIfNoSpecifiedTests does. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
PowerShell split the dotted -Dsurefire.failIfNoSpecifiedTests property at the '.', so Maven saw a bogus lifecycle phase. Quoting passes them as literal tokens. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
On Windows the escaped-backslash source-root path produced glob results like
C:\Users\... which CMake rejects as invalid string escapes ('\U') when
expanded into add_executable/add_library. Forward slashes are accepted by CMake
on all platforms; this is a no-op on macOS/Linux. Fixes the clean-target
configure failure under clang-cl on Windows.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
clang-cl flagged these POSIX functions (used by the date/timezone runtime in nativeMethods) as undeclared under the MSVC ABI. Add static-inline wrappers over the MSVC equivalents (_putenv_s, _mkgmtime, localtime_s). Gated on _WIN32, so a no-op elsewhere. Co-Authored-By: Claude Opus 4.8 (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
1 participant
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.
Context
ParparVM's
ByteCodeTranslator.OutputTypehad four backends; the C# target was dead (generateCSharpCode()returned"",appendMethodCSharp()was an empty// todostub with zero callers — abandoned years ago pervm/README.md). Separately, there was no Windows build of the VM. The existingcleantarget is already an LLVM/CMake portable-C path (proven end-to-end on Linux/mac byCleanTargetIntegrationTest).This PR removes the dead C# target and lays the groundwork to build the
cleantarget on Windows using LLVM (clang-cl / MSVC ABI) rather than Visual Studio'scl.exe, plus a CI runner that exercises it. This is preliminary work for a future Windows desktop port (separate task) — targeting the MSVC ABI now means building the Win32 compatibility layer the runtime needs.Changes
Remove the dead C# target
OUTPUT_TYPE_CSHARP, its arg-parse branch, help text, thegenerateCSharpCode()/appendMethodCSharp()stubs, and the Parser C# write branch.handleDefaultOutput(previously they silently fell through to the iOS default — a latent bug). The default-branch test is repointed from"csharp"to"unknown".Win32 compatibility shim (the substantive deliverable)
cn1_win_compat.h/.c(entirely#ifdef _WIN32) maps the runtime's exact POSIX surface onto Win32: pthread mutex→SRWLOCK, cond→CONDITION_VARIABLE, TLS keys→Tls*,pthread_create→_beginthreadex, sched→Get/SetThreadPriority, plususleep/gettimeofday.windows.h-free (layout-mirrored lock structs,_Static_assert-checked against the real Win32 types in the.c) so it's safe to pull into every translated unit viacn1_globals.h.cn1_globals.h/.mandnativeMethods.mare guarded;handleCleanOutputalways emits the shim (inert off-Windows);writeCmakeProjecttargets C11 (for<stdatomic.h>/_Static_assert).Windows-aware test harness
clang-cl+ Ninja generator,.exesuffix, and nolibmlink under MSVC.Windows CI runner
.github/workflows/parparvm-tests-windows.ymlruns the vm test suite onwindows-latestwith the MSVC env, clang-cl and Ninja.Testing
Full vm suite on macOS: 826 run / 0 failures / 0 errors, including
CleanTargetIntegrationTest(13/0/0) which translates Java→C, compiles with clang via CMake, and runs the binary — confirming the C# removal, C11 bump and always-copied shim don't regress the existing POSIX path.The clang-cl-on-Windows path is first exercised by the new workflow in CI; expect to iterate there (most likely a narrow
<stdatomic.h>/linker detail, fixable without touching the POSIX paths).🤖 Generated with Claude Code