Error printing collections when items are Clojure functions

[shantanu-sardesai]

Issue Description

There is a possible regression in jank wherein using Clojure functions as collection items causes a runtime error. Still looking into it further, but this was an issue I noticed in my local build and also in the jank-alpha from brew I ran after updating it (brew reinstall jank-lang/jank/jank). Thought to bring it up here in case someone can confirm to me if this is an actual issue or not.

I've also chosen to ignore the warning on the health check of my brew installation since it's regarding AOT builds and my local build, even without that warning, also throws the same error.

Reproduction Steps

Setup:

user=> (defn foo [])
#'user/foo

user=> [foo]
user=> #{foo}
user=> {foo 0}
user=> {0 foo}

All cause the following error:

Uncaught exception: invalid object type (expected persistent_string found keyword)

Stack trace (most recent call first):
#0  in ___gxx_personality_v0 + 903 at libc++abi.1.0.dylib
#1  in __Unwind_RaiseException + 403 at libunwind.1.0.dylib
#2  in ___cxa_throw + 79 at libc++abi.1.0.dylib
#3  in jank::runtime::obj::deferred_cpp_function::to_string at jank
#4  in jank::runtime::object::to_string at jank
#5  in jank::runtime::to_code_string at jank
#6  in jank::runtime::detail::native_array_map>::to_string_impl at jank
#7  in jank::runtime::detail::native_array_map>::to_code_string at jank
#8  in main::$_0::operator at jank
#9  in _jank_init_with_pch + 259 at jank
#10 in start + 6075 at dyld

jank health check

For my local build:

─ system ──────────────────────────────────────────────────────────────────────────
─ ✅ operating system: macos
─ ✅ default triple: arm64-apple-darwin24.6.0

─ jank install ────────────────────────────────────────────────────────────────────
─ ✅ jank version: jank-0.1-alpha
─ ⚠️ jank assertions are enabled; performance will be impacted
─ ✅ jank resource dir: ../lib/jank/0.1
─ ✅ jank resolved resource dir: /Users/shantanusardesai/Desktop/code/projects/jank/compiler+runtime/build/../lib/jank/0.1 (ignored for dev build)
─ ✅ jank user cache dir: /Users/shantanusardesai/.cache/jank/arm64-apple-darwin24.6.0-51ae0a95777396bcb32e09fd18a5de3975f101526bfb06b470d49d121095adb9 (not found)

─ clang install ───────────────────────────────────────────────────────────────────
─ ✅ configured clang path: /Users/shantanusardesai/Desktop/code/projects/jank/compiler+runtime/build/llvm-install/usr/local/bin/clang++ (found)
─ ✅ configured clang resource dir: /Users/shantanusardesai/Desktop/code/projects/jank/compiler+runtime/build/llvm-install/usr/local/lib/clang/22 (found)

─ jank runtime ────────────────────────────────────────────────────────────────────
─ ✅ jank runtime initialized
─ ✅ jank pch path: /Users/shantanusardesai/.cache/jank/arm64-apple-darwin24.6.0-51ae0a95777396bcb32e09fd18a5de3975f101526bfb06b470d49d121095adb9 (found)
─ ✅ jank can jit compile c++
warning: (arm64)  skipping debug map object with duplicate name and timestamp: 2026-02-09 22:03:14.000000000 /Users/shantanusardesai/Desktop/code/projects/jank/compiler+runtime/build/libjank-standalone.a(processor.cpp.o)
─ ✅ jank can aot compile working binaries

For my brew installation:

─ system ──────────────────────────────────────────────────────────────────────────
─ ✅ operating system: macos
─ ✅ default triple: arm64-apple-darwin24.6.0

─ jank install ────────────────────────────────────────────────────────────────────
─ ✅ jank version: jank-0.1-alpha
─ ✅ jank resource dir: ../lib/jank/0.1
─ ✅ jank resolved resource dir: /opt/homebrew/Cellar/jank/0.1/bin/../lib/jank/0.1 (found)
─ ✅ jank user cache dir: /Users/shantanusardesai/.cache/jank/arm64-apple-darwin24.6.0-9b209a7b414d4298b30f18158ce90eab4a30092be1013e8d6ed377380a68ac9d (found)

─ clang install ───────────────────────────────────────────────────────────────────
─ ⚠️  configured clang path: /Users/runner/work/jank/jank/compiler+runtime/build/llvm-install/usr/local/bin/clang++ (not found)
─ ✅ runtime clang path: /opt/homebrew/Cellar/jank/0.1/bin/../lib/jank/0.1/bin/clang++ (found)
─ ⚠️  configured clang resource dir: /Users/runner/work/jank/jank/compiler+runtime/build/llvm-install/usr/local/lib/clang/22 (not found)
─ ✅ runtime clang resource dir: /opt/homebrew/Cellar/jank/0.1/lib/jank/0.1/lib/clang/22 (found)
─ jank runtime ────────────────────────────────────────────────────────────────────
─ ✅ jank runtime initialized
─ ✅ jank pch path: /Users/shantanusardesai/.cache/jank/arm64-apple-darwin24.6.0-9b209a7b414d4298b30f18158ce90eab4a30092be1013e8d6ed377380a68ac9d (found)
─ ✅ jank can jit compile c++
Compiled program exited with code '1'.
─ system/clang-executable-not-found ────────────────────────────────────────────
error: Unable to find a suitable Clang 22 binary.


─ ❌ jank cannot jit aot compile working binaries

Stack trace

N/A.

OS Version Information

MacOS Sequoia v15.7.3

I acknowledge that:

• I have searched the jank repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[shantanu-sardesai]

UPDATE: It looks like the issue is with printing a collection, so the following doesn't cause the same issue:

user=> (do [foo] nil)
nil

user=> (do #{foo} nil)
nil

user=> (do {foo 0} nil)
nil

user=> (do {0 foo} nil)
nil

Seems like it might be a bug in the to_string implementation of jank::runtime::obj::deferred_cpp_function.

I've yet to fully catch-up on the latest object model changes, but it might be that currently the get function being called is this one due to which the :name keyword is acting like the fallback instead of a key to search inside the map.

Yep, swapping out the current get call to the following fixes the issue:

auto const name(meta->get(__rt_ctx->intern_keyword("name").expect_ok()));

@jeaye, shall I create a PR with all of existing usages of get in other runtime objects replaced with the above fix? Of course, only for get attempts on meta.

[shantanu-sardesai]

Since I'm impatient 🙂.

[jeaye]

Good find, Shantanu.

shall I create a PR with all of existing usages of get in other runtime objects replaced with the above fix?

The problem here is that get(meta, ...) is calling the member function, but it used to be calling runtime::get, since we're in the runtime namespace and get was accessible without qualification. So the most minimal port is to audit the unqualified get calls in objects to see if they need to be runtime::get.

However, all runtime::get does these days is call the member function, so this is an appropriate time to manually inline any of these which need to be changed anyway, by just using the member function directly rather than using runtime::get. We'll still keep the runtime::get function, though, since it's part of our core API.

[shantanu-sardesai]

Makes sense, in my PR I've inlined calls. I'll check for any other unruly gets and fix them as well 💪!