[nooga]

with-folded-salt's fully-literal branch crashes at runtime for any salt-key encoding to 33 bytes or more. Fixes #204.

What was happening

The branch encodes the whole salt-key at expansion time and splices the byte buffer into the emitted form as a compile-time constant. encode-salt builds that buffer with conj, and let-go's conj promotes ArrayVector to PersistentVector above 32 elements.

let-go's compileForm type switch has a case for ArrayVectorType but none for PersistentVectorType, and no default: — so the form emits no bytecode at all. The expansion compiled clean and then panicked on a short stack when called:

(defn f [seed] (with-folded-salt seed [:combat :hit 12 34]))
(f 42)   ;=> error: runtime error: index out of range [-1]

33 bytes is not an exotic size. The macro's own docstring example, [:combat :hit attacker target], reaches it the moment its variable terms are literals.

The fix

One vec, which rebuilds the buffer as an ArrayVector.

into would not do: it goes through conj and promotes straight back. The macro's other three splice sites already go through vec, which is why this was the only branch affected — and why the partial-literal path, which people actually hit in the inner loop, kept working and hid this.

Filed upstream as nooga/let-go#943 with a core-only 8-line repro. That issue also covers the missing default:, since SortedMapType and SortedSetType are absent from the same switch and fail identically — it is a class of silent miscompile, not one missing case. This workaround comes out when the upstream fix ships; the comment says so and names the test that will catch it going early.

The test

Straddles the boundary with one character of keyword name:

salt-key	bytes	before
[:combat :hi 1 2]	32	ok
[:combat :hit 1 2]	33	panic

Also covers a 48-byte key mixing strings with keywords and ints, and multi-byte UTF-8 in a folded string term.

Worth knowing: this guard cannot fail softly. Drop the vec and the panic takes the whole suite down rather than reporting an assertion failure. For a silent miscompile that is the point. Verified both directions — lg xsofy/test/run.lg exits 1 without the fix, 0 with it, so CI does catch it.

Why nothing caught it before

with-folded-salt-equals-combine-fully-literal uses [:combat :hit] — 15 bytes, under the threshold. The other three with-folded-salt tests exercise the partial-literal, no-literal-prefix and non-vector paths, which build their vectors at runtime where a PersistentVector is harmless. So the fully-literal path had coverage that could not fail.

Verification

• 331 tests, 2870 assertions, 0 failures (was 330/2864)
• make smoke-lg passes
• Hashes are unchanged: vec produces an equal vector, and the existing golden-value tests pin that

Branched off main; touches only with-folded-salt, so it is independent of #202.

🤖 Generated with Claude Code

[mparrett]

No findings.

Verified locally:

• Reproduced the pre-fix index out of range [-1] panic at the 33-byte boundary on the base commit.
• Confirmed the patched expansion forces the folded constant back to ArrayVector and returns the same hash as combine.
• lg xsofy/test/run.lg: 331 tests, 2,870 assertions, 0 failures, 0 errors.
• make smoke-lg: passes.

The workaround is narrowly scoped, and the regression test covers both sides of the 32/33-byte boundary plus larger and multibyte inputs.

[github-actions]

PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-09-21 11:46 UTC