Aggressive Parser/Compiler Stripping for Bytecode-Only Runtime

[yumin-chen]

This PR implements a safe and aggressive removal of the parser and compiler from the QuickJS runtime when explicitly requested via feature flags.

When -fno-eval -fno-regexp -fno-json -fno-module-loader are all provided to qjsc, the toolchain now:

1. Defines JS_RUNTIME_BYTECODE_ONLY in the generated C code.
2. Uses minimal initialization functions (JS_AddIntrinsicBaseObjectsMin, js_std_add_helpers_min, etc.) that avoid pulling in parser-dependent code.
3. Stubbs out "forbidden" features like eval(), new Function(), and JSON.parse() to throw a clear TypeError instead of crashing or silently failing.

The core QuickJS engine and qjsc compiler remain fully functional. The standard test suite passes without regressions. For runtime-only embedding of pre-compiled bytecode, the binary size is reduced by approximately 40% when LTO is used.

---

PR created automatically by Jules for task 13703995254801319840 started by @yumin-chen

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[yumin-chen]

@jules, you don't have to stub out these forbidden functions. THey're alerady handled by -fno-*. please follow this updated specs:
This feature introduces a bytecode-only runtime build mode for QuickJS. When qjsc is invoked with all four parser-disabling flags simultaneously (-fno-eval -fno-regexp -fno-json -fno-module-loader), the generated executable is linked against a minified runtime library (libquickjs-bytecode.a / libquickjs-bytecode.lto.a) that is compiled with CONFIG_BYTECODE_ONLY_RUNTIME defined. This causes LTO to dead-strip the parser and compiler from the final binary, producing a smaller executable suitable for embedded or deploy-only targets.

The feature's scope is strictly the parser/compiler dead-stripping mechanism: detecting when all four flags are simultaneously set, building the minified library, and ensuring LTO can eliminate the unreachable parser/compiler code. The behavioral consequences of the individual flags — such as TypeError on eval, absent JSON global, etc. — are pre-existing behaviors of those flags and are explicitly out of scope for this feature.

The feature formalises the existing "two-stage" qjsc workflow: qjsc (the Build_Engine) always remains full-featured; only the library embedded into the generated executable (the Runtime_Engine) is minified.

---

Glossary

• Build_Engine: The qjsc binary together with libquickjs.a / libquickjs.lto.a. Always compiled without CONFIG_BYTECODE_ONLY_RUNTIME. Retains the full parser, compiler, and all intrinsics. Used at build time to compile JS source to bytecode.
• Runtime_Engine: libquickjs-bytecode.a / libquickjs-bytecode.lto.a. Compiled with CONFIG_BYTECODE_ONLY_RUNTIME. Linked into the executable that qjsc produces. This is the binary that ships to end users or embedded targets.
• Bytecode_Only_Trigger: The condition where all four flags -fno-eval -fno-regexp -fno-json -fno-module-loader are passed to qjsc simultaneously.
• qjsc: The QuickJS ahead-of-time compiler tool. Always built against the Build_Engine.
• CONFIG_BYTECODE_ONLY_RUNTIME: A C preprocessor macro that, when defined, guards all parser/compiler call sites in quickjs.c so that LTO can dead-strip them.
• LTO: Link-Time Optimisation. Used to dead-strip unreachable code from the final linked binary.

---

Requirements

Requirement 1: Bytecode-Only Trigger Detection

User Story: As a developer embedding QuickJS in a resource-constrained target, I want qjsc to automatically select the minified Runtime_Engine when I disable all parser-dependent features, so that the generated executable is as small as possible without manual build-system changes.

Acceptance Criteria

