ai slop by robobun · Pull Request #33864 · oven-sh/bun

bun build --target=bun emits a // @Bun pragma that tells the module loader to
hand the file to JSC verbatim. The two already_bundled paths built the
WTF::String from the raw file bytes via String::clone_latin1, which treats
each byte as one Latin-1 code unit. The printer's ASCII-only escaping covers
program text, but --banner/--footer are appended as raw bytes, so a non-ASCII
banner put UTF-8 bytes into a file the loader then reinterpreted as Latin-1:
string literals came back mojibake and non-ASCII identifiers became a
SyntaxError.

Switch both sites to String::clone_utf8, which fast-paths through simdutf to
the same Latin-1 memcpy when the input is all-ASCII (the common case) and
UTF-8 decodes otherwise.

The previous commit made the already_bundled loader sites decode source.contents
as UTF-8. generateCached{Module,CommonJSProgram}ByteCodeFromSourceCode still
built the WTF::String via the Latin-1 span constructor, so a non-ASCII
banner/footer under --target=bun --bytecode produced a .jsc whose serialized
SourceCodeKey was derived from the mojibake string while the loader computed
its key from the UTF-8 string. decodeCodeBlock rejected the mismatch and JSC
silently re-parsed, leaving the sidecar as dead weight.

Route both through a helper that mirrors BunString__fromBytes: simdutf
validate_ascii fast-paths to the Latin-1 constructor, else decodes UTF-8.