Make --compile --bytecode executables work when cross-compiled (portable JSC bytecode cache) - #40270

…ven-sh/WebKit#389)

…e version hash

… every source-reachable opcode

features.js grows to cover every operator/jump form, property access and
definition form, call form, sloppy-only construct, function/class shape and
constant kind the front end has bytecode for; a generated big.js adds what
only large functions produce (wide16 operands, a 32-bit metadata table,
out-of-line jump targets, a >64 KB constant, a multi-page payload). Measured
with llvm-cov on CachedTypes.cpp and --dumpGeneratedBytecodes: every encode
path reachable from source, 173/194 opcodes; the test's header says why the
other 21 cannot occur in a cached code block.

…t assume LF-only stderr

…rm-2d6835' into claude/jsc-bytecode-cross-platform-2d6835

…er; merges #502)

- --compile appended up to 128 bytes of never-written buffer after each
  module's bytecode and counted them in its length; embed exactly the payload.
- node:vm cachedData (Script#createCachedData, produceCachedData,
  SourceTextModule#createCachedData) is generated for the whole source with the
  default code-generation mode, instead of serializing whatever the VM's
  CodeCache held (nested functions only if they had already run; debugger /
  profiler opcodes if attached). The module variant is keyed as module code.
- Thread-pool threads reserve the same 18 MB stack on every platform; JSC caps
  its recursion budget at 5 MB, and below that the depth at which the parser /
  bytecode generator give up depended on the platform.
- Portability test: corpus gains the shapes whose encoding used to follow
  process state (Annex B block functions, >9 computed class fields, parse-time
  ** folding, an arrow ending in a multi-line template), and a test that the
  payload is the same under collectContinuously, useSourceProviderCache=0, a
  64 KB heap, and through Bun.build()/vm.Script in a process that ran other JS
  first.

…age in the corpus; WebKit preview-pr-505-d3058e2d

The golden-hash test is what guards the cache format's portability now, so
its corpus has to reach everything: features.js gains the last user-reachable
opcodes it was missing (top-level block functions, arguments.length, postfix
increment), identical functions (shared arrays) and a shared string constant;
lodash, acorn, react-dom, svelte's compiler, rollup and typescript from
test/node_modules are bundled and hashed too (18 MB of payload in all), and
lodash/acorn also go through vm.Script / vm.SourceTextModule.

…rm-2d6835' into claude/jsc-bytecode-cross-platform-2d6835

…nlines it as an absolute path); typescript through vm.Script

…ross-platform-2d6835

…ecord type), a fuller module.js, generated shapes.js sweeps; vm module cachedData is generated as strict code

records.js walks the cache's record types -- strings/identifiers in every
encoding, every constant kind and source representation, array-literal
butterflies, regexps, template objects (incl. absent cooked strings),
bigints, immediate/character/string switch tables, all four exception
handler kinds, spread bit vectors and object-rest identifier sets, symbol
tables of every scope kind, TDZ environment chains, every function parse
mode / naming / parameter / source-position shape, class element
definitions and executable rare data, object-literal definition forms,
control flow, generator/async resume points, wide expression-info deltas,
sloppy-only forms -- with several variations each. module.js covers every
import/export form, top-level await, import.meta, dynamic import and strict
block functions. shapes.js is generated: sweeps of string length (3
widths), integers around each encoding boundary, switch sizes, parameter
and field counts, arrow nesting and closure depth. 21 payloads, 21 MB.

NodeVM's getBytecode() generated module cachedData without
StrictModeLexicallyScopedFeature (JSC's generateModuleBytecode sets it);
a block-level function declaration in a vm.SourceTextModule then failed an
assertion in the bytecode generator. Found by the new module.js.

bun build --compile --bytecode also embeds bytecode for the internal modules
(node:*, bun:*) an app imports, generated through encodeBuiltinFunction from
builtin-syntax source (@-intrinsics, private names, link-time constants) --
record and opcode paths user source never reaches. internal-for-testing gains
internalModuleBytecode(index | source, name) returning exactly those bytes.

The golden hash gains builtin.js, a builtin-syntax corpus (platform-independent
source, so comparable across platforms). Bun's own internal modules have
per-OS source (process.platform is inlined at codegen), so all ~200 of them
go into the process-independence test instead: encoded in the test process
and again in the busy subprocess, hashes must match.

…pared padding bytes)

…y VM) instead of per-VM PrivateSymbolImpls whose hash came from the process-wide symbol counter; builtin bytecode no longer depends on how many symbols the process created first. node:http2 back in the process-independence test.

…m:oven-sh/bun into claude/jsc-bytecode-cross-platform-2d6835

…er each call, as bun build does (on a JS thread it otherwise keeps WTFTimers registered with the main event loop)