1. WHEN qjsc is invoked with all four flags -fno-eval, -fno-regexp, -fno-json, and -fno-module-loader simultaneously, THE qjsc Compiler SHALL set an internal runtime_needs_parser() predicate to FALSE.
2. WHEN runtime_needs_parser() returns FALSE, THE qjsc Compiler SHALL link the generated executable against libquickjs-bytecode.lto.a (or libquickjs-bytecode.a when LTO is disabled) instead of libquickjs.lto.a / libquickjs.a.
3. WHEN fewer than all four flags are present, THE qjsc Compiler SHALL link against the standard libquickjs library and SHALL NOT activate the Bytecode_Only_Trigger.
4. THE qjsc Compiler SHALL accept the four flags in any order and SHALL treat them as independent, additive feature-disable switches.

---

Requirement 2: Runtime_Engine Build Targets

User Story: As a build-system maintainer, I want dedicated Makefile targets for the bytecode-only runtime libraries, so that CI and downstream embedders can build and depend on them explicitly.

Acceptance Criteria

1. THE Makefile SHALL provide a libquickjs-bytecode.a target that compiles quickjs.c and its dependencies with CONFIG_BYTECODE_ONLY_RUNTIME defined and without LTO.
2. THE Makefile SHALL provide a libquickjs-bytecode.lto.a target that compiles quickjs.c and its dependencies with both CONFIG_BYTECODE_ONLY_RUNTIME defined and LTO enabled.
3. THE Makefile SHALL ensure that libquickjs.a and libquickjs.lto.a (the Build_Engine libraries) are never compiled with CONFIG_BYTECODE_ONLY_RUNTIME.
4. THE Makefile SHALL ensure that the qjsc binary is never linked against libquickjs-bytecode.a or libquickjs-bytecode.lto.a.
5. WHEN make libquickjs-bytecode.a or make libquickjs-bytecode.lto.a is invoked, THE Makefile SHALL produce the corresponding archive without rebuilding the full Build_Engine.

---

Requirement 3: Parser/Compiler Absence from Runtime_Engine Binary

User Story: As a security-conscious embedder, I want to verify that the parser and compiler are physically absent from the Runtime_Engine binary, so that I can guarantee no source-code execution path exists at runtime.

Acceptance Criteria

1. WHEN quickjs.c is compiled with CONFIG_BYTECODE_ONLY_RUNTIME defined, THE Compiler SHALL guard every call site that invokes the JS parser or bytecode compiler behind #ifndef CONFIG_BYTECODE_ONLY_RUNTIME preprocessor blocks.
2. WHEN the Runtime_Engine is linked with LTO enabled, THE Linker SHALL dead-strip all parser and compiler translation units, leaving no reachable parser or compiler symbols in the final binary.
3. WHEN nm or an equivalent symbol-inspection tool is run against a binary linked with libquickjs-bytecode.lto.a, THE Binary SHALL contain no defined symbols whose names match the pattern of internal parser or compiler functions (e.g. js_parse_*, js_compile_*, __JS_EvalInternal).
4. THE test-bytecode-runtime CI target SHALL execute the symbol-inspection check described in criterion 3 and SHALL fail the build if any forbidden symbols are present.

---

Requirement 4: Build_Engine Integrity

User Story: As a developer using qjsc to compile JS source files, I want the Build_Engine to remain fully functional regardless of whether the bytecode-only feature is active, so that my compilation workflow is unaffected.

Acceptance Criteria

