AI Slop by Robobun

Robobun submitted a pull request to Bun that changes source content cloning from Latin-1 to UTF-8 in Rust transpiler cache-hit paths, adds a UTF-8 decoding helper for native module/CJS cache generation, and includes bundler tests for non-ASCII banner and footer content. The PR was reviewed by Claude Bot, which confirmed the encoding fix is correct and safe, noting it improves handling of non-ASCII characters without regressions.

ai slop 33864 robobun /robobun wants to merge 3 commits into Conversation This PR has been marked as AI slop and the description has been updated to avoid confusion or misleading reviewers. Many AI PRs are fine, but sometimes they submit a PR too early, fail to test if the problem is real, fail to reproduce the problem, or fail to test that the problem is fixed. If you think this PR is not AI slop, please leave a comment. WalkthroughThis PR changes source content cloning from Latin-1 to UTF-8 in Rust transpiler cache-hit paths RuntimeTranspilerStore and jsc hooks , adds a shared UTF-8 decoding helper stringFromPrinterBytes for native module/CJS cache generation in ZigSourceProvider.cpp, and adds bundler tests covering non-ASCII banner and footer content. Changes 🚥 Pre-merge checks | ✅ 4 ✅ Passed checks 4 passed | Updated 2:34 PM PT - Jul 9th, 2026❌ Build 71145 | reviewed claude /apps/claude BotJul 9, 2026 claude /apps/claude Bot left a comment left a comment claude /apps/claude Bot There was a problem hiding this comment. LGTM — targeted encoding fix with the ASCII fast-path preserved; the bytecode-generation sibling noted inline is a strict follow-up, not a regression. Extended reasoning... Overview Two one-line changes swapping String::clone latin1 → String::clone utf8 on the already bundled loader paths in src/runtime/jsc hooks.rs and src/jsc/RuntimeTranspilerStore.rs , plus four new itBundled tests in bundler banner.test.ts / bundler footer.test.ts covering non-ASCII banner/footer under --target=bun for both the sync entry and async-import code paths. Security risks None. This is an encoding-correctness fix on bytes that Bun itself wrote to disk. No untrusted-input parsing surface is introduced; clone utf8 → BunString fromBytes already handles invalid UTF-8 falls through to WTF::String::fromUTF8 which produces null on malformed input, same as any other file load . Level of scrutiny Low-to-moderate. The module loader is a hot path, but the change is a narrow encoding correction at two well-understood sites. I verified BunString fromBytes BunString.cpp:479 does simdutf::validate ascii first and falls through to the identical BunString fromLatin1 when the input is all-ASCII — which is essentially always true for // @bun output — so the only added cost is one SIMD ASCII scan. No behavior change for the common case. Other factors The tests are well-structured: they assert the // @bun pragma is present proving the fast path is exercised , assert exact stdout including .length proving code-unit count, not just visual match , and cover both loader sites via a direct-entry run and an import "./out.js" runtime file. The one nit found — the paired build-time bytecode path in ZigSourceProvider.cpp still constructing via Latin-1, causing a silent .jsc cache miss when combined with --bytecode + non-ASCII banner — is a strict follow-up: runtime output is now correct where it was mojibake before, so this PR is a strict improvement even on that path. src/runtime/jsc hooks.rs /oven-sh/bun/pull/33864/files/c1197bc56289dbb0d88c7079213b6ae173a9793c diff-9a03c705fa3868e895a7eecde4630a9e9d1012898356bf72e6f2e95aef12f800 reviewed claude /apps/claude BotJul 9, 2026 claude /apps/claude Bot left a comment left a comment claude /apps/claude Bot There was a problem hiding this comment. LGTM — the follow-up commit addresses the bytecode SourceCodeKey sibling site I flagged, and the new NonAsciiBannerTargetBunBytecode test asserts the cache actually hits. Extended reasoning... Overview Three one-line swaps from Latin-1 → UTF-8 decoding on the // @bun already-bundled loader paths jsc hooks.rs sync entry, RuntimeTranspilerStore.rs async import plus a matching 5-line stringFromPrinterBytes helper in ZigSourceProvider.cpp for the two build-time bytecode-generation entry points. Five new itBundled tests cover the sync path, async-import path, non-ASCII identifier, footer, and bytecode cache-hit under BUN JSC verboseDiskCache=1 . Security risks None. This decodes the user's own bundler output from disk; no untrusted network input, no auth/crypto/permissions surface. clone utf8 → BunString fromBytes and stringFromPrinterBytes both take the simdutf validate ascii fast-path to the same Latin-1 memcpy for the overwhelmingly-common all-ASCII case, and fall back to fromUTF8ReplacingInvalidSequences on invalid UTF-8 never null / never unbounded . Level of scrutiny Low-to-medium. The native change is a helper-for-helper swap with no ownership, refcount, or lifetime changes; the ASCII hot path is byte-identical. I verified BunString fromUTF8 the non-ASCII arm of clone utf8 and stringFromPrinterBytes produce equivalent UTF-16 for both valid and invalid UTF-8, so build-time and load-time SourceCodeKey s agree. Other factors My previous review's only finding bytecode-path sibling site was addressed in 68c1594 https://github.com/oven-sh/bun/commit/68c15940045c41ff072c0363dd6f6024d9276fb3 with a test that would fail on key mismatch. PR description shows fail-on-canary / pass-on-PR evidence for both ASAN debug and release. No CODEOWNERS on the touched paths, no outstanding human review comments. reviewed claude /apps/claude BotJul 9, 2026 claude /apps/claude Bot left a comment left a comment claude /apps/claude Bot There was a problem hiding this comment. LGTM — the sibling bytecode-generation path is now aligned and covered by the cache-hit assertion. Extended reasoning... Overview Two one-line changes in the already bundled loader arms jsc hooks.rs , RuntimeTranspilerStore.rs switching String::clone latin1 → String::clone utf8 , plus a 6-line stringFromPrinterBytes helper in ZigSourceProvider.cpp so the build-time bytecode SourceCodeKey is derived from the same decoding as the load-time key. Five new itBundled tests cover sync entry, async import, footer, non-ASCII identifier, and the CJS+bytecode cache-hit path. Security risks None. This is a source-decoding change on the // @bun fast path; no auth/crypto/permissions surface. Level of scrutiny Module loader is a hot path, but the change is narrow: clone utf8 calls BunString fromBytes , which fast-paths to the identical Latin-1 memcpy when simdutf::validate ascii passes the overwhelming case for printer output , and only diverges on the exact inputs that were previously mojibake. I verified stringFromPrinterBytes and BunString fromUTF8 agree on valid-UTF-8 both produce the canonical UTF-16 and on invalid-UTF-8 both route through fromUTF8ReplacingInvalidSequences , so build-time and load-time keys match. The transpiled non-already-bundled print path still correctly uses clone latin1 on Format::EsmAscii output, which is unchanged. Other factors My earlier comment about the paired generateCached ByteCodeFromSourceCode sites was addressed in 68c1594 https://github.com/oven-sh/bun/commit/68c15940045c41ff072c0363dd6f6024d9276fb3 with the shared helper and a banner/NonAsciiBannerTargetBunBytecode test that asserts Disk Cache Cache hit for sourceCode under BUN JSC verboseDiskCache=1 — a key mismatch would fail it. Evidence block shows debug+ASAN and release both green, and the tests fail on canary for the right reasons.| CI is failing on unrelated lanes across three runs 71111, 71126, 71145 : None of these touch the module loader, bundler, or bytecode generation paths this PR changes. | | This PR has been closed because it was flagged as AI slop. Many AI-generated PRs are fine, but this one was identified as having one or more of the following issues: If you believe this was done in error, please leave a comment explaining why. | github-actions /apps/github-actions Bot changed the title Jul 9, 2026 Learn more about bidirectional Unicode characters https://github.co/hiddenchars