Switch to C++ codegen by default #598
Open
Conversation
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
This currently doesn't work with ASan, but I have an open issue for this here: bdwgc/bdwgc#772
It leaks, leads to premature GC, takes too long to compile, and doesn't support runtime sorting functions. We'll need a new solution. For now, we're deep copying standard containers, which isn't going to last us very long.
This addresses a GC crash we were seeing, as documented here: bdwgc/bdwgc#800 (comment)
It's blocked on this Clang bug: llvm/llvm-project#146956
pfeodrippe
added a commit
to pfeodrippe/jank
that referenced
this pull request
Nov 26, 2025
Merged the C++ codegen branch from jank-lang#598 Key changes from the PR: - Fixed void return handling in codegen - Improved type handling with cpp_util - Added better error handling in JIT evaluation - Fixed let binding codegen for arrays - Added JANK_PRINT_IR environment variable for debugging Merged changes were combined with WASM support from nrepl branch: - Kept jank_target_wasm CMake option - Kept jank_debug_gc option from PR - Added wasm-aot codegen type to CLI - Preserved WASM-specific include directories and source files - Fixed codegen_type_str switch for wasm_aot enum value
This was needed to support some `is` usages within the clojure-test-suite.
1. Dedupe lifted constants/vars across arities 2. Remove lifting of nil/bools 3. Remove baked in `using namespace` usages Much, much more to go.
We want to dedupe them by arity, which gives us just as much work in codegen as tracking them normally would, if not more. This also gives each codegen processor its own flexibility about which things to lift and at which scope to do it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
On main, we have issues with the GC on Linux and macOS. It doesn't collect! After working to resolve these issues (in #549), I managed to get Linux working, but macOS would still crash due to premature collections. I found that the issues don't happen with C++ codegen, so I'm committing us to that for the alpha release. We can sort out why the IR leads to premature collections as we move forward, but I've already put a couple solid weeks into this and there's too much else to do.
Embracing C++ codegen makes sense for other reasons, too. It's far simpler than IR gen. It leads to faster runtime performance than IR gen. It celebrates that jank is C++ and it more closely ties jank's AST to C++. It also allows us to not worry about entire unimplemented IR features like destructors.
I still plan on keeping IR gen, but we can develop it in parallel, take our time with it, and enable it by default when it makes sense to do so. There should never be a behavioral difference between the two.
This closes #549.
This closes #372.
This replaces #349, so it's no longer needed in the alpha.
This closes #354.
This replaces #242, so it's no longer needed in the alpha.