dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibJS/RustIntegration.h

214 lines
11 KiB
C
Raw Normal View History

LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
/*
* Copyright (c) 2026, Andreas Kling <andreas@ladybird.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibJS: Serialize compiled bytecode cache blobs Add a versioned Rust bytecode cache writer for fully compiled programs. The blob records executable bytecode, metadata tables, source maps, exception handlers, nested function bytecode, and class blueprints without materializing GC objects. Expose the serialized blob through RustIntegration as an owned ByteBuffer so Web-facing callers can store it as HTTP cache data.
2026-05-03 13:53:38 -03:00
#include <AK/ByteBuffer.h>
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
#include <AK/HashTable.h>
LibJS: Add C++ parse_program/compile_parsed_script wrappers Expose the Rust parse/compile split to C++ callers: - parse_program(): takes raw UTF-16 data and a ProgramType parameter (Script or Module). No GC interaction, thread-safe. - compile_parsed_script(): takes a pre-parsed RustParsedProgram and a SourceCode, checks for errors, and calls rust_compile_parsed_script(). Returns a ScriptResult. Rewrite compile_script() to use the split path internally. The pipeline comparison logic now gets the AST dump from the ParsedProgram before compilation consumes it.
2026-02-27 19:44:14 -03:00
#include <AK/NonnullRefPtr.h>
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
#include <AK/Optional.h>
#include <AK/Result.h>
LibJS: Track shared function data ownership Give scripts and modules an explicit list of their shared function data records, and teach Rust materialization to populate that list directly. This gives bytecode cache installation a stable set of functions to update when replacing executable backing storage.
2026-05-21 16:49:43 -03:00
#include <AK/Span.h>
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
#include <AK/Utf16FlyString.h>
LibJS: Borrow mapped bytecode cache executable bytes Keep executable bytecode payloads decoded from owner-backed bytecode cache blobs as ranges into the original blob instead of copying them into Rust Vec allocations. The mapped blob owner is held by decoded executable records, including lazy nested function executables, so the borrowed bytecode remains alive until materialization copies it into the final C++ Executable. Use the owner-backed decoder for HTTP bytecode cache hits and keep the plain byte decoder for tests and in-memory callers. Add coverage for materializing bytecode cache data from an ImmutableBytes mapped file.
2026-05-15 11:45:31 -03:00
#include <LibCore/ImmutableBytes.h>
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
#include <LibGC/Ptr.h>
#include <LibGC/Root.h>
LibJS: Remove C++ AST Delete AST.cpp, AST.h, ASTDump.cpp, ScopeRecord.h, and the dead get_builtin(MemberExpression const&) from Builtins.cpp. Extract ImportEntry and ExportEntry into a new ModuleEntry.h, since they are data types used by the module system, not AST node types. Inline ModuleRequest's sorting constructor and SourceRange::filename(). Remove the dead annex_b_function_declarations field from EvalDeclarationData, which was only populated by the C++ parser.
2026-03-19 15:37:46 -03:00
#include <LibJS/ModuleEntry.h>
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
#include <LibJS/ParserError.h>
#include <LibJS/Runtime/AbstractOperations.h>
#include <LibJS/Runtime/FunctionKind.h>
#include <LibJS/Script.h>
LibJS: Add C++ parse_program/compile_parsed_script wrappers Expose the Rust parse/compile split to C++ callers: - parse_program(): takes raw UTF-16 data and a ProgramType parameter (Script or Module). No GC interaction, thread-safe. - compile_parsed_script(): takes a pre-parsed RustParsedProgram and a SourceCode, checks for errors, and calls rust_compile_parsed_script(). Returns a ScriptResult. Rewrite compile_script() to use the split path internally. The pipeline comparison logic now gets the AST dump from the ParsedProgram before compilation consumes it.
2026-02-27 19:44:14 -03:00
#include <LibJS/SourceCode.h>
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
#include <LibJS/SourceTextModule.h>
LibJS: Add C++ parse_program/compile_parsed_script wrappers Expose the Rust parse/compile split to C++ callers: - parse_program(): takes raw UTF-16 data and a ProgramType parameter (Script or Module). No GC interaction, thread-safe. - compile_parsed_script(): takes a pre-parsed RustParsedProgram and a SourceCode, checks for errors, and calls rust_compile_parsed_script(). Returns a ScriptResult. Rewrite compile_script() to use the split path internally. The pipeline comparison logic now gets the AST dump from the ParsedProgram before compilation consumes it.
2026-02-27 19:44:14 -03:00
// Opaque parsed program handle from the Rust pipeline.
LibJS: Generate FFI header using cbindgen instead of hand-rolling Replace the BytecodeFactory header with cbindgen. This will help ensure that types and enums and constants are kept in sync between the C++ and Rust code. It's also a step in exporting more Rust enums directly rather than relying on magic constants for switch statements. The FFI functions are now all placed in the JS::FFI namespace, which is the cause for all the churn in the scripting parts of LibJS and LibWeb.
2026-03-17 18:47:58 -03:00
namespace JS::FFI {
struct ParsedProgram;
LibWeb+LibJS: Compile fetched top-level JS off-thread Split Rust program compilation so code generation and assembly finish before the main thread materializes GC-backed executable objects. The new CompiledProgram handle owns the parsed program, generator state, and bytecode until C++ consumes it on the main thread. Wire WebContent script fetching through that handle for classic scripts and modules. Syntax-error paths still return ParsedProgram, so existing error reporting stays in place. Successful fetches now do top-level codegen on the thread pool before deferred_invoke hands control back to the main thread. Executable creation, SharedFunctionInstanceData materialization, module metadata extraction, and declaration data extraction still run on the main thread where VM and GC access is valid.
2026-04-26 09:53:34 -03:00
struct CompiledProgram;
LibJS: Add off-thread function bytecode artifacts Add Rust and C++ integration points for cloning lazy function compile payloads, compiling them to GC-free bytecode off the main thread, and materializing the result later on the main thread. The cloned payload lets background compilation race with lazy main-thread compilation without sharing AST ownership between threads. Compiled function artifacts recursively include nested functions, so materialization can discard the corresponding AST subtree.
2026-05-05 09:24:11 -03:00
struct CompiledFunction;
LibJS: Decode bytecode cache blobs over FFI Expose an owned decoded bytecode cache handle through RustIntegration. This lets C++ callers keep validated metadata and executable records in Rust-owned cache structures without invoking the parser. Extend the js bytecode cache validation mode to create and free the FFI handle so blob generation exercises the ownership path.
2026-05-03 14:48:26 -03:00
struct DecodedBytecodeCacheBlob;
LibJS: Generate FFI header using cbindgen instead of hand-rolling Replace the BytecodeFactory header with cbindgen. This will help ensure that types and enums and constants are kept in sync between the C++ and Rust code. It's also a step in exporting more Rust enums directly rather than relying on magic constants for switch statements. The FFI functions are now all placed in the JS::FFI namespace, which is the cause for all the churn in the scripting parts of LibJS and LibWeb.
2026-03-17 18:47:58 -03:00
}
LibJS: Add C++ parse_program/compile_parsed_script wrappers Expose the Rust parse/compile split to C++ callers: - parse_program(): takes raw UTF-16 data and a ProgramType parameter (Script or Module). No GC interaction, thread-safe. - compile_parsed_script(): takes a pre-parsed RustParsedProgram and a SourceCode, checks for errors, and calls rust_compile_parsed_script(). Returns a ScriptResult. Rewrite compile_script() to use the split path internally. The pipeline comparison logic now gets the AST dump from the ParsedProgram before compilation consumes it.
2026-02-27 19:44:14 -03:00
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
namespace JS::RustIntegration {
LibJS: Add C++ parse_program/compile_parsed_script wrappers Expose the Rust parse/compile split to C++ callers: - parse_program(): takes raw UTF-16 data and a ProgramType parameter (Script or Module). No GC interaction, thread-safe. - compile_parsed_script(): takes a pre-parsed RustParsedProgram and a SourceCode, checks for errors, and calls rust_compile_parsed_script(). Returns a ScriptResult. Rewrite compile_script() to use the split path internally. The pipeline comparison logic now gets the AST dump from the ParsedProgram before compilation consumes it.
2026-02-27 19:44:14 -03:00
enum class ProgramType : u8 {
Script = 0,
Module = 1,
};
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
// Result type for compile_script().
// NB: Uses GC::Root to prevent collection while the result is in transit
// between compile_script() and the Script constructor.
struct ScriptResult {
GC::Root<Bytecode::Executable> executable;
LibJS: Track shared function data ownership Give scripts and modules an explicit list of their shared function data records, and teach Rust materialization to populate that list directly. This gives bytecode cache installation a stable set of functions to update when replacing executable backing storage.
2026-05-21 16:49:43 -03:00
Vector<GC::Root<SharedFunctionInstanceData>> shared_function_data;
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
bool is_strict_mode { false };
Vector<Utf16FlyString> lexical_names;
Vector<Utf16FlyString> var_names;
struct FunctionToInitialize {
GC::Root<SharedFunctionInstanceData> shared_data;
Utf16FlyString name;
};
Vector<FunctionToInitialize> functions_to_initialize;
HashTable<Utf16FlyString> declared_function_names;
Vector<Utf16FlyString> var_scoped_names;
Vector<Utf16FlyString> annex_b_candidate_names;
Vector<Script::LexicalBinding> lexical_bindings;
};
Everywhere: Remove ShadowRealm support The proposal has not seemed to progress for a while, and there is a open issue about module imports which breaks HTML integration. While we could probably make an AD-HOC change to fix that issue, it is deep enough in the JS engine that I am not particularly keen on making that change. Until other browsers begin to make positive signals about shipping ShadowRealms, let's remove our implementation for now. There is still some cleanup that can be done with regard to the HTML integration, but there are a few more items that need to be untangled there.
2026-04-03 09:34:03 -03:00
// Result type for compile_eval().
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
// NB: Uses GC::Root to prevent collection while the result is in transit.
struct EvalResult {
GC::Root<Bytecode::Executable> executable;
bool is_strict_mode { false };
EvalDeclarationData declaration_data;
};
// Result type for compile_module().
// NB: Uses GC::Root to prevent collection while the result is in transit.
struct ModuleResult {
bool has_top_level_await { false };
Vector<ModuleRequest> requested_modules;
Vector<ImportEntry> import_entries;
Vector<ExportEntry> local_export_entries;
Vector<ExportEntry> indirect_export_entries;
Vector<ExportEntry> star_export_entries;
Optional<Utf16FlyString> default_export_binding_name;
Vector<Utf16FlyString> var_declared_names;
Vector<SourceTextModule::LexicalBinding> lexical_bindings;
struct FunctionToInitialize {
GC::Root<SharedFunctionInstanceData> shared_data;
Utf16FlyString name;
};
Vector<FunctionToInitialize> functions_to_initialize;
GC::Root<Bytecode::Executable> executable;
LibJS: Track shared function data ownership Give scripts and modules an explicit list of their shared function data records, and teach Rust materialization to populate that list directly. This gives bytecode cache installation a stable set of functions to update when replacing executable backing storage.
2026-05-21 16:49:43 -03:00
Vector<GC::Root<SharedFunctionInstanceData>> shared_function_data;
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
GC::Root<SharedFunctionInstanceData> tla_shared_data;
};
LibJS+LibWeb: Parse classic scripts off the main thread Create a SourceCode on the main thread (performing UTF-8 to UTF-16 conversion), then submit parse_program() to the ThreadPool for Rust parsing on a worker thread. This unblocks the WebContent event loop during external script loading. Add Script::create_from_parsed() and ClassicScript::create_from_pre_parsed() factory methods that take a pre-parsed RustParsedProgram and a SourceCode, performing only the GC-allocating compile step on the main thread. Falls back to synchronous parsing when the Rust pipeline is unavailable (LIBJS_CPP=1 or LIBJS_COMPARE_PIPELINES=1).
2026-02-27 19:44:29 -03:00
// Check if the Rust pipeline is available for off-thread parsing.
JS_API bool rust_pipeline_available();
LibJS: Add C++ parse_program/compile_parsed_script wrappers Expose the Rust parse/compile split to C++ callers: - parse_program(): takes raw UTF-16 data and a ProgramType parameter (Script or Module). No GC interaction, thread-safe. - compile_parsed_script(): takes a pre-parsed RustParsedProgram and a SourceCode, checks for errors, and calls rust_compile_parsed_script(). Returns a ScriptResult. Rewrite compile_script() to use the split path internally. The pipeline comparison logic now gets the AST dump from the ParsedProgram before compilation consumes it.
2026-02-27 19:44:14 -03:00
// Parse a program (script or module) without GC interaction. Thread-safe.
LibJS: Generate FFI header using cbindgen instead of hand-rolling Replace the BytecodeFactory header with cbindgen. This will help ensure that types and enums and constants are kept in sync between the C++ and Rust code. It's also a step in exporting more Rust enums directly rather than relying on magic constants for switch statements. The FFI functions are now all placed in the JS::FFI namespace, which is the cause for all the churn in the scripting parts of LibJS and LibWeb.
2026-03-17 18:47:58 -03:00
JS_API FFI::ParsedProgram* parse_program(u16 const* utf16_data, size_t length_in_code_units, ProgramType type, size_t line_number_offset = 0);
LibJS: Add C++ parse_program/compile_parsed_script wrappers Expose the Rust parse/compile split to C++ callers: - parse_program(): takes raw UTF-16 data and a ProgramType parameter (Script or Module). No GC interaction, thread-safe. - compile_parsed_script(): takes a pre-parsed RustParsedProgram and a SourceCode, checks for errors, and calls rust_compile_parsed_script(). Returns a ScriptResult. Rewrite compile_script() to use the split path internally. The pipeline comparison logic now gets the AST dump from the ParsedProgram before compilation consumes it.
2026-02-27 19:44:14 -03:00
LibWeb+LibJS: Compile fetched top-level JS off-thread Split Rust program compilation so code generation and assembly finish before the main thread materializes GC-backed executable objects. The new CompiledProgram handle owns the parsed program, generator state, and bytecode until C++ consumes it on the main thread. Wire WebContent script fetching through that handle for classic scripts and modules. Syntax-error paths still return ParsedProgram, so existing error reporting stays in place. Successful fetches now do top-level codegen on the thread pool before deferred_invoke hands control back to the main thread. Executable creation, SharedFunctionInstanceData materialization, module metadata extraction, and declaration data extraction still run on the main thread where VM and GC access is valid.
2026-04-26 09:53:34 -03:00
// Compile a parsed program to bytecode without touching the VM or GC. Thread-safe.
JS_API FFI::CompiledProgram* compile_parsed_program_off_thread(FFI::ParsedProgram* parsed, size_t length_in_code_units);
LibJS: Split full off-thread script compilation Keep fetched script and module compilation on the latency-sensitive path limited to top-level code and eager direct IIFE compilation before returning bytecode to the main thread. Add a separate full off-thread compile entry point for bytecode cache generation. Cache jobs can use it to compile every nested function after the execution path has already been unblocked.
2026-05-03 13:43:14 -03:00
// Fully compile a parsed program to bytecode without touching the VM or GC. Thread-safe.
JS_API FFI::CompiledProgram* compile_parsed_program_fully_off_thread(FFI::ParsedProgram* parsed, size_t length_in_code_units);
LibJS: Remove C++ parser Delete Parser.cpp/h and ScopeCollector.cpp/h, now that all parsing goes through the Rust pipeline. Port test262-runner to use RustIntegration::parse_program() for its fast parse-only check instead of the C++ Parser. Add parsed_program_has_errors() and free_parsed_program() to the RustIntegration public API for parse-only use cases.
2026-03-19 15:20:30 -03:00
// Check if a parsed program has errors. Does not consume the program.
JS_API bool parsed_program_has_errors(FFI::ParsedProgram const*);
// Free a parsed program without compiling it.
JS_API void free_parsed_program(FFI::ParsedProgram*);
LibWeb+LibJS: Compile fetched top-level JS off-thread Split Rust program compilation so code generation and assembly finish before the main thread materializes GC-backed executable objects. The new CompiledProgram handle owns the parsed program, generator state, and bytecode until C++ consumes it on the main thread. Wire WebContent script fetching through that handle for classic scripts and modules. Syntax-error paths still return ParsedProgram, so existing error reporting stays in place. Successful fetches now do top-level codegen on the thread pool before deferred_invoke hands control back to the main thread. Executable creation, SharedFunctionInstanceData materialization, module metadata extraction, and declaration data extraction still run on the main thread where VM and GC access is valid.
2026-04-26 09:53:34 -03:00
// Free a compiled program without materializing it.
JS_API void free_compiled_program(FFI::CompiledProgram*);
LibJS: Serialize compiled bytecode cache blobs Add a versioned Rust bytecode cache writer for fully compiled programs. The blob records executable bytecode, metadata tables, source maps, exception handlers, nested function bytecode, and class blueprints without materializing GC objects. Expose the serialized blob through RustIntegration as an owned ByteBuffer so Web-facing callers can store it as HTTP cache data.
2026-05-03 13:53:38 -03:00
// Serialize a fully compiled program into a versioned bytecode cache blob.
LibJS: Match bytecode cache blobs to their source Store a SHA-256 fingerprint of the decoded source text in each bytecode cache blob, and require callers to provide the expected fingerprint when validating or decoding a blob. This rejects sidecars for stale HTTP cache entries whose URL and request headers still match but whose source body has been replaced. Bytecode cache tests cover the mismatched-source rejection path.
2026-05-03 17:49:29 -03:00
JS_API ByteBuffer serialize_compiled_program_for_bytecode_cache(FFI::CompiledProgram const&, ProgramType, ReadonlyBytes source_hash);
LibJS: Serialize compiled bytecode cache blobs Add a versioned Rust bytecode cache writer for fully compiled programs. The blob records executable bytecode, metadata tables, source maps, exception handlers, nested function bytecode, and class blueprints without materializing GC objects. Expose the serialized blob through RustIntegration as an owned ByteBuffer so Web-facing callers can store it as HTTP cache data.
2026-05-03 13:53:38 -03:00
LibJS: Track shared function data ownership Give scripts and modules an explicit list of their shared function data records, and teach Rust materialization to populate that list directly. This gives bytecode cache installation a stable set of functions to update when replacing executable backing storage.
2026-05-21 16:49:43 -03:00
// Decode an ImmutableBytes-backed bytecode cache blob into a parser-free cache handle.
LibJS: Borrow mapped bytecode cache executable bytes Keep executable bytecode payloads decoded from owner-backed bytecode cache blobs as ranges into the original blob instead of copying them into Rust Vec allocations. The mapped blob owner is held by decoded executable records, including lazy nested function executables, so the borrowed bytecode remains alive until materialization copies it into the final C++ Executable. Use the owner-backed decoder for HTTP bytecode cache hits and keep the plain byte decoder for tests and in-memory callers. Add coverage for materializing bytecode cache data from an ImmutableBytes mapped file.
2026-05-15 11:45:31 -03:00
JS_API FFI::DecodedBytecodeCacheBlob* decode_bytecode_cache_blob(Core::ImmutableBytes, ProgramType, ReadonlyBytes source_hash);
LibJS: Decode bytecode cache blobs over FFI Expose an owned decoded bytecode cache handle through RustIntegration. This lets C++ callers keep validated metadata and executable records in Rust-owned cache structures without invoking the parser. Extend the js bytecode cache validation mode to create and free the FFI handle so blob generation exercises the ownership path.
2026-05-03 14:48:26 -03:00
// Free a decoded bytecode cache blob.
JS_API void free_decoded_bytecode_cache_blob(FFI::DecodedBytecodeCacheBlob*);
LibJS: Materialize decoded bytecode cache blobs Create parser-free script and module materializers for decoded cache blobs. Cached functions create SFDs without Rust compile inputs and attach their precompiled executable immediately, while declaration metadata is populated from decoded records. Treat cache blobs as external input from the HTTP disk cache. Run bytecode validation unconditionally before fixing up cache pointers, and reject decoded source ranges or metadata indices that would be out-of-bounds during C++ materialization. Report executable validation failures as parser errors so callers can reject corrupt sidecars and fall back to source compilation. LibJS tests cover corrupt top-level bytecode, declaration bytecode, and declaration source spans.
2026-05-03 14:53:55 -03:00
// Materialize a decoded script bytecode cache blob. Must be called on the main thread.
// Consumes and frees the decoded blob.
JS_API Optional<Result<ScriptResult, Vector<ParserError>>> materialize_bytecode_cache_script(FFI::DecodedBytecodeCacheBlob*, NonnullRefPtr<SourceCode const> source_code, Realm&);
// Materialize a decoded module bytecode cache blob. Must be called on the main thread.
// Consumes and frees the decoded blob.
JS_API Optional<Result<ModuleResult, Vector<ParserError>>> materialize_bytecode_cache_module(FFI::DecodedBytecodeCacheBlob*, NonnullRefPtr<SourceCode const> source_code, Realm&);
LibJS: Track shared function data ownership Give scripts and modules an explicit list of their shared function data records, and teach Rust materialization to populate that list directly. This gives bytecode cache installation a stable set of functions to update when replacing executable backing storage.
2026-05-21 16:49:43 -03:00
struct ModuleBytecodeCacheInstallResult {
GC::Root<Bytecode::Executable> executable;
GC::Root<Bytecode::Executable> top_level_await_executable;
};
// Try to install a decoded script bytecode cache blob into an existing script executable tree.
// Must be called on the main thread. Consumes and frees the decoded blob.
JS_API GC::Ptr<Bytecode::Executable> try_install_bytecode_cache_script(FFI::DecodedBytecodeCacheBlob*, NonnullRefPtr<SourceCode const> source_code, Realm&, Bytecode::Executable& existing_executable, ReadonlySpan<SharedFunctionInstanceData*> existing_shared_function_data);
// Install a decoded script bytecode cache blob produced by the current process.
// Must be called on the main thread. Consumes and frees the decoded blob.
JS_API GC::Ref<Bytecode::Executable> install_generated_bytecode_cache_script(FFI::DecodedBytecodeCacheBlob*, NonnullRefPtr<SourceCode const> source_code, Realm&, Bytecode::Executable& existing_executable, ReadonlySpan<SharedFunctionInstanceData*> existing_shared_function_data);
// Try to install a decoded module bytecode cache blob into an existing module executable tree.
// Must be called on the main thread. Consumes and frees the decoded blob.
JS_API Optional<ModuleBytecodeCacheInstallResult> try_install_bytecode_cache_module(FFI::DecodedBytecodeCacheBlob*, NonnullRefPtr<SourceCode const> source_code, Realm&, Bytecode::Executable* existing_executable, ReadonlySpan<SharedFunctionInstanceData*> existing_shared_function_data, SharedFunctionInstanceData* existing_top_level_await_shared_data);
// Install a decoded module bytecode cache blob produced by the current process.
// Must be called on the main thread. Consumes and frees the decoded blob.
JS_API ModuleBytecodeCacheInstallResult install_generated_bytecode_cache_module(FFI::DecodedBytecodeCacheBlob*, NonnullRefPtr<SourceCode const> source_code, Realm&, Bytecode::Executable* existing_executable, ReadonlySpan<SharedFunctionInstanceData*> existing_shared_function_data, SharedFunctionInstanceData* existing_top_level_await_shared_data);
LibJS: Add C++ parse_program/compile_parsed_script wrappers Expose the Rust parse/compile split to C++ callers: - parse_program(): takes raw UTF-16 data and a ProgramType parameter (Script or Module). No GC interaction, thread-safe. - compile_parsed_script(): takes a pre-parsed RustParsedProgram and a SourceCode, checks for errors, and calls rust_compile_parsed_script(). Returns a ScriptResult. Rewrite compile_script() to use the split path internally. The pipeline comparison logic now gets the AST dump from the ParsedProgram before compilation consumes it.
2026-02-27 19:44:14 -03:00
// Compile a previously parsed script. Must be called on the main thread.
LibJS: Generate FFI header using cbindgen instead of hand-rolling Replace the BytecodeFactory header with cbindgen. This will help ensure that types and enums and constants are kept in sync between the C++ and Rust code. It's also a step in exporting more Rust enums directly rather than relying on magic constants for switch statements. The FFI functions are now all placed in the JS::FFI namespace, which is the cause for all the churn in the scripting parts of LibJS and LibWeb.
2026-03-17 18:47:58 -03:00
// Consumes and frees the Rust ParsedProgram.
LibJS: Add C++ parse_program/compile_parsed_script wrappers Expose the Rust parse/compile split to C++ callers: - parse_program(): takes raw UTF-16 data and a ProgramType parameter (Script or Module). No GC interaction, thread-safe. - compile_parsed_script(): takes a pre-parsed RustParsedProgram and a SourceCode, checks for errors, and calls rust_compile_parsed_script(). Returns a ScriptResult. Rewrite compile_script() to use the split path internally. The pipeline comparison logic now gets the AST dump from the ParsedProgram before compilation consumes it.
2026-02-27 19:44:14 -03:00
// Returns nullopt if Rust is not available.
LibJS: Generate FFI header using cbindgen instead of hand-rolling Replace the BytecodeFactory header with cbindgen. This will help ensure that types and enums and constants are kept in sync between the C++ and Rust code. It's also a step in exporting more Rust enums directly rather than relying on magic constants for switch statements. The FFI functions are now all placed in the JS::FFI namespace, which is the cause for all the churn in the scripting parts of LibJS and LibWeb.
2026-03-17 18:47:58 -03:00
Optional<Result<ScriptResult, Vector<ParserError>>> compile_parsed_script(FFI::ParsedProgram* parsed, NonnullRefPtr<SourceCode const> source_code, Realm& realm);
LibJS: Add C++ parse_program/compile_parsed_script wrappers Expose the Rust parse/compile split to C++ callers: - parse_program(): takes raw UTF-16 data and a ProgramType parameter (Script or Module). No GC interaction, thread-safe. - compile_parsed_script(): takes a pre-parsed RustParsedProgram and a SourceCode, checks for errors, and calls rust_compile_parsed_script(). Returns a ScriptResult. Rewrite compile_script() to use the split path internally. The pipeline comparison logic now gets the AST dump from the ParsedProgram before compilation consumes it.
2026-02-27 19:44:14 -03:00
LibWeb+LibJS: Compile fetched top-level JS off-thread Split Rust program compilation so code generation and assembly finish before the main thread materializes GC-backed executable objects. The new CompiledProgram handle owns the parsed program, generator state, and bytecode until C++ consumes it on the main thread. Wire WebContent script fetching through that handle for classic scripts and modules. Syntax-error paths still return ParsedProgram, so existing error reporting stays in place. Successful fetches now do top-level codegen on the thread pool before deferred_invoke hands control back to the main thread. Executable creation, SharedFunctionInstanceData materialization, module metadata extraction, and declaration data extraction still run on the main thread where VM and GC access is valid.
2026-04-26 09:53:34 -03:00
// Materialize a previously compiled script. Must be called on the main thread.
// Consumes and frees the Rust CompiledProgram.
Optional<Result<ScriptResult, Vector<ParserError>>> materialize_compiled_script(FFI::CompiledProgram* compiled, NonnullRefPtr<SourceCode const> source_code, Realm& realm);
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
// Compile a script. Returns nullopt if Rust is not available.
LibJS: Add C++ parse_program/compile_parsed_script wrappers Expose the Rust parse/compile split to C++ callers: - parse_program(): takes raw UTF-16 data and a ProgramType parameter (Script or Module). No GC interaction, thread-safe. - compile_parsed_script(): takes a pre-parsed RustParsedProgram and a SourceCode, checks for errors, and calls rust_compile_parsed_script(). Returns a ScriptResult. Rewrite compile_script() to use the split path internally. The pipeline comparison logic now gets the AST dump from the ParsedProgram before compilation consumes it.
2026-02-27 19:44:14 -03:00
Optional<Result<ScriptResult, Vector<ParserError>>> compile_script(StringView source_text, Realm& realm, StringView filename, size_t line_number_offset);
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
// Compile eval code. Returns nullopt if Rust is not available.
// On success, the executable's name is set to "eval".
Optional<Result<EvalResult, String>> compile_eval(
PrimitiveString& code_string, VM& vm,
CallerMode strict_caller, bool in_function, bool in_method,
bool in_derived_constructor, bool in_class_field_initializer);
LibJS+LibWeb: Add C++ compile_parsed_module wrapper Add compile_parsed_module() to RustIntegration, which takes a RustParsedProgram and a SourceCode (from parse_program with ProgramType::Module) and compiles it on the main thread with GC interaction. Rewrite compile_module() to use the new split functions internally. Add SourceTextModule::parse_from_pre_parsed() and JavaScriptModuleScript::create_from_pre_parsed() to allow creating module scripts from a pre-parsed RustParsedProgram. This prepares the infrastructure for off-thread module parsing.
2026-02-27 19:44:44 -03:00
// Compile a previously parsed module. Must be called on the main thread.
LibJS: Generate FFI header using cbindgen instead of hand-rolling Replace the BytecodeFactory header with cbindgen. This will help ensure that types and enums and constants are kept in sync between the C++ and Rust code. It's also a step in exporting more Rust enums directly rather than relying on magic constants for switch statements. The FFI functions are now all placed in the JS::FFI namespace, which is the cause for all the churn in the scripting parts of LibJS and LibWeb.
2026-03-17 18:47:58 -03:00
// Consumes and frees the Rust ParsedProgram.
LibJS+LibWeb: Add C++ compile_parsed_module wrapper Add compile_parsed_module() to RustIntegration, which takes a RustParsedProgram and a SourceCode (from parse_program with ProgramType::Module) and compiles it on the main thread with GC interaction. Rewrite compile_module() to use the new split functions internally. Add SourceTextModule::parse_from_pre_parsed() and JavaScriptModuleScript::create_from_pre_parsed() to allow creating module scripts from a pre-parsed RustParsedProgram. This prepares the infrastructure for off-thread module parsing.
2026-02-27 19:44:44 -03:00
// Returns nullopt if Rust is not available.
LibJS: Generate FFI header using cbindgen instead of hand-rolling Replace the BytecodeFactory header with cbindgen. This will help ensure that types and enums and constants are kept in sync between the C++ and Rust code. It's also a step in exporting more Rust enums directly rather than relying on magic constants for switch statements. The FFI functions are now all placed in the JS::FFI namespace, which is the cause for all the churn in the scripting parts of LibJS and LibWeb.
2026-03-17 18:47:58 -03:00
Optional<Result<ModuleResult, Vector<ParserError>>> compile_parsed_module(FFI::ParsedProgram* parsed, NonnullRefPtr<SourceCode const> source_code, Realm& realm);
LibJS+LibWeb: Add C++ compile_parsed_module wrapper Add compile_parsed_module() to RustIntegration, which takes a RustParsedProgram and a SourceCode (from parse_program with ProgramType::Module) and compiles it on the main thread with GC interaction. Rewrite compile_module() to use the new split functions internally. Add SourceTextModule::parse_from_pre_parsed() and JavaScriptModuleScript::create_from_pre_parsed() to allow creating module scripts from a pre-parsed RustParsedProgram. This prepares the infrastructure for off-thread module parsing.
2026-02-27 19:44:44 -03:00
LibWeb+LibJS: Compile fetched top-level JS off-thread Split Rust program compilation so code generation and assembly finish before the main thread materializes GC-backed executable objects. The new CompiledProgram handle owns the parsed program, generator state, and bytecode until C++ consumes it on the main thread. Wire WebContent script fetching through that handle for classic scripts and modules. Syntax-error paths still return ParsedProgram, so existing error reporting stays in place. Successful fetches now do top-level codegen on the thread pool before deferred_invoke hands control back to the main thread. Executable creation, SharedFunctionInstanceData materialization, module metadata extraction, and declaration data extraction still run on the main thread where VM and GC access is valid.
2026-04-26 09:53:34 -03:00
// Materialize a previously compiled module. Must be called on the main thread.
// Consumes and frees the Rust CompiledProgram.
Optional<Result<ModuleResult, Vector<ParserError>>> materialize_compiled_module(FFI::CompiledProgram* compiled, NonnullRefPtr<SourceCode const> source_code, Realm& realm);
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
// Compile a module. Returns nullopt if Rust is not available.
LibJS+LibWeb: Add C++ compile_parsed_module wrapper Add compile_parsed_module() to RustIntegration, which takes a RustParsedProgram and a SourceCode (from parse_program with ProgramType::Module) and compiles it on the main thread with GC interaction. Rewrite compile_module() to use the new split functions internally. Add SourceTextModule::parse_from_pre_parsed() and JavaScriptModuleScript::create_from_pre_parsed() to allow creating module scripts from a pre-parsed RustParsedProgram. This prepares the infrastructure for off-thread module parsing.
2026-02-27 19:44:44 -03:00
Optional<Result<ModuleResult, Vector<ParserError>>> compile_module(StringView source_text, Realm& realm, StringView filename);
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
LibJS+LibWeb: Port remaining callers to Rust pipeline Port all remaining users of the C++ Parser/Lexer/Generator to use the Rust pipeline instead: - Intrinsics: Remove C++ fallback in parse_builtin_file() - ECMAScriptFunctionObject: Remove C++ compile() fallback - NativeJavaScriptBackedFunction: Remove C++ compile() fallback - EventTarget: Port to compile_dynamic_function - WebDriver/ExecuteScript: Port to compile_dynamic_function - LibTest/JavaScriptTestRunner.h: Remove Parser/Lexer includes - FuzzilliJs: Remove unused Parser/Lexer includes Also remove the dead Statement-based template instantiation of async_block_start/async_function_start.
2026-03-19 14:41:49 -03:00
// Compile a dynamic function (new Function()).
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
// On success, returns a SharedFunctionInstanceData with source_text set.
LibJS+LibWeb: Port remaining callers to Rust pipeline Port all remaining users of the C++ Parser/Lexer/Generator to use the Rust pipeline instead: - Intrinsics: Remove C++ fallback in parse_builtin_file() - ECMAScriptFunctionObject: Remove C++ compile() fallback - NativeJavaScriptBackedFunction: Remove C++ compile() fallback - EventTarget: Port to compile_dynamic_function - WebDriver/ExecuteScript: Port to compile_dynamic_function - LibTest/JavaScriptTestRunner.h: Remove Parser/Lexer includes - FuzzilliJs: Remove unused Parser/Lexer includes Also remove the dead Statement-based template instantiation of async_block_start/async_function_start.
2026-03-19 14:41:49 -03:00
JS_API Optional<Result<GC::Ref<SharedFunctionInstanceData>, String>> compile_dynamic_function(
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
VM& vm, StringView source_text, StringView parameters_string, StringView body_parse_string,
FunctionKind kind);
// Compile a builtin JS file. Returns nullopt if Rust is not available.
Optional<Vector<GC::Root<SharedFunctionInstanceData>>> compile_builtin_file(
unsigned char const* script_text, VM& vm);
// Compile a function body for lazy compilation.
// Returns nullptr if Rust is not available or the SFD doesn't use Rust compilation.
GC::Ptr<Bytecode::Executable> compile_function(VM& vm, SharedFunctionInstanceData& shared_data, bool builtin_abstract_operations_enabled);
LibJS: Add off-thread function bytecode artifacts Add Rust and C++ integration points for cloning lazy function compile payloads, compiling them to GC-free bytecode off the main thread, and materializing the result later on the main thread. The cloned payload lets background compilation race with lazy main-thread compilation without sharing AST ownership between threads. Compiled function artifacts recursively include nested functions, so materialization can discard the corresponding AST subtree.
2026-05-05 09:24:11 -03:00
JS_API void* clone_function_ast(void const*);
JS_API FFI::CompiledFunction* compile_function_off_thread(void* function_ast, size_t length_in_code_units, bool builtin_abstract_operations_enabled);
LibJS: Materialize compiled function bytecode lazily Keep fully compiled function bytecode in its Rust-side form until the function is called for the first time. This covers decoded disk cache records and freshly precompiled bytecode, so startup avoids eagerly allocating every nested function executable. Validate cached function bytecode before accepting a cache entry. This keeps the existing failure behavior for corrupt on-disk cache data. Add coverage for bytecode-cache and freshly precompiled functions to assert that nested executables stay absent after script materialization, then appear after the function is called.
2026-05-13 18:35:55 -03:00
// Attach a previously compiled function for lazy materialization.
LibJS: Add off-thread function bytecode artifacts Add Rust and C++ integration points for cloning lazy function compile payloads, compiling them to GC-free bytecode off the main thread, and materializing the result later on the main thread. The cloned payload lets background compilation race with lazy main-thread compilation without sharing AST ownership between threads. Compiled function artifacts recursively include nested functions, so materialization can discard the corresponding AST subtree.
2026-05-05 09:24:11 -03:00
JS_API void materialize_compiled_function(FFI::CompiledFunction*, VM&, SourceCode const&, SharedFunctionInstanceData&);
JS_API void free_compiled_function(FFI::CompiledFunction*);
LibJS: Materialize compiled function bytecode lazily Keep fully compiled function bytecode in its Rust-side form until the function is called for the first time. This covers decoded disk cache records and freshly precompiled bytecode, so startup avoids eagerly allocating every nested function executable. Validate cached function bytecode before accepting a cache entry. This keeps the existing failure behavior for corrupt on-disk cache data. Add coverage for bytecode-cache and freshly precompiled functions to assert that nested executables stay absent after script materialization, then appear after the function is called.
2026-05-13 18:35:55 -03:00
// Free a Rust decoded bytecode cache executable pointer. No-op if null.
void free_cached_bytecode_executable(void*);
// Free a Rust precompiled bytecode executable pointer. No-op if null.
void free_precompiled_bytecode_executable(void*);
LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
// Free a Rust function AST pointer. No-op if Rust is not available.
void free_function_ast(void* ast);
}
Reference in a new issue Copy permalink