{"slug": "ai-slop-by-robobun", "title": "AI Slop by Robobun", "summary": "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.", "body_md": "# ai slop#33864\n\n[robobun](/robobun)wants to merge 3 commits into\n\n## Conversation\n\nThis PR has been marked as AI slop and the description has been updated to avoid confusion or misleading reviewers.\n\nMany 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.\n\n## 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\n## 🚥 Pre-merge checks | ✅ 4## ✅ Passed checks (4 passed)\n|\n\nUpdated 2:34 PM PT - Jul 9th, 2026❌\n`Build #71145` |\n\n**reviewed**\n\n[claude](/apps/claude)BotJul 9, 2026\n\n###\n**\n**[claude](/apps/claude)\nBot\nleft a comment\n\n**left a comment**\n\n[claude](/apps/claude)Bot\n\nThere was a problem hiding this comment.\n\nLGTM — targeted encoding fix with the ASCII fast-path preserved; the bytecode-generation sibling noted inline is a strict follow-up, not a regression.\n\n## Extended reasoning...\n\n### Overview\n\nTwo one-line changes swapping `String::clone_latin1`\n\n→ `String::clone_utf8`\n\non the `already_bundled`\n\nloader paths in `src/runtime/jsc_hooks.rs`\n\nand `src/jsc/RuntimeTranspilerStore.rs`\n\n, plus four new `itBundled`\n\ntests in `bundler_banner.test.ts`\n\n/ `bundler_footer.test.ts`\n\ncovering non-ASCII banner/footer under `--target=bun`\n\nfor both the sync entry and async-import code paths.\n\n### Security risks\n\nNone. This is an encoding-correctness fix on bytes that Bun itself wrote to disk. No untrusted-input parsing surface is introduced; `clone_utf8`\n\n→ `BunString__fromBytes`\n\nalready handles invalid UTF-8 (falls through to `WTF::String::fromUTF8`\n\nwhich produces null on malformed input, same as any other file load).\n\n### Level of scrutiny\n\nLow-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`\n\n(BunString.cpp:479) does `simdutf::validate_ascii`\n\nfirst and falls through to the identical `BunString__fromLatin1`\n\nwhen the input is all-ASCII — which is essentially always true for `// @bun`\n\noutput — so the only added cost is one SIMD ASCII scan. No behavior change for the common case.\n\n### Other factors\n\nThe tests are well-structured: they assert the `// @bun`\n\npragma is present (proving the fast path is exercised), assert exact stdout including `.length`\n\n(proving code-unit count, not just visual match), and cover both loader sites via a direct-entry run and an `import \"./out.js\"`\n\nruntime file. The one nit found — the paired build-time bytecode path in `ZigSourceProvider.cpp`\n\nstill constructing via Latin-1, causing a silent `.jsc`\n\ncache miss when combined with `--bytecode`\n\n+ 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.\n\n[src/runtime/jsc_hooks.rs](/oven-sh/bun/pull/33864/files/c1197bc56289dbb0d88c7079213b6ae173a9793c#diff-9a03c705fa3868e895a7eecde4630a9e9d1012898356bf72e6f2e95aef12f800)\n\n**reviewed**\n\n[claude](/apps/claude)BotJul 9, 2026\n\n###\n**\n**[claude](/apps/claude)\nBot\nleft a comment\n\n**left a comment**\n\n[claude](/apps/claude)Bot\n\nThere was a problem hiding this comment.\n\nLGTM — the follow-up commit addresses the bytecode SourceCodeKey sibling site I flagged, and the new `NonAsciiBannerTargetBunBytecode`\n\ntest asserts the cache actually hits.\n\n## Extended reasoning...\n\n### Overview\n\nThree one-line swaps from Latin-1 → UTF-8 decoding on the `// @bun`\n\nalready-bundled loader paths (`jsc_hooks.rs`\n\nsync entry, `RuntimeTranspilerStore.rs`\n\nasync import) plus a matching 5-line `stringFromPrinterBytes`\n\nhelper in `ZigSourceProvider.cpp`\n\nfor the two build-time bytecode-generation entry points. Five new `itBundled`\n\ntests cover the sync path, async-import path, non-ASCII identifier, footer, and bytecode cache-hit under `BUN_JSC_verboseDiskCache=1`\n\n.\n\n### Security risks\n\nNone. This decodes the user's own bundler output from disk; no untrusted network input, no auth/crypto/permissions surface. `clone_utf8`\n\n→ `BunString__fromBytes`\n\nand `stringFromPrinterBytes`\n\nboth take the simdutf `validate_ascii`\n\nfast-path to the same Latin-1 memcpy for the overwhelmingly-common all-ASCII case, and fall back to `fromUTF8ReplacingInvalidSequences`\n\non invalid UTF-8 (never null / never unbounded).\n\n### Level of scrutiny\n\nLow-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`\n\n(the non-ASCII arm of `clone_utf8`\n\n) and `stringFromPrinterBytes`\n\nproduce equivalent UTF-16 for both valid and invalid UTF-8, so build-time and load-time `SourceCodeKey`\n\ns agree.\n\n### Other factors\n\nMy 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.\n\n**reviewed**\n\n[claude](/apps/claude)BotJul 9, 2026\n\n###\n**\n**[claude](/apps/claude)\nBot\nleft a comment\n\n**left a comment**\n\n[claude](/apps/claude)Bot\n\nThere was a problem hiding this comment.\n\nLGTM — the sibling bytecode-generation path is now aligned and covered by the cache-hit assertion.\n\n## Extended reasoning...\n\n### Overview\n\nTwo one-line changes in the `already_bundled`\n\nloader arms (`jsc_hooks.rs`\n\n, `RuntimeTranspilerStore.rs`\n\n) switching `String::clone_latin1`\n\n→ `String::clone_utf8`\n\n, plus a 6-line `stringFromPrinterBytes`\n\nhelper in `ZigSourceProvider.cpp`\n\nso the build-time bytecode `SourceCodeKey`\n\nis derived from the same decoding as the load-time key. Five new `itBundled`\n\ntests cover sync entry, async import, footer, non-ASCII identifier, and the CJS+bytecode cache-hit path.\n\n### Security risks\n\nNone. This is a source-decoding change on the `// @bun`\n\nfast path; no auth/crypto/permissions surface.\n\n### Level of scrutiny\n\nModule loader is a hot path, but the change is narrow: `clone_utf8`\n\ncalls `BunString__fromBytes`\n\n, which fast-paths to the identical Latin-1 memcpy when `simdutf::validate_ascii`\n\npasses (the overwhelming case for printer output), and only diverges on the exact inputs that were previously mojibake. I verified `stringFromPrinterBytes`\n\nand `BunString__fromUTF8`\n\nagree on valid-UTF-8 (both produce the canonical UTF-16) and on invalid-UTF-8 (both route through `fromUTF8ReplacingInvalidSequences`\n\n), so build-time and load-time keys match. The transpiled (non-already-bundled) print path still correctly uses `clone_latin1`\n\non `Format::EsmAscii`\n\noutput, which is unchanged.\n\n### Other factors\n\nMy earlier comment about the paired `generateCached*ByteCodeFromSourceCode`\n\nsites was addressed in [ 68c1594](https://github.com/oven-sh/bun/commit/68c15940045c41ff072c0363dd6f6024d9276fb3) with the shared helper and a\n\n`banner/NonAsciiBannerTargetBunBytecode`\n\ntest that asserts `[Disk Cache] Cache hit for sourceCode`\n\nunder `BUN_JSC_verboseDiskCache=1`\n\n— 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.|\nCI is failing on unrelated lanes across three runs (71111, 71126, 71145):\nNone of these touch the module loader, bundler, or bytecode generation paths this PR changes. |\n\n|\nThis 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:\nIf you believe this was done in error, please leave a comment explaining why. |\n\n[github-actions](/apps/github-actions)Bot changed the title\n\nJul 9, 2026\n\n[Learn more about bidirectional Unicode characters](https://github.co/hiddenchars)", "url": "https://wpnews.pro/news/ai-slop-by-robobun", "canonical_source": "https://github.com/oven-sh/bun/pull/33864", "published_at": "2026-07-10 11:54:47+00:00", "updated_at": "2026-07-10 12:05:49.260080+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Robobun", "Bun", "Claude Bot"], "alternates": {"html": "https://wpnews.pro/news/ai-slop-by-robobun", "markdown": "https://wpnews.pro/news/ai-slop-by-robobun.md", "text": "https://wpnews.pro/news/ai-slop-by-robobun.txt", "jsonld": "https://wpnews.pro/news/ai-slop-by-robobun.jsonld"}}