1. THE Build_Engine (qjsc binary and libquickjs.a / libquickjs.lto.a) SHALL always be compiled without CONFIG_BYTECODE_ONLY_RUNTIME.
2. THE Build_Engine SHALL retain the full parser, compiler, all intrinsics, and all JS_AddIntrinsic* functions regardless of which -fno-* flags are passed to qjsc.
3. WHEN qjsc compiles a JS source file with the Bytecode_Only_Trigger active, THE Build_Engine SHALL successfully parse and compile the source file to bytecode using the full parser.
4. IF the Build_Engine is accidentally compiled with CONFIG_BYTECODE_ONLY_RUNTIME defined, THEN THE Build_Engine SHALL emit a compile-time error (#error) to prevent a silently broken qjsc binary.

---

Requirement 5: Hidden Dependency Audit

User Story: As a security auditor, I want all indirect parser call sites to be identified and guarded, so that no parser invocation can leak through edge-case language features in the Runtime_Engine.

Acceptance Criteria

1. THE Runtime_Engine SHALL NOT invoke the parser or compiler through Function.prototype.toString() when called on a bytecode function object; THE Runtime_Engine SHALL return the source string stored in the bytecode debug info if present, or a placeholder string if debug info is stripped.
2. WHEN import.meta is accessed in a Runtime_Engine context for a pre-compiled module, THE Runtime_Engine SHALL return the import.meta object populated at compile time without invoking the parser.
3. THE Runtime_Engine SHALL NOT invoke the parser or compiler through any Reflect or Proxy trap that could trigger dynamic code evaluation.
4. WHEN CONFIG_BYTECODE_ONLY_RUNTIME is defined, THE Compiler SHALL emit a compile-time warning or static assertion if any guarded parser call site is found to be reachable through a non-guarded code path.

---

Requirement 6: Bytecode Round-Trip Equivalence

User Story: As a developer deploying pre-compiled bytecode, I want programs compiled by the Build_Engine and executed on the Runtime_Engine to produce identical results to running the same programs on the full runtime, so that I can trust the minification does not alter program semantics.

Acceptance Criteria

1. WHEN a JS program is compiled by the Build_Engine using JS_WriteObject and then loaded and executed on the Runtime_Engine using JS_ReadObject + JS_EvalFunction, THE Runtime_Engine SHALL produce output identical to executing the same program on the full runtime.
2. FOR ALL valid bytecode objects produced by JS_WriteObject on the Build_Engine, JS_ReadObject on the Runtime_Engine SHALL successfully deserialise the object without error.
3. FOR ALL valid bytecode objects b, serialising b with JS_WriteObject on the Build_Engine and then deserialising the result with JS_ReadObject on the Runtime_Engine SHALL produce a functionally equivalent bytecode object (round-trip property).
4. THE test-bytecode-runtime CI target SHALL include at least one round-trip test that compiles a non-trivial JS program on the Build_Engine and verifies identical output when run on the Runtime_Engine.

---

Requirement 7: CI Integration

User Story: As a CI maintainer, I want a dedicated test target that validates the bytecode-only runtime end-to-end, so that regressions in parser stripping or round-trip correctness are caught automatically.

Acceptance Criteria

1. THE Makefile SHALL provide a test-bytecode-runtime target that builds libquickjs-bytecode.lto.a, compiles a representative JS test program using the Bytecode_Only_Trigger, and executes the resulting binary.
2. WHEN the test-bytecode-runtime target is run, THE CI System SHALL verify that no parser or compiler symbols are present in the generated binary as specified in Requirement 3, criterion 3.
3. WHEN the test-bytecode-runtime target is run, THE CI System SHALL verify the bytecode round-trip equivalence property as specified in Requirement 6, criterion 4.
4. WHEN the test-bytecode-runtime target is run, THE CI System SHALL verify that the compiled binary executes correctly and produces the expected output.
5. THE test-bytecode-runtime target SHALL be runnable independently of the full test target and SHALL complete without requiring the test262 suite.

[yumin-chen]

Add comprehensive tests that:

1. ensure BigInt, closures with mutation, generators, async/await, Map/Set iteration still work
2. test std.evalScript, std.loadScript, std.parseExtJSON are absent from the std module at runtime
3. test os.Worker is absent from the os module at runtime
4. test Function.prototype.toString() on a bytecode function
5. test of import.meta.url on a pre-compiled module
6. test that the bytecode-only binary rejects a partial/corrupted bytecode buffer gracefully

And the following must not be guarded (as they are required for bytecode execution):

JS_ReadObject
JS_EvalFunction
JS_EvalFunctionInternal
free_function_bytecode
js_closure