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

1932 lines
77 KiB
C++
Raw Permalink 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
*/
#include <LibJS/RustIntegration.h>
LibJS: Move bytecode instruction dumping to Rust Generate Rust bytecode dump helpers from Bytecode.def and route Executable::dump() through them for instruction stream formatting. Add a small Rust runtime::value helper for decoding encoded LibJS Values so immediate Value operands are formatted on the Rust side. C++ callbacks remain only for local names and GC-backed Value payloads that still need LibJS object access. Remove the generated C++ to_byte_string_impl() methods and the old Instruction::to_byte_string() dispatch. The bytecode dump tests cover output compatibility.
2026-06-14 13:12:06 -03:00
#include <AK/BitCast.h>
LibJS: Stop persisting basic_block_start_offsets on Executable Keep basic block offsets as construction-only metadata rather than storing them on every Executable. The validator now receives the offsets through a transient Rust FFI span, and the bytecode dump rebuilds block starts by scanning labels, terminators, and exception handler metadata. Drop the table from the bytecode cache format and bump the format version so old caches are rebuilt. This removes a field that was only used by validation and bytecode dump paths.
2026-05-13 15:36:54 -03:00
#include <AK/NumericLimits.h>
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
#include <AK/TemporaryChange.h>
LibJS: Remove LIBJS_CPP env var and ENABLE_RUST guards The Rust pipeline is now the only compilation path, so remove: - The LIBJS_CPP environment variable check - The rust_pipeline_enabled() helper - The #ifdef ENABLE_RUST / #else stub section - The test-js-cpp CTest target and LIBJS_TEST_PARSER_MODE env var - The ParserMode enum and canParseSourceWithCpp/Rust test functions rust_pipeline_available() now unconditionally returns true.
2026-03-19 14:29:15 -03:00
#include <AK/Utf16String.h>
#include <AK/Utf16View.h>
AK: Adopt mimalloc v2 as main allocator Use mimalloc for Ladybird-owned allocations without overriding malloc(). Route kmalloc(), kcalloc(), krealloc(), and kfree() through mimalloc, and put the embedded Rust crates on the same allocator via a shared shim in AK/kmalloc.cpp. This also lets us drop kfree_sized(), since it no longer used its size argument. StringData, Utf16StringData, JS object storage, Rust error strings, and the CoreAudio playback helpers can all free their AK-backed storage with plain kfree(). Sanitizer builds still use the system allocator. LeakSanitizer does not reliably trace references stored in mimalloc-managed AK containers, so static caches and other long-lived roots can look leaked. Pass the old size into the Rust realloc shim so aligned fallback reallocations can move posix_memalign-backed blocks safely. Static builds still need a little linker help. macOS app binaries need the Rust allocator entry points forced in from liblagom-ak.a, while static ELF links can pull in identical allocator shim definitions from multiple Rust staticlibs. Keep the Apple -u flags and allow those duplicate shim symbols for LibJS and LibRegex links on Linux and BSD.
2026-04-03 12:06:58 -03:00
#include <AK/kmalloc.h>
LibJS: Prepare bytecode cache validation off-thread Add an explicit validation entry point for decoded bytecode cache blobs. This lets callers validate a blob before materialization while keeping the existing validated-before-use invariant in place. Make validation idempotent so a prevalidated blob is not walked again when materialization reaches the same check. Keep the existing decoded source length query for callers that still validate synchronously. Route decoded cache blob owner destruction through the origin event loop. This lets a worker decode or reject mapped bytecode without releasing non-atomically refcounted ImmutableBytes off-thread, while lazy cached function materialization can still retain mmap-backed bytecode.
2026-06-03 19:38:49 -03:00
#include <LibCore/EventLoop.h>
LibJS: Remove LIBJS_CPP env var and ENABLE_RUST guards The Rust pipeline is now the only compilation path, so remove: - The LIBJS_CPP environment variable check - The rust_pipeline_enabled() helper - The #ifdef ENABLE_RUST / #else stub section - The test-js-cpp CTest target and LIBJS_TEST_PARSER_MODE env var - The ParserMode enum and canParseSourceWithCpp/Rust test functions rust_pipeline_available() now unconditionally returns true.
2026-03-19 14:29:15 -03:00
#include <LibGC/DeferGC.h>
#include <LibJS/Bytecode/ClassBlueprint.h>
LibJS: Precompile top-level IIFEs off-thread Mark direct calls to function expressions while generating top-level Rust bytecode, then compile those functions before returning the off-thread compilation result to WebContent. The main thread still performs all VM and GC-backed materialization. It now receives an already assembled executable for each eager IIFE and attaches it to the SharedFunctionInstanceData while creating the parent Executable. Nested functions owned by the eager executable remain lazy. This targets large wrapper IIFEs that are invoked as soon as top-level code starts running. Their bytecode generation now runs on the existing script compilation worker instead of blocking the main thread on first call.
2026-04-26 12:24:25 -03:00
#include <LibJS/Bytecode/Debug.h>
LibJS: Remove LIBJS_CPP env var and ENABLE_RUST guards The Rust pipeline is now the only compilation path, so remove: - The LIBJS_CPP environment variable check - The rust_pipeline_enabled() helper - The #ifdef ENABLE_RUST / #else stub section - The test-js-cpp CTest target and LIBJS_TEST_PARSER_MODE env var - The ParserMode enum and canParseSourceWithCpp/Rust test functions rust_pipeline_available() now unconditionally returns true.
2026-03-19 14:29:15 -03:00
#include <LibJS/Bytecode/Executable.h>
#include <LibJS/Bytecode/IdentifierTable.h>
#include <LibJS/Bytecode/PropertyKeyTable.h>
#include <LibJS/Bytecode/RegexTable.h>
#include <LibJS/Bytecode/StringTable.h>
LibJS: Add bytecode validator scaffolding driven from Bytecode.def The plan is to start caching compiled JS bytecode on disk. Before loading anything from a cache we need confidence that the bytes are structurally well-formed, since a corrupted or tampered-with cache file could otherwise hand the interpreter an out-of-bounds jump or a constant-pool index that points past the end of the table. This commit lays down the scaffolding for that validator. The walker lives in Rust (Libraries/LibJS/Rust/src/bytecode/validator.rs) so that it can share the existing Bytecode.def-driven layout machinery with the encoder. C++ calls into it through cbindgen, the same way the rest of the Rust pipeline is wired up. For now, the validator only does Pass 1: walk the byte stream, verify each instruction is 8-byte aligned, the opcode byte is in range, and the reported length keeps us inside the buffer. The length lookup is generated from Bytecode.def so fixed-length and variable-length instructions stay in sync with the rest of the codegen automatically. Per-field bounds checks (operands, labels, table indices, cache indices) and structural extras (basic block offsets, exception handlers, source map) come in follow-up commits. The validator runs after every successful compilation in debug and sanitizer builds, gated on !NDEBUG || HAS_ADDRESS_SANITIZER, so we get an extra sanity check on every executable the encoder produces without paying for it in release builds. Failure trips a VERIFY_NOT_REACHED with the offset, opcode, and error category logged via dbgln().
2026-05-02 04:49:32 -03:00
#include <LibJS/Bytecode/Validator.h>
LibJS: Remove LIBJS_CPP env var and ENABLE_RUST guards The Rust pipeline is now the only compilation path, so remove: - The LIBJS_CPP environment variable check - The rust_pipeline_enabled() helper - The #ifdef ENABLE_RUST / #else stub section - The test-js-cpp CTest target and LIBJS_TEST_PARSER_MODE env var - The ParserMode enum and canParseSourceWithCpp/Rust test functions rust_pipeline_available() now unconditionally returns true.
2026-03-19 14:29:15 -03:00
#include <LibJS/Runtime/BigInt.h>
#include <LibJS/Runtime/Intrinsics.h>
#include <LibJS/Runtime/NativeJavaScriptBackedFunction.h>
#include <LibJS/Runtime/PrimitiveString.h>
#include <LibJS/Runtime/RegExpObject.h>
#include <LibJS/Runtime/SharedFunctionInstanceData.h>
#include <LibJS/Runtime/VM.h>
#include <LibJS/RustFFI.h>
#include <LibJS/Script.h>
#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
extern bool JS::g_dump_ast;
extern bool JS::g_dump_ast_use_color;
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
using namespace JS::FFI;
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 {
// --- Shared helpers ---
LibJS: Prepare bytecode cache validation off-thread Add an explicit validation entry point for decoded bytecode cache blobs. This lets callers validate a blob before materialization while keeping the existing validated-before-use invariant in place. Make validation idempotent so a prevalidated blob is not walked again when materialization reaches the same check. Keep the existing decoded source length query for callers that still validate synchronously. Route decoded cache blob owner destruction through the origin event loop. This lets a worker decode or reject mapped bytecode without releasing non-atomically refcounted ImmutableBytes off-thread, while lazy cached function materialization can still retain mmap-backed bytecode.
2026-06-03 19:38:49 -03:00
// Bytecode cache blobs are validated before rebuilding Executables. Materialization paths flip this flag for the
// duration of their work so rust_create_executable() does not run the same validator again.
LibJS: Avoid revalidating cached bytecode executables Cache blobs already validate decoded bytecode before rebuilding C++ Bytecode::Executable objects. Keep that as the only cache validation pass and mark the decoded cache state once it completes. Materialization now asserts that cache blobs and lazy cached function records passed through validation before they can be installed or decoded. This keeps the invariant without re-running the same validator from rust_create_executable().
2026-06-03 17:56:24 -03:00
static thread_local bool s_skip_bytecode_validation_for_prevalidated_cache = false;
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
LibJS: Handle empty UTF-16 strings in Rust FFI Treat zero length UTF-16 slices from Rust as empty views at the FFI boundary instead of assuming a non null backing pointer. Add a regression test which crashed before these changes. Fixes a crash loading github.com/ladybirdbrowser/ladybird.
2026-03-31 13:27:42 -03:00
static Utf16View utf16_view_from_bytes(uint16_t const* data, size_t len)
{
if (len == 0)
return {};
return Utf16View { reinterpret_cast<char16_t const*>(data), len };
}
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
static Utf16FlyString utf16_fly_from(uint16_t const* data, size_t len)
{
LibJS: Handle empty UTF-16 strings in Rust FFI Treat zero length UTF-16 slices from Rust as empty views at the FFI boundary instead of assuming a non null backing pointer. Add a regression test which crashed before these changes. Fixes a crash loading github.com/ladybirdbrowser/ladybird.
2026-03-31 13:27:42 -03:00
return Utf16FlyString::from_utf16(utf16_view_from_bytes(data, len));
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
}
static Utf16FlyString utf16_fly_from_raw(uint16_t const* data, size_t len)
{
if (len == 0)
return {};
LibJS: Handle empty UTF-16 strings in Rust FFI Treat zero length UTF-16 slices from Rust as empty views at the FFI boundary instead of assuming a non null backing pointer. Add a regression test which crashed before these changes. Fixes a crash loading github.com/ladybirdbrowser/ladybird.
2026-03-31 13:27:42 -03:00
return Utf16FlyString::from_utf16(utf16_view_from_bytes(data, len));
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
}
static Utf16String utf16_from_raw(uint16_t const* data, size_t len)
{
if (len == 0)
return {};
LibJS: Handle empty UTF-16 strings in Rust FFI Treat zero length UTF-16 slices from Rust as empty views at the FFI boundary instead of assuming a non null backing pointer. Add a regression test which crashed before these changes. Fixes a crash loading github.com/ladybirdbrowser/ladybird.
2026-03-31 13:27:42 -03:00
return Utf16String::from_utf16(utf16_view_from_bytes(data, len));
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: Move bytecode instruction dumping to Rust Generate Rust bytecode dump helpers from Bytecode.def and route Executable::dump() through them for instruction stream formatting. Add a small Rust runtime::value helper for decoding encoded LibJS Values so immediate Value operands are formatted on the Rust side. C++ callbacks remain only for local names and GC-backed Value payloads that still need LibJS object access. Remove the generated C++ to_byte_string_impl() methods and the old Instruction::to_byte_string() dispatch. The bytecode dump tests cover output compatibility.
2026-06-14 13:12:06 -03:00
static StringView string_view_from_rust_bytes(uint8_t const* data, size_t len)
{
return { reinterpret_cast<char const*>(data), len };
}
struct BytecodeDumpBuilder {
StringBuilder& output;
GC::Ref<Bytecode::Executable const> executable;
};
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
// --- Error collection callbacks ---
// Collects parse errors as a Vector<ParserError> (for Script/Module compilation).
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
static void collect_parse_errors(void* ctx, uint16_t const* message, size_t message_len, uint32_t line, uint32_t column)
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
{
auto& errors = *static_cast<Vector<ParserError>*>(ctx);
errors.append({
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
Utf16String::from_utf16(utf16_view_from_bytes(message, message_len)),
LibJS: Drop source ranges from bytecode source maps Store source map locations as bytecode offset, line, and column. Runtime consumers only emit the start line and column, so source end positions and source text offsets do not need to be carried through Executable source maps, bytecode cache serialization, or the Rust FFI. Keep SourceCode's internal position cache able to track source text offsets so callers can still translate source offsets to line and column pairs when needed. Hash dump-bytecode IDs from the name, first source position, and bytecode size instead of source slices that need end offsets. Bump the bytecode cache format version for the slimmer serialized source map entry shape.
2026-05-14 03:29:39 -03:00
Position { line, column },
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
});
}
Libraries: Use UTF-16 for JS-visible runtime strings Produce JS-visible string results as UTF-16 at their source, including numeric formatting, BigInt and BigFraction formatting, URI encoding, console formatting, parser errors, regular expression errors, Intl and Temporal records, LibUnicode locale boundaries, and LibWeb bindings. Handle fractional radix formatting through the UTF-16 builder view.
2026-06-21 14:03:10 -03:00
// Collects a single parse error as a formatted Utf16String (for eval/dynamic function compilation).
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
static void collect_single_parse_error(void* ctx, uint16_t const* message, size_t message_len, uint32_t line, uint32_t column)
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
{
Libraries: Use UTF-16 for JS-visible runtime strings Produce JS-visible string results as UTF-16 at their source, including numeric formatting, BigInt and BigFraction formatting, URI encoding, console formatting, parser errors, regular expression errors, Intl and Temporal records, LibUnicode locale boundaries, and LibWeb bindings. Handle fractional radix formatting through the UTF-16 builder view.
2026-06-21 14:03:10 -03:00
auto& error_message = *static_cast<Utf16String*>(ctx);
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
if (error_message.is_empty())
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
error_message = Utf16String::formatted("{} (line: {}, column: {})", utf16_view_from_bytes(message, message_len), line, column);
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
}
// --- Script GDI builder and callbacks ---
struct ScriptGdiBuilder {
ScriptResult result;
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
SharedFunctionInstanceDataList shared_function_data;
void collect_shared_function_data()
{
result.shared_function_data.clear();
shared_function_data.for_each([&](auto& shared_data) {
result.shared_function_data.append(shared_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
};
}
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 {
LibJS: Move bytecode instruction dumping to Rust Generate Rust bytecode dump helpers from Bytecode.def and route Executable::dump() through them for instruction stream formatting. Add a small Rust runtime::value helper for decoding encoded LibJS Values so immediate Value operands are formatted on the Rust side. C++ callbacks remain only for local names and GC-backed Value payloads that still need LibJS object access. Remove the generated C++ to_byte_string_impl() methods and the old Instruction::to_byte_string() dispatch. The bytecode dump tests cover output compatibility.
2026-06-14 13:12:06 -03:00
static void bytecode_dump_append(void* ctx, uint8_t const* data, size_t len)
{
auto& builder = *static_cast<JS::RustIntegration::BytecodeDumpBuilder*>(ctx);
builder.output.append(JS::RustIntegration::string_view_from_rust_bytes(data, len));
}
static void bytecode_dump_append_local(void* ctx, uint32_t index)
{
auto& builder = *static_cast<JS::RustIntegration::BytecodeDumpBuilder*>(ctx);
LibJS: Remove unused C++ local variable wrapper The Rust bytecode generator only passes local variable names to C++ now, and no C++ code observes declaration kind metadata from LocalVariable. Store local names directly as Utf16FlyString values and remove the stale C++ wrapper type.
2026-06-14 16:09:41 -03:00
builder.output.append(builder.executable->local_variable_names[index]);
LibJS: Move bytecode instruction dumping to Rust Generate Rust bytecode dump helpers from Bytecode.def and route Executable::dump() through them for instruction stream formatting. Add a small Rust runtime::value helper for decoding encoded LibJS Values so immediate Value operands are formatted on the Rust side. C++ callbacks remain only for local names and GC-backed Value payloads that still need LibJS object access. Remove the generated C++ to_byte_string_impl() methods and the old Instruction::to_byte_string() dispatch. The bytecode dump tests cover output compatibility.
2026-06-14 13:12:06 -03:00
}
static void bytecode_dump_append_identifier(void* ctx, uint32_t index, bool quoted)
{
auto& builder = *static_cast<JS::RustIntegration::BytecodeDumpBuilder*>(ctx);
auto identifier = builder.executable->identifier_table->get(JS::Bytecode::IdentifierTableIndex { index });
if (quoted)
builder.output.appendff("\033[36m`{}`\033[0m", identifier);
else
builder.output.append(identifier);
}
static void bytecode_dump_append_property_key(void* ctx, uint32_t index, bool quoted)
{
auto& builder = *static_cast<JS::RustIntegration::BytecodeDumpBuilder*>(ctx);
auto const& property_key = builder.executable->property_key_table->get(JS::Bytecode::PropertyKeyTableIndex { index });
if (quoted)
builder.output.appendff("\033[36m`{}`\033[0m", property_key);
else
builder.output.appendff("{}", property_key);
}
static void bytecode_dump_append_string(void* ctx, uint32_t index)
{
auto& builder = *static_cast<JS::RustIntegration::BytecodeDumpBuilder*>(ctx);
builder.output.append(builder.executable->get_string(JS::Bytecode::StringTableIndex { index }));
}
static void bytecode_dump_append_value_double(void* ctx, double value)
{
auto& builder = *static_cast<JS::RustIntegration::BytecodeDumpBuilder*>(ctx);
builder.output.appendff("{}", value);
}
static void bytecode_dump_append_value_string(void* ctx, uint64_t encoded)
{
auto& builder = *static_cast<JS::RustIntegration::BytecodeDumpBuilder*>(ctx);
auto value = bit_cast<Value>(encoded);
LibJS: Store primitive strings as UTF-16 Keep primitive string storage in Utf16String and remove the UTF-8 storage path from PrimitiveString. ASCII strings still use compact Utf16String ASCII storage, while UTF-16 becomes the only owned representation.
2026-06-21 14:02:35 -03:00
builder.output.append(value.as_string().utf16_string_view());
LibJS: Move bytecode instruction dumping to Rust Generate Rust bytecode dump helpers from Bytecode.def and route Executable::dump() through them for instruction stream formatting. Add a small Rust runtime::value helper for decoding encoded LibJS Values so immediate Value operands are formatted on the Rust side. C++ callbacks remain only for local names and GC-backed Value payloads that still need LibJS object access. Remove the generated C++ to_byte_string_impl() methods and the old Instruction::to_byte_string() dispatch. The bytecode dump tests cover output compatibility.
2026-06-14 13:12:06 -03:00
}
static void bytecode_dump_append_value_bigint(void* ctx, uint64_t encoded)
{
auto& builder = *static_cast<JS::RustIntegration::BytecodeDumpBuilder*>(ctx);
auto value = bit_cast<Value>(encoded);
Libraries: Use UTF-16 for JS-visible runtime strings Produce JS-visible string results as UTF-16 at their source, including numeric formatting, BigInt and BigFraction formatting, URI encoding, console formatting, parser errors, regular expression errors, Intl and Temporal records, LibUnicode locale boundaries, and LibWeb bindings. Handle fractional radix formatting through the UTF-16 builder view.
2026-06-21 14:03:10 -03:00
builder.output.append(value.as_bigint().to_utf16_string());
LibJS: Move bytecode instruction dumping to Rust Generate Rust bytecode dump helpers from Bytecode.def and route Executable::dump() through them for instruction stream formatting. Add a small Rust runtime::value helper for decoding encoded LibJS Values so immediate Value operands are formatted on the Rust side. C++ callbacks remain only for local names and GC-backed Value payloads that still need LibJS object access. Remove the generated C++ to_byte_string_impl() methods and the old Instruction::to_byte_string() dispatch. The bytecode dump tests cover output compatibility.
2026-06-14 13:12:06 -03:00
}
static void bytecode_dump_append_value_fallback(void* ctx, uint64_t encoded)
{
auto& builder = *static_cast<JS::RustIntegration::BytecodeDumpBuilder*>(ctx);
auto value = bit_cast<Value>(encoded);
builder.output.appendff("{}", value);
}
}
namespace JS::RustIntegration {
LibJS: Move bytecode block counting to Rust Use the Rust bytecode dumper's basic block collection logic for the metadata block count. This removes the last C++ bytecode label walk and lets us delete the generated C++ label and operand visitor helpers.
2026-06-14 15:51:57 -03:00
static Vector<FFI::FFIDumpExceptionHandler> make_ffi_exception_handlers(Bytecode::Executable const& executable)
LibJS: Move bytecode instruction dumping to Rust Generate Rust bytecode dump helpers from Bytecode.def and route Executable::dump() through them for instruction stream formatting. Add a small Rust runtime::value helper for decoding encoded LibJS Values so immediate Value operands are formatted on the Rust side. C++ callbacks remain only for local names and GC-backed Value payloads that still need LibJS object access. Remove the generated C++ to_byte_string_impl() methods and the old Instruction::to_byte_string() dispatch. The bytecode dump tests cover output compatibility.
2026-06-14 13:12:06 -03:00
{
Vector<FFI::FFIDumpExceptionHandler> exception_handlers;
exception_handlers.ensure_capacity(executable.exception_handlers.size());
for (auto const& handler : executable.exception_handlers) {
LibJS: Move bytecode block counting to Rust Use the Rust bytecode dumper's basic block collection logic for the metadata block count. This removes the last C++ bytecode label walk and lets us delete the generated C++ label and operand visitor helpers.
2026-06-14 15:51:57 -03:00
exception_handlers.unchecked_append({
LibJS: Move bytecode instruction dumping to Rust Generate Rust bytecode dump helpers from Bytecode.def and route Executable::dump() through them for instruction stream formatting. Add a small Rust runtime::value helper for decoding encoded LibJS Values so immediate Value operands are formatted on the Rust side. C++ callbacks remain only for local names and GC-backed Value payloads that still need LibJS object access. Remove the generated C++ to_byte_string_impl() methods and the old Instruction::to_byte_string() dispatch. The bytecode dump tests cover output compatibility.
2026-06-14 13:12:06 -03:00
.start_offset = handler.start_offset,
.end_offset = handler.end_offset,
.handler_offset = handler.handler_offset,
});
}
LibJS: Move bytecode block counting to Rust Use the Rust bytecode dumper's basic block collection logic for the metadata block count. This removes the last C++ bytecode label walk and lets us delete the generated C++ label and operand visitor helpers.
2026-06-14 15:51:57 -03:00
return exception_handlers;
}
LibJS: Move bytecode instruction dumping to Rust Generate Rust bytecode dump helpers from Bytecode.def and route Executable::dump() through them for instruction stream formatting. Add a small Rust runtime::value helper for decoding encoded LibJS Values so immediate Value operands are formatted on the Rust side. C++ callbacks remain only for local names and GC-backed Value payloads that still need LibJS object access. Remove the generated C++ to_byte_string_impl() methods and the old Instruction::to_byte_string() dispatch. The bytecode dump tests cover output compatibility.
2026-06-14 13:12:06 -03:00
LibJS: Move bytecode block counting to Rust Use the Rust bytecode dumper's basic block collection logic for the metadata block count. This removes the last C++ bytecode label walk and lets us delete the generated C++ label and operand visitor helpers.
2026-06-14 15:51:57 -03:00
void dump_bytecode(StringBuilder& output, Bytecode::Executable const& executable)
{
auto exception_handlers = make_ffi_exception_handlers(executable);
LibJS: Move bytecode instruction dumping to Rust Generate Rust bytecode dump helpers from Bytecode.def and route Executable::dump() through them for instruction stream formatting. Add a small Rust runtime::value helper for decoding encoded LibJS Values so immediate Value operands are formatted on the Rust side. C++ callbacks remain only for local names and GC-backed Value payloads that still need LibJS object access. Remove the generated C++ to_byte_string_impl() methods and the old Instruction::to_byte_string() dispatch. The bytecode dump tests cover output compatibility.
2026-06-14 13:12:06 -03:00
BytecodeDumpBuilder builder { output, executable };
FFI::FFIBytecodeDumpCallbacks callbacks {
.append = FFI::bytecode_dump_append,
.append_local = FFI::bytecode_dump_append_local,
.append_identifier = FFI::bytecode_dump_append_identifier,
.append_property_key = FFI::bytecode_dump_append_property_key,
.append_string = FFI::bytecode_dump_append_string,
.append_value_double = FFI::bytecode_dump_append_value_double,
.append_value_string = FFI::bytecode_dump_append_value_string,
.append_value_bigint = FFI::bytecode_dump_append_value_bigint,
.append_value_fallback = FFI::bytecode_dump_append_value_fallback,
};
FFI::FFIBytecodeDumpMetadata metadata {
.number_of_registers = executable.number_of_registers,
.registers_and_locals_count = executable.registers_and_locals_count,
.local_index_base = executable.local_index_base,
.argument_index_base = executable.argument_index_base,
.constants = reinterpret_cast<uint64_t const*>(executable.constants.data()),
.constant_count = executable.constants.size(),
};
FFI::rust_dump_bytecode(
executable.bytecode.data(),
executable.bytecode.size(),
exception_handlers.data(),
exception_handlers.size(),
&metadata,
&builder,
&callbacks);
}
LibJS: Move bytecode block counting to Rust Use the Rust bytecode dumper's basic block collection logic for the metadata block count. This removes the last C++ bytecode label walk and lets us delete the generated C++ label and operand visitor helpers.
2026-06-14 15:51:57 -03:00
size_t count_bytecode_basic_blocks(Bytecode::Executable const& executable)
{
auto exception_handlers = make_ffi_exception_handlers(executable);
return FFI::rust_count_basic_blocks(
executable.bytecode.data(),
executable.bytecode.size(),
exception_handlers.data(),
exception_handlers.size());
}
LibJS: Move bytecode instruction dumping to Rust Generate Rust bytecode dump helpers from Bytecode.def and route Executable::dump() through them for instruction stream formatting. Add a small Rust runtime::value helper for decoding encoded LibJS Values so immediate Value operands are formatted on the Rust side. C++ callbacks remain only for local names and GC-backed Value payloads that still need LibJS object access. Remove the generated C++ to_byte_string_impl() methods and the old Instruction::to_byte_string() dispatch. The bytecode dump tests cover output compatibility.
2026-06-14 13:12:06 -03:00
}
namespace JS::FFI {
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
extern "C" void script_gdi_push_lexical_name(void* ctx, uint16_t const* name, size_t len)
{
static_cast<JS::RustIntegration::ScriptGdiBuilder*>(ctx)->result.lexical_names.append(JS::RustIntegration::utf16_fly_from(name, len));
}
extern "C" void script_gdi_push_var_name(void* ctx, uint16_t const* name, size_t len)
{
static_cast<JS::RustIntegration::ScriptGdiBuilder*>(ctx)->result.var_names.append(JS::RustIntegration::utf16_fly_from(name, len));
}
extern "C" void script_gdi_push_function(void* ctx, void* sfd_ptr, uint16_t const* name, size_t len)
{
auto& builder = *static_cast<JS::RustIntegration::ScriptGdiBuilder*>(ctx);
auto fn_name = JS::RustIntegration::utf16_fly_from(name, len);
builder.result.declared_function_names.set(fn_name);
auto& sfd = *static_cast<JS::SharedFunctionInstanceData*>(sfd_ptr);
builder.result.functions_to_initialize.append({ sfd, move(fn_name) });
}
extern "C" void script_gdi_push_var_scoped_name(void* ctx, uint16_t const* name, size_t len)
{
static_cast<JS::RustIntegration::ScriptGdiBuilder*>(ctx)->result.var_scoped_names.append(JS::RustIntegration::utf16_fly_from(name, len));
}
extern "C" void script_gdi_push_annex_b_name(void* ctx, uint16_t const* name, size_t len)
{
static_cast<JS::RustIntegration::ScriptGdiBuilder*>(ctx)->result.annex_b_candidate_names.append(JS::RustIntegration::utf16_fly_from(name, len));
}
extern "C" void script_gdi_push_lexical_binding(void* ctx, uint16_t const* name, size_t len, bool is_constant)
{
static_cast<JS::RustIntegration::ScriptGdiBuilder*>(ctx)->result.lexical_bindings.append({ JS::RustIntegration::utf16_fly_from(name, len), is_constant });
}
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 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
// --- Eval GDI builder and callbacks ---
namespace JS::RustIntegration {
struct EvalGdiBuilder {
GC::Ptr<Bytecode::Executable> executable;
bool is_strict_mode { false };
Vector<Utf16FlyString> var_names;
Vector<EvalDeclarationData::FunctionToInitialize> functions_to_initialize;
HashTable<Utf16FlyString> declared_function_names;
Vector<Utf16FlyString> var_scoped_names;
Vector<Utf16FlyString> annex_b_candidate_names;
Vector<EvalDeclarationData::LexicalBinding> lexical_bindings;
LibJS: Validate eval private names at instantiation Track private identifiers that eval code references outside a local class body and pass them through EvalDeclarationInstantiation data. This lets direct eval validate those names against the caller private environment before execution, while indirect eval and missing names still throw SyntaxError. Add coverage for direct eval access from methods, field initializers, static methods, and the missing-private-name SyntaxError path.
2026-05-21 08:04:46 -03:00
Vector<Utf16FlyString> referenced_private_names;
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
EvalResult to_result()
{
EvalResult result;
result.executable = executable;
result.is_strict_mode = is_strict_mode;
result.declaration_data.var_names = move(var_names);
result.declaration_data.functions_to_initialize = move(functions_to_initialize);
result.declaration_data.declared_function_names = move(declared_function_names);
result.declaration_data.var_scoped_names = move(var_scoped_names);
result.declaration_data.annex_b_candidate_names = move(annex_b_candidate_names);
result.declaration_data.lexical_bindings = move(lexical_bindings);
LibJS: Validate eval private names at instantiation Track private identifiers that eval code references outside a local class body and pass them through EvalDeclarationInstantiation data. This lets direct eval validate those names against the caller private environment before execution, while indirect eval and missing names still throw SyntaxError. Add coverage for direct eval access from methods, field initializers, static methods, and the missing-private-name SyntaxError path.
2026-05-21 08:04:46 -03:00
result.declaration_data.referenced_private_names = move(referenced_private_names);
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
return result;
}
};
}
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 {
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
extern "C" void eval_gdi_set_strict(void* ctx, bool is_strict)
{
static_cast<JS::RustIntegration::EvalGdiBuilder*>(ctx)->is_strict_mode = is_strict;
}
extern "C" void eval_gdi_push_var_name(void* ctx, uint16_t const* name, size_t len)
{
static_cast<JS::RustIntegration::EvalGdiBuilder*>(ctx)->var_names.append(JS::RustIntegration::utf16_fly_from(name, len));
}
extern "C" void eval_gdi_push_function(void* ctx, void* sfd_ptr, uint16_t const* name, size_t len)
{
auto& builder = *static_cast<JS::RustIntegration::EvalGdiBuilder*>(ctx);
auto fn_name = JS::RustIntegration::utf16_fly_from(name, len);
builder.declared_function_names.set(fn_name);
auto& sfd = *static_cast<JS::SharedFunctionInstanceData*>(sfd_ptr);
builder.functions_to_initialize.append({ sfd, move(fn_name) });
}
extern "C" void eval_gdi_push_var_scoped_name(void* ctx, uint16_t const* name, size_t len)
{
static_cast<JS::RustIntegration::EvalGdiBuilder*>(ctx)->var_scoped_names.append(JS::RustIntegration::utf16_fly_from(name, len));
}
extern "C" void eval_gdi_push_annex_b_name(void* ctx, uint16_t const* name, size_t len)
{
static_cast<JS::RustIntegration::EvalGdiBuilder*>(ctx)->annex_b_candidate_names.append(JS::RustIntegration::utf16_fly_from(name, len));
}
extern "C" void eval_gdi_push_lexical_binding(void* ctx, uint16_t const* name, size_t len, bool is_constant)
{
static_cast<JS::RustIntegration::EvalGdiBuilder*>(ctx)->lexical_bindings.append({ JS::RustIntegration::utf16_fly_from(name, len), is_constant });
}
LibJS: Validate eval private names at instantiation Track private identifiers that eval code references outside a local class body and pass them through EvalDeclarationInstantiation data. This lets direct eval validate those names against the caller private environment before execution, while indirect eval and missing names still throw SyntaxError. Add coverage for direct eval access from methods, field initializers, static methods, and the missing-private-name SyntaxError path.
2026-05-21 08:04:46 -03:00
extern "C" void eval_gdi_push_private_name(void* ctx, uint16_t const* name, size_t len)
{
static_cast<JS::RustIntegration::EvalGdiBuilder*>(ctx)->referenced_private_names.append(JS::RustIntegration::utf16_fly_from(name, len));
}
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 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
// --- Module builder and callbacks ---
namespace JS::RustIntegration {
struct ModuleBuilder {
ModuleResult result;
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
SharedFunctionInstanceDataList shared_function_data;
void collect_shared_function_data()
{
result.shared_function_data.clear();
shared_function_data.for_each([&](auto& shared_data) {
result.shared_function_data.append(shared_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
};
static Vector<ImportAttribute> attributes_from_ffi(FFIUtf16Slice const* keys, FFIUtf16Slice const* values, size_t count)
{
Vector<ImportAttribute> attributes;
for (size_t i = 0; i < count; ++i)
attributes.empend(utf16_from_raw(keys[i].data, keys[i].length), utf16_from_raw(values[i].data, values[i].length));
return attributes;
}
static Optional<ModuleRequest> module_request_from_ffi(uint16_t const* specifier, size_t specifier_len,
FFIUtf16Slice const* attribute_keys, FFIUtf16Slice const* attribute_values, size_t attribute_count)
{
if (specifier == nullptr || specifier_len == 0)
return {};
auto attributes = attributes_from_ffi(attribute_keys, attribute_values, attribute_count);
if (attributes.is_empty())
return ModuleRequest { utf16_fly_from_raw(specifier, specifier_len) };
return ModuleRequest { utf16_fly_from_raw(specifier, specifier_len), move(attributes) };
}
}
extern "C" {
static void module_set_has_top_level_await(void* ctx, bool value)
{
static_cast<JS::RustIntegration::ModuleBuilder*>(ctx)->result.has_top_level_await = value;
}
static void module_push_import_entry(void* ctx,
uint16_t const* import_name, size_t import_name_len, bool is_namespace,
uint16_t const* local_name, size_t local_name_len,
uint16_t const* specifier, size_t specifier_len,
FFIUtf16Slice const* attribute_keys, FFIUtf16Slice const* attribute_values, size_t attribute_count)
{
auto* builder = static_cast<JS::RustIntegration::ModuleBuilder*>(ctx);
Optional<Utf16FlyString> import_name_opt;
if (!is_namespace)
import_name_opt = JS::RustIntegration::utf16_fly_from_raw(import_name, import_name_len);
JS::ImportEntry entry { move(import_name_opt), JS::RustIntegration::utf16_fly_from_raw(local_name, local_name_len) };
entry.m_module_request = JS::RustIntegration::module_request_from_ffi(specifier, specifier_len, attribute_keys, attribute_values, attribute_count);
builder->result.import_entries.append(move(entry));
}
static void module_push_export_entry(Vector<JS::ExportEntry>& list, uint8_t kind,
uint16_t const* export_name, size_t export_name_len,
uint16_t const* local_or_import_name, size_t local_or_import_name_len,
uint16_t const* specifier, size_t specifier_len,
FFIUtf16Slice const* attribute_keys, FFIUtf16Slice const* attribute_values, size_t attribute_count)
{
Optional<Utf16FlyString> en;
if (export_name)
en = JS::RustIntegration::utf16_fly_from_raw(export_name, export_name_len);
Optional<Utf16FlyString> lin;
if (local_or_import_name)
lin = JS::RustIntegration::utf16_fly_from_raw(local_or_import_name, local_or_import_name_len);
JS::ExportEntry entry { static_cast<JS::ExportEntry::Kind>(kind), move(en), move(lin) };
entry.m_module_request = JS::RustIntegration::module_request_from_ffi(specifier, specifier_len, attribute_keys, attribute_values, attribute_count);
list.append(move(entry));
}
static void module_push_local_export(void* ctx, uint8_t kind,
uint16_t const* export_name, size_t export_name_len,
uint16_t const* local_or_import_name, size_t local_or_import_name_len,
uint16_t const* specifier, size_t specifier_len,
FFIUtf16Slice const* attribute_keys, FFIUtf16Slice const* attribute_values, size_t attribute_count)
{
module_push_export_entry(static_cast<JS::RustIntegration::ModuleBuilder*>(ctx)->result.local_export_entries, kind,
export_name, export_name_len, local_or_import_name, local_or_import_name_len,
specifier, specifier_len, attribute_keys, attribute_values, attribute_count);
}
static void module_push_indirect_export(void* ctx, uint8_t kind,
uint16_t const* export_name, size_t export_name_len,
uint16_t const* local_or_import_name, size_t local_or_import_name_len,
uint16_t const* specifier, size_t specifier_len,
FFIUtf16Slice const* attribute_keys, FFIUtf16Slice const* attribute_values, size_t attribute_count)
{
module_push_export_entry(static_cast<JS::RustIntegration::ModuleBuilder*>(ctx)->result.indirect_export_entries, kind,
export_name, export_name_len, local_or_import_name, local_or_import_name_len,
specifier, specifier_len, attribute_keys, attribute_values, attribute_count);
}
static void module_push_star_export(void* ctx, uint8_t kind,
uint16_t const* export_name, size_t export_name_len,
uint16_t const* local_or_import_name, size_t local_or_import_name_len,
uint16_t const* specifier, size_t specifier_len,
FFIUtf16Slice const* attribute_keys, FFIUtf16Slice const* attribute_values, size_t attribute_count)
{
module_push_export_entry(static_cast<JS::RustIntegration::ModuleBuilder*>(ctx)->result.star_export_entries, kind,
export_name, export_name_len, local_or_import_name, local_or_import_name_len,
specifier, specifier_len, attribute_keys, attribute_values, attribute_count);
}
static void module_push_requested_module(void* ctx,
uint16_t const* specifier, size_t specifier_len,
FFIUtf16Slice const* attribute_keys, FFIUtf16Slice const* attribute_values, size_t attribute_count)
{
auto* builder = static_cast<JS::RustIntegration::ModuleBuilder*>(ctx);
auto attributes = JS::RustIntegration::attributes_from_ffi(attribute_keys, attribute_values, attribute_count);
if (attributes.is_empty())
builder->result.requested_modules.empend(JS::RustIntegration::utf16_fly_from_raw(specifier, specifier_len));
else
builder->result.requested_modules.empend(JS::RustIntegration::utf16_fly_from_raw(specifier, specifier_len), move(attributes));
}
static void module_set_default_export_binding(void* ctx, uint16_t const* name, size_t name_len)
{
static_cast<JS::RustIntegration::ModuleBuilder*>(ctx)->result.default_export_binding_name = JS::RustIntegration::utf16_fly_from_raw(name, name_len);
}
static void module_push_var_name(void* ctx, uint16_t const* name, size_t name_len)
{
static_cast<JS::RustIntegration::ModuleBuilder*>(ctx)->result.var_declared_names.append(JS::RustIntegration::utf16_fly_from_raw(name, name_len));
}
static void module_push_function(void* ctx, void* sfd_ptr, uint16_t const* name, size_t name_len)
{
auto& shared = *static_cast<JS::SharedFunctionInstanceData*>(sfd_ptr);
static_cast<JS::RustIntegration::ModuleBuilder*>(ctx)->result.functions_to_initialize.append({ shared, JS::RustIntegration::utf16_fly_from_raw(name, name_len) });
}
static void module_push_lexical_binding(void* ctx, uint16_t const* name, size_t name_len, bool is_constant, int32_t function_index)
{
static_cast<JS::RustIntegration::ModuleBuilder*>(ctx)->result.lexical_bindings.append({
.name = JS::RustIntegration::utf16_fly_from_raw(name, name_len),
.is_constant = is_constant,
.function_index = function_index,
});
}
} // extern "C"
// --- Builtin file callback ---
namespace JS::RustIntegration {
static void collect_builtin_function(void* ctx, void* sfd_ptr, uint16_t const*, size_t)
{
auto& list = *static_cast<Vector<GC::Root<SharedFunctionInstanceData>>*>(ctx);
list.append(*static_cast<SharedFunctionInstanceData*>(sfd_ptr));
}
// --- Compile functions ---
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
ParsedProgram* parse_program(u16 const* utf16_data, size_t length_in_code_units, ProgramType type, 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
{
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
return rust_parse_program(utf16_data, length_in_code_units, static_cast<u8>(type), line_number_offset, g_dump_ast, g_dump_ast_use_color);
}
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
CompiledProgram* compile_parsed_program_off_thread(ParsedProgram* parsed, size_t length_in_code_units)
{
return rust_compile_parsed_program_off_thread(parsed, 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
CompiledProgram* compile_parsed_program_fully_off_thread(ParsedProgram* parsed, size_t length_in_code_units)
{
return rust_compile_parsed_program_fully_off_thread(parsed, 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
bool parsed_program_has_errors(ParsedProgram const* parsed)
{
return rust_parsed_program_has_errors(const_cast<ParsedProgram*>(parsed));
}
void free_parsed_program(ParsedProgram* parsed)
{
rust_free_parsed_program(parsed);
}
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
void free_compiled_program(CompiledProgram* compiled)
{
rust_free_compiled_program(compiled);
}
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
ByteBuffer serialize_compiled_program_for_bytecode_cache(CompiledProgram const& compiled, ProgramType type, 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: 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
auto blob = rust_serialize_compiled_program_for_bytecode_cache(&compiled, static_cast<u8>(type), source_hash.data(), source_hash.size());
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
if (!blob.data || blob.length == 0)
return {};
auto bytes = ByteBuffer::copy({ blob.data, blob.length }).release_value_but_fixme_should_propagate_errors();
rust_free_bytecode_cache_blob(blob.data, blob.length);
return bytes;
}
LibJS: Prepare bytecode cache validation off-thread Add an explicit validation entry point for decoded bytecode cache blobs. This lets callers validate a blob before materialization while keeping the existing validated-before-use invariant in place. Make validation idempotent so a prevalidated blob is not walked again when materialization reaches the same check. Keep the existing decoded source length query for callers that still validate synchronously. Route decoded cache blob owner destruction through the origin event loop. This lets a worker decode or reject mapped bytecode without releasing non-atomically refcounted ImmutableBytes off-thread, while lazy cached function materialization can still retain mmap-backed bytecode.
2026-06-03 19:38:49 -03:00
struct BytecodeCacheBlobOwner {
Core::ImmutableBytes bytes;
LibWeb+LibJS: Validate bytecode cache blobs off-thread Warm cache hits used to validate bytecode cache blobs on the main thread. Route script and module sidecars through a worker step that decodes and validates the cache blob, then returns the validated blob for main-thread materialization. Keep the source bytes mmap-backed and avoid decoding the full source on cache hits. The main thread still computes the UTF-16 source length so validation can reject stale blobs before materialization. Remove the decoded source length getter now that sidecar validation uses the explicit validation API instead.
2026-06-05 15:28:23 -03:00
Core::EventLoop* event_loop { nullptr };
LibJS: Prepare bytecode cache validation off-thread Add an explicit validation entry point for decoded bytecode cache blobs. This lets callers validate a blob before materialization while keeping the existing validated-before-use invariant in place. Make validation idempotent so a prevalidated blob is not walked again when materialization reaches the same check. Keep the existing decoded source length query for callers that still validate synchronously. Route decoded cache blob owner destruction through the origin event loop. This lets a worker decode or reject mapped bytecode without releasing non-atomically refcounted ImmutableBytes off-thread, while lazy cached function materialization can still retain mmap-backed bytecode.
2026-06-03 19:38:49 -03:00
};
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
static void free_bytecode_cache_blob_owner(void* owner)
{
LibJS: Prepare bytecode cache validation off-thread Add an explicit validation entry point for decoded bytecode cache blobs. This lets callers validate a blob before materialization while keeping the existing validated-before-use invariant in place. Make validation idempotent so a prevalidated blob is not walked again when materialization reaches the same check. Keep the existing decoded source length query for callers that still validate synchronously. Route decoded cache blob owner destruction through the origin event loop. This lets a worker decode or reject mapped bytecode without releasing non-atomically refcounted ImmutableBytes off-thread, while lazy cached function materialization can still retain mmap-backed bytecode.
2026-06-03 19:38:49 -03:00
auto owner_ptr = adopt_own_if_nonnull(static_cast<BytecodeCacheBlobOwner*>(owner));
if (!owner_ptr)
return;
LibWeb+LibJS: Validate bytecode cache blobs off-thread Warm cache hits used to validate bytecode cache blobs on the main thread. Route script and module sidecars through a worker step that decodes and validates the cache blob, then returns the validated blob for main-thread materialization. Keep the source bytes mmap-backed and avoid decoding the full source on cache hits. The main thread still computes the UTF-16 source length so validation can reject stale blobs before materialization. Remove the decoded source length getter now that sidecar validation uses the explicit validation API instead.
2026-06-05 15:28:23 -03:00
if (owner_ptr->event_loop) {
owner_ptr->event_loop->deferred_invoke([owner = move(owner_ptr)] { (void)owner; });
LibJS: Prepare bytecode cache validation off-thread Add an explicit validation entry point for decoded bytecode cache blobs. This lets callers validate a blob before materialization while keeping the existing validated-before-use invariant in place. Make validation idempotent so a prevalidated blob is not walked again when materialization reaches the same check. Keep the existing decoded source length query for callers that still validate synchronously. Route decoded cache blob owner destruction through the origin event loop. This lets a worker decode or reject mapped bytecode without releasing non-atomically refcounted ImmutableBytes off-thread, while lazy cached function materialization can still retain mmap-backed bytecode.
2026-06-03 19:38:49 -03:00
return;
}
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
}
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
static void* clone_bytecode_cache_bytecode_owner(void const* owner)
LibJS: Keep cached bytecode file-backed Teach Bytecode::Executable to store its instruction stream as either an owned Vector or a retained Core::ImmutableBytes range. Cached bytecode materialization now clones the immutable blob owner and lets the executable point directly into the file-backed cache blob instead of copying instruction bytes back onto the heap. Keep a cached instruction data pointer inside the stream wrapper so the asm interpreter still has a direct hot-path load. Align executable bytecode payloads in the cache format so mmap-backed instruction streams satisfy validator and interpreter alignment requirements.
2026-05-18 08:29:29 -03:00
{
LibJS: Prepare bytecode cache validation off-thread Add an explicit validation entry point for decoded bytecode cache blobs. This lets callers validate a blob before materialization while keeping the existing validated-before-use invariant in place. Make validation idempotent so a prevalidated blob is not walked again when materialization reaches the same check. Keep the existing decoded source length query for callers that still validate synchronously. Route decoded cache blob owner destruction through the origin event loop. This lets a worker decode or reject mapped bytecode without releasing non-atomically refcounted ImmutableBytes off-thread, while lazy cached function materialization can still retain mmap-backed bytecode.
2026-06-03 19:38:49 -03:00
auto const& existing_owner = *static_cast<BytecodeCacheBlobOwner const*>(owner);
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
return new Core::ImmutableBytes { existing_owner.bytes };
LibJS: Keep cached bytecode file-backed Teach Bytecode::Executable to store its instruction stream as either an owned Vector or a retained Core::ImmutableBytes range. Cached bytecode materialization now clones the immutable blob owner and lets the executable point directly into the file-backed cache blob instead of copying instruction bytes back onto the heap. Keep a cached instruction data pointer inside the stream wrapper so the asm interpreter still has a direct hot-path load. Align executable bytecode payloads in the cache format so mmap-backed instruction streams satisfy validator and interpreter alignment requirements.
2026-05-18 08:29:29 -03:00
}
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
static DecodedBytecodeCacheBlob* decode_bytecode_cache_blob(Core::ImmutableBytes bytes, ProgramType expected_type, ReadonlyBytes source_hash)
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
{
LibWeb+LibJS: Validate bytecode cache blobs off-thread Warm cache hits used to validate bytecode cache blobs on the main thread. Route script and module sidecars through a worker step that decodes and validates the cache blob, then returns the validated blob for main-thread materialization. Keep the source bytes mmap-backed and avoid decoding the full source on cache hits. The main thread still computes the UTF-16 source length so validation can reject stale blobs before materialization. Remove the decoded source length getter now that sidecar validation uses the explicit validation API instead.
2026-06-05 15:28:23 -03:00
auto* owner = new BytecodeCacheBlobOwner { move(bytes) };
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
return rust_decode_bytecode_cache_blob_with_owner(owner->bytes.bytes().data(), owner->bytes.bytes().size(), static_cast<u8>(expected_type), source_hash.data(), source_hash.size(), owner, clone_bytecode_cache_bytecode_owner, free_bytecode_cache_blob_owner);
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
}
LibWeb+LibJS: Validate bytecode cache blobs off-thread Warm cache hits used to validate bytecode cache blobs on the main thread. Route script and module sidecars through a worker step that decodes and validates the cache blob, then returns the validated blob for main-thread materialization. Keep the source bytes mmap-backed and avoid decoding the full source on cache hits. The main thread still computes the UTF-16 source length so validation can reject stale blobs before materialization. Remove the decoded source length getter now that sidecar validation uses the explicit validation API instead.
2026-06-05 15:28:23 -03:00
DecodedBytecodeCacheBlob* decode_bytecode_cache_blob(Core::ImmutableBytes bytes, ProgramType expected_type, ReadonlyBytes source_hash, Core::EventLoop& event_loop)
LibJS: Hash encoded source identity in bytecode cache Switch bytecode cache source identity from decoded UTF-16 source text to the original encoded response bytes plus the effective source encoding. Store the decoded source length in the cache blob header so warm loads can build lazy SourceCode objects without decoding the source before checking the sidecar. This removes the main-thread decoded_source_text_info pass from valid warm-cache script and module loads. The source is only decoded on cache miss, or when a rejected sidecar falls back to source compilation.
2026-06-03 06:03:51 -03:00
{
LibWeb+LibJS: Validate bytecode cache blobs off-thread Warm cache hits used to validate bytecode cache blobs on the main thread. Route script and module sidecars through a worker step that decodes and validates the cache blob, then returns the validated blob for main-thread materialization. Keep the source bytes mmap-backed and avoid decoding the full source on cache hits. The main thread still computes the UTF-16 source length so validation can reject stale blobs before materialization. Remove the decoded source length getter now that sidecar validation uses the explicit validation API instead.
2026-06-05 15:28:23 -03:00
auto* owner = new BytecodeCacheBlobOwner { move(bytes), &event_loop };
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
return rust_decode_bytecode_cache_blob_with_owner(owner->bytes.bytes().data(), owner->bytes.bytes().size(), static_cast<u8>(expected_type), source_hash.data(), source_hash.size(), owner, clone_bytecode_cache_bytecode_owner, free_bytecode_cache_blob_owner);
LibJS: Hash encoded source identity in bytecode cache Switch bytecode cache source identity from decoded UTF-16 source text to the original encoded response bytes plus the effective source encoding. Store the decoded source length in the cache blob header so warm loads can build lazy SourceCode objects without decoding the source before checking the sidecar. This removes the main-thread decoded_source_text_info pass from valid warm-cache script and module loads. The source is only decoded on cache miss, or when a rejected sidecar falls back to source compilation.
2026-06-03 06:03:51 -03:00
}
LibJS: Prepare bytecode cache validation off-thread Add an explicit validation entry point for decoded bytecode cache blobs. This lets callers validate a blob before materialization while keeping the existing validated-before-use invariant in place. Make validation idempotent so a prevalidated blob is not walked again when materialization reaches the same check. Keep the existing decoded source length query for callers that still validate synchronously. Route decoded cache blob owner destruction through the origin event loop. This lets a worker decode or reject mapped bytecode without releasing non-atomically refcounted ImmutableBytes off-thread, while lazy cached function materialization can still retain mmap-backed bytecode.
2026-06-03 19:38:49 -03:00
bool validate_decoded_bytecode_cache_blob(DecodedBytecodeCacheBlob* blob, size_t source_length)
{
return rust_validate_decoded_bytecode_cache_blob(blob, source_length);
}
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
void free_decoded_bytecode_cache_blob(DecodedBytecodeCacheBlob* blob)
{
rust_free_decoded_bytecode_cache_blob(blob);
}
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
DecodedBytecodeCache::DecodedBytecodeCache(DecodedBytecodeCacheBlob* blob)
: m_blob(blob)
{
VERIFY(m_blob);
}
DecodedBytecodeCache::~DecodedBytecodeCache()
{
rust_free_decoded_bytecode_cache_blob(m_blob);
}
RefPtr<DecodedBytecodeCache> DecodedBytecodeCache::create(Core::ImmutableBytes bytes, ProgramType expected_type, ReadonlyBytes source_hash)
{
auto* blob = decode_bytecode_cache_blob(move(bytes), expected_type, source_hash);
if (!blob)
return {};
return create(blob);
}
NonnullRefPtr<DecodedBytecodeCache> DecodedBytecodeCache::create(DecodedBytecodeCacheBlob* blob)
{
return adopt_ref(*new DecodedBytecodeCache(blob));
}
DecodedBytecodeCacheBlob* DecodedBytecodeCache::create_materialization_handle() const
{
return rust_ref_decoded_bytecode_cache_blob(m_blob);
}
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(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
{
if (!parsed)
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
return {};
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
if (rust_parsed_program_has_errors(parsed)) {
Vector<ParserError> parse_errors;
rust_parsed_program_take_errors(parsed, &parse_errors, collect_parse_errors);
rust_free_parsed_program(parsed);
return parse_errors;
}
auto length = source_code->length_in_code_units();
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::DeferGC defer_gc(realm.vm().heap());
ScriptGdiBuilder builder;
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
void* exec_ptr = rust_compile_parsed_script(parsed, &realm.vm(), source_code.ptr(), &builder.shared_function_data, &builder, length);
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: 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
if (!exec_ptr)
return Vector<ParserError> {};
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: 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
builder.collect_shared_function_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
builder.result.executable = static_cast<Bytecode::Executable*>(exec_ptr);
return builder.result;
}
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
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
Optional<Result<ScriptResult, Vector<ParserError>>> materialize_compiled_script(CompiledProgram* compiled, NonnullRefPtr<SourceCode const> source_code, Realm& realm)
{
if (!compiled)
return {};
GC::DeferGC defer_gc(realm.vm().heap());
ScriptGdiBuilder builder;
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
void* exec_ptr = rust_materialize_compiled_script(compiled, &realm.vm(), source_code.ptr(), &builder.shared_function_data, &builder);
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
if (!exec_ptr)
return Vector<ParserError> {};
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
builder.collect_shared_function_data();
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
builder.result.executable = static_cast<Bytecode::Executable*>(exec_ptr);
return builder.result;
}
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
Optional<Result<ScriptResult, Vector<ParserError>>> materialize_bytecode_cache_script(DecodedBytecodeCache& bytecode_cache, NonnullRefPtr<SourceCode const> source_code, Realm& realm)
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
{
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
auto* blob = bytecode_cache.create_materialization_handle();
VERIFY(blob);
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
GC::DeferGC defer_gc(realm.vm().heap());
LibJS: Avoid revalidating cached bytecode executables Cache blobs already validate decoded bytecode before rebuilding C++ Bytecode::Executable objects. Keep that as the only cache validation pass and mark the decoded cache state once it completes. Materialization now asserts that cache blobs and lazy cached function records passed through validation before they can be installed or decoded. This keeps the invariant without re-running the same validator from rust_create_executable().
2026-06-03 17:56:24 -03:00
TemporaryChange skip_cache_executable_validation { s_skip_bytecode_validation_for_prevalidated_cache, true };
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
ScriptGdiBuilder builder;
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
void* exec_ptr = rust_materialize_bytecode_cache_script(blob, &realm.vm(), source_code.ptr(), source_code->length_in_code_units(), &builder.shared_function_data, &builder);
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
if (!exec_ptr)
Libraries: Use UTF-16 for JS-visible runtime strings Produce JS-visible string results as UTF-16 at their source, including numeric formatting, BigInt and BigFraction formatting, URI encoding, console formatting, parser errors, regular expression errors, Intl and Temporal records, LibUnicode locale boundaries, and LibWeb bindings. Handle fractional radix formatting through the UTF-16 builder view.
2026-06-21 14:03:10 -03:00
return Vector<ParserError> { ParserError { "Failed to materialize bytecode cache"_utf16, {} } };
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
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
builder.collect_shared_function_data();
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
builder.result.executable = static_cast<Bytecode::Executable*>(exec_ptr);
return builder.result;
}
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
Optional<Result<ScriptResult, Vector<ParserError>>> compile_script(Utf16View source_text, Realm& realm, Utf16View display_filename, size_t line_number_offset)
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
{
auto source_code = SourceCode::create(
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
Utf16String::from_utf16(display_filename),
Libraries: Parse JS strings from UTF-16 Thread UTF-16 string input through JSON, script parsing, Date parsing, Intl option parsing, Temporal parsing, and the helper library boundaries that feed those parsers. Preserve ASCII fast paths where the source data is known to be ASCII.
2026-06-21 14:03:06 -03:00
Utf16String::from_utf16(source_text));
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
auto const* source_ptr = source_code->utf16_data();
auto length = source_code->length_in_code_units();
auto* parsed = rust_parse_program(source_ptr, length, static_cast<u8>(ProgramType::Script), line_number_offset, g_dump_ast, g_dump_ast_use_color);
LibJS: Remove pipeline comparison infrastructure Remove PipelineComparison.cpp/h and all LIBJS_COMPARE_PIPELINES support from RustIntegration.cpp. This includes: - The compare_pipelines_enabled() function - All comparison blocks in compile_script/eval/module/function - The pair_shared_function_data() helper - The m_cpp_comparison_sfd field on SharedFunctionInstanceData The Rust pipeline has been validated extensively through comparison testing and no longer needs the side-by-side verification harness.
2026-03-19 14:07:57 -03:00
return compile_parsed_script(parsed, source_code, 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
}
Libraries: Use UTF-16 for JS-visible runtime strings Produce JS-visible string results as UTF-16 at their source, including numeric formatting, BigInt and BigFraction formatting, URI encoding, console formatting, parser errors, regular expression errors, Intl and Temporal records, LibUnicode locale boundaries, and LibWeb bindings. Handle fractional radix formatting through the UTF-16 builder view.
2026-06-21 14:03:10 -03:00
Optional<Result<EvalResult, Utf16String>> 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
PrimitiveString& code_string, VM& vm,
CallerMode strict_caller, bool in_function, bool in_method,
bool in_derived_constructor, bool in_class_field_initializer)
{
auto source_code = SourceCode::create({}, code_string.utf16_string());
auto const& code_view = source_code->code_view();
auto length = code_view.length_in_code_units();
GC::DeferGC defer_gc(vm.heap());
EvalGdiBuilder builder;
Libraries: Use UTF-16 for JS-visible runtime strings Produce JS-visible string results as UTF-16 at their source, including numeric formatting, BigInt and BigFraction formatting, URI encoding, console formatting, parser errors, regular expression errors, Intl and Temporal records, LibUnicode locale boundaries, and LibWeb bindings. Handle fractional radix formatting through the UTF-16 builder view.
2026-06-21 14:03:10 -03:00
Utf16String parse_error;
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: Cache ASCII-to-UTF-16 source conversion for Rust compilation The Rust FFI requires UTF-16 source data, so ASCII-stored source code must be widened to UTF-16. Previously, this conversion was done into a temporary buffer on every call to compile_function, meaning the entire source file was converted for each lazily-compiled function. For large modules with many functions, this caused heavy spinning. Move the conversion into SourceCode::utf16_data() which lazily converts and caches the result once per source file. Subsequent compilations of functions from the same file reuse the cached data.
2026-02-24 18:07:27 -03:00
auto const* source_ptr = source_code->utf16_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
void* exec_ptr = rust_compile_eval(source_ptr, length, &vm, source_code.ptr(), &builder,
strict_caller == CallerMode::Strict,
in_function, in_method, in_derived_constructor, in_class_field_initializer,
LibJS: Remove pipeline comparison infrastructure Remove PipelineComparison.cpp/h and all LIBJS_COMPARE_PIPELINES support from RustIntegration.cpp. This includes: - The compare_pipelines_enabled() function - All comparison blocks in compile_script/eval/module/function - The pair_shared_function_data() helper - The m_cpp_comparison_sfd field on SharedFunctionInstanceData The Rust pipeline has been validated extensively through comparison testing and no longer needs the side-by-side verification harness.
2026-03-19 14:07:57 -03:00
&parse_error, collect_single_parse_error, nullptr, nullptr);
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: Remove pipeline comparison infrastructure Remove PipelineComparison.cpp/h and all LIBJS_COMPARE_PIPELINES support from RustIntegration.cpp. This includes: - The compare_pipelines_enabled() function - All comparison blocks in compile_script/eval/module/function - The pair_shared_function_data() helper - The m_cpp_comparison_sfd field on SharedFunctionInstanceData The Rust pipeline has been validated extensively through comparison testing and no longer needs the side-by-side verification harness.
2026-03-19 14:07:57 -03:00
if (!exec_ptr)
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
return parse_error;
builder.executable = static_cast<Bytecode::Executable*>(exec_ptr);
builder.executable->name = "eval"_utf16_fly_string;
auto result = builder.to_result();
// If the caller is strict, the eval is always strict regardless of what Rust reported.
if (strict_caller == CallerMode::Strict)
result.is_strict_mode = true;
return result;
}
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(ParsedProgram* parsed, 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
{
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
if (!parsed)
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
return {};
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
if (rust_parsed_program_has_errors(parsed)) {
Vector<ParserError> parse_errors;
rust_parsed_program_take_errors(parsed, &parse_errors, collect_parse_errors);
rust_free_parsed_program(parsed);
return parse_errors;
}
auto length = source_code->length_in_code_units();
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: Defer GC during Rust-pipeline module and builtin compilation The Rust bytecode pipeline stores SharedFunctionInstanceData pointers as raw void pointers invisible to the GC. If garbage collection runs during compilation (triggered by heap allocation of a new SFD), it can collect previously created SFDs, leaving stale pointers that crash during the next GC marking phase. Every other Rust compilation entry point (compile_script, compile_eval, compile_shadow_realm_eval, compile_dynamic_function, compile_function) already uses GC::DeferGC to prevent this. Add the missing DeferGC to compile_module and compile_builtin_file.
2026-02-24 17:52:36 -03:00
GC::DeferGC defer_gc(realm.vm().heap());
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
ModuleBuilder builder;
ModuleCallbacks callbacks {
.set_has_top_level_await = module_set_has_top_level_await,
.push_import_entry = module_push_import_entry,
.push_local_export = module_push_local_export,
.push_indirect_export = module_push_indirect_export,
.push_star_export = module_push_star_export,
.push_requested_module = module_push_requested_module,
.set_default_export_binding = module_set_default_export_binding,
.push_var_name = module_push_var_name,
.push_function = module_push_function,
.push_lexical_binding = module_push_lexical_binding,
};
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
void* tla_executable = nullptr;
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: 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
void* exec_ptr = rust_compile_parsed_module(parsed, &realm.vm(), source_code.ptr(), &builder.shared_function_data,
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
&builder, &callbacks, &tla_executable, length);
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: 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
if (!exec_ptr && !tla_executable)
return Vector<ParserError> {};
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: 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
builder.collect_shared_function_data();
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
if (tla_executable) {
auto& vm = realm.vm();
auto* tla_exec = static_cast<Bytecode::Executable*>(tla_executable);
builder.result.tla_shared_data = vm.heap().allocate<SharedFunctionInstanceData>(
vm, FunctionKind::Async,
"module code with top-level await"_utf16_fly_string,
0, 0, true, false, true,
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<Utf16FlyString> {}, NoSharedFunctionDataList {}, nullptr);
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
builder.result.tla_shared_data->m_is_module_wrapper = true;
builder.result.tla_shared_data->m_uses_this = true;
builder.result.tla_shared_data->m_function_environment_needed = true;
builder.result.tla_shared_data->update_asm_call_metadata();
builder.result.tla_shared_data->set_executable(tla_exec);
} else {
builder.result.executable = static_cast<Bytecode::Executable*>(exec_ptr);
}
return builder.result;
}
Optional<Result<ModuleResult, Vector<ParserError>>> materialize_compiled_module(CompiledProgram* compiled, NonnullRefPtr<SourceCode const> source_code, Realm& realm)
{
if (!compiled)
return {};
GC::DeferGC defer_gc(realm.vm().heap());
ModuleBuilder builder;
ModuleCallbacks callbacks {
.set_has_top_level_await = module_set_has_top_level_await,
.push_import_entry = module_push_import_entry,
.push_local_export = module_push_local_export,
.push_indirect_export = module_push_indirect_export,
.push_star_export = module_push_star_export,
.push_requested_module = module_push_requested_module,
.set_default_export_binding = module_set_default_export_binding,
.push_var_name = module_push_var_name,
.push_function = module_push_function,
.push_lexical_binding = module_push_lexical_binding,
};
void* tla_executable = nullptr;
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
void* exec_ptr = rust_materialize_compiled_module(compiled, &realm.vm(), source_code.ptr(), &builder.shared_function_data,
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
&builder, &callbacks, &tla_executable);
if (!exec_ptr && !tla_executable)
return Vector<ParserError> {};
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
builder.collect_shared_function_data();
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
if (tla_executable) {
auto& vm = realm.vm();
auto* tla_exec = static_cast<Bytecode::Executable*>(tla_executable);
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: 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
builder.result.tla_shared_data = vm.heap().allocate<SharedFunctionInstanceData>(
vm, FunctionKind::Async,
"module code with top-level await"_utf16_fly_string,
0, 0, true, false, true,
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<Utf16FlyString> {}, NoSharedFunctionDataList {}, nullptr);
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
builder.result.tla_shared_data->m_is_module_wrapper = true;
builder.result.tla_shared_data->m_uses_this = true;
builder.result.tla_shared_data->m_function_environment_needed = true;
LibJS: Pack asm Call shared-data metadata Pack the asm Call fast path metadata next to the executable pointer so the interpreter can fetch both values with one paired load. This removes several dependent shared-data loads from the hot path. Keep the executable pointer and packed metadata in separate registers through this binding so the fast path can still use the paired-load layout after any non-strict this adjustment. Lower the packed metadata flag checks correctly on x86_64 as well. Those bits now live above bit 31, so the generator uses bt for single- bit high masks and covers that path with a unit test. Add a runtime test that exercises both object and global this binding through the asm Call fast path.
2026-04-14 04:56:33 -03:00
builder.result.tla_shared_data->update_asm_call_metadata();
LibJS: Cache JS-to-JS inline call eligibility Store whether a function can participate in JS-to-JS inline calls on SharedFunctionInstanceData instead of recomputing the function kind, class-constructor bit, and bytecode availability at each fast-path call site.
2026-04-13 08:43:55 -03:00
builder.result.tla_shared_data->set_executable(tla_exec);
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
} else {
builder.result.executable = static_cast<Bytecode::Executable*>(exec_ptr);
}
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: 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
return builder.result;
}
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
Optional<Result<ModuleResult, Vector<ParserError>>> materialize_bytecode_cache_module(DecodedBytecodeCache& bytecode_cache, NonnullRefPtr<SourceCode const> source_code, Realm& realm)
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
{
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
auto* blob = bytecode_cache.create_materialization_handle();
VERIFY(blob);
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
GC::DeferGC defer_gc(realm.vm().heap());
LibJS: Avoid revalidating cached bytecode executables Cache blobs already validate decoded bytecode before rebuilding C++ Bytecode::Executable objects. Keep that as the only cache validation pass and mark the decoded cache state once it completes. Materialization now asserts that cache blobs and lazy cached function records passed through validation before they can be installed or decoded. This keeps the invariant without re-running the same validator from rust_create_executable().
2026-06-03 17:56:24 -03:00
TemporaryChange skip_cache_executable_validation { s_skip_bytecode_validation_for_prevalidated_cache, true };
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
ModuleBuilder builder;
ModuleCallbacks callbacks {
.set_has_top_level_await = module_set_has_top_level_await,
.push_import_entry = module_push_import_entry,
.push_local_export = module_push_local_export,
.push_indirect_export = module_push_indirect_export,
.push_star_export = module_push_star_export,
.push_requested_module = module_push_requested_module,
.set_default_export_binding = module_set_default_export_binding,
.push_var_name = module_push_var_name,
.push_function = module_push_function,
.push_lexical_binding = module_push_lexical_binding,
};
void* tla_executable = nullptr;
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
void* exec_ptr = rust_materialize_bytecode_cache_module(blob, &realm.vm(), source_code.ptr(), source_code->length_in_code_units(), &builder.shared_function_data,
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
&builder, &callbacks, &tla_executable);
if (!exec_ptr && !tla_executable)
Libraries: Use UTF-16 for JS-visible runtime strings Produce JS-visible string results as UTF-16 at their source, including numeric formatting, BigInt and BigFraction formatting, URI encoding, console formatting, parser errors, regular expression errors, Intl and Temporal records, LibUnicode locale boundaries, and LibWeb bindings. Handle fractional radix formatting through the UTF-16 builder view.
2026-06-21 14:03:10 -03:00
return Vector<ParserError> { ParserError { "Failed to materialize bytecode cache"_utf16, {} } };
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
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
builder.collect_shared_function_data();
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
if (tla_executable) {
auto& vm = realm.vm();
auto* tla_exec = static_cast<Bytecode::Executable*>(tla_executable);
builder.result.tla_shared_data = vm.heap().allocate<SharedFunctionInstanceData>(
vm, FunctionKind::Async,
"module code with top-level await"_utf16_fly_string,
0, 0, true, false, true,
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<Utf16FlyString> {}, NoSharedFunctionDataList {}, nullptr);
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
builder.result.tla_shared_data->m_is_module_wrapper = true;
builder.result.tla_shared_data->m_uses_this = true;
builder.result.tla_shared_data->m_function_environment_needed = true;
builder.result.tla_shared_data->update_asm_call_metadata();
builder.result.tla_shared_data->set_executable(tla_exec);
} else {
builder.result.executable = static_cast<Bytecode::Executable*>(exec_ptr);
}
return builder.result;
}
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
GC::Ptr<Bytecode::Executable> try_install_bytecode_cache_script(DecodedBytecodeCache& bytecode_cache, NonnullRefPtr<SourceCode const> source_code, Realm& realm, Bytecode::Executable& existing_executable, ReadonlySpan<SharedFunctionInstanceData*> existing_shared_function_data)
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
{
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
auto* blob = bytecode_cache.create_materialization_handle();
VERIFY(blob);
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<void*> existing_shared_function_data_ptrs;
existing_shared_function_data_ptrs.ensure_capacity(existing_shared_function_data.size());
for (auto* function : existing_shared_function_data)
existing_shared_function_data_ptrs.unchecked_append(function);
GC::Root<Bytecode::Executable> executable;
{
GC::DeferGC defer_gc(realm.vm().heap());
LibJS: Avoid revalidating cached bytecode executables Cache blobs already validate decoded bytecode before rebuilding C++ Bytecode::Executable objects. Keep that as the only cache validation pass and mark the decoded cache state once it completes. Materialization now asserts that cache blobs and lazy cached function records passed through validation before they can be installed or decoded. This keeps the invariant without re-running the same validator from rust_create_executable().
2026-06-03 17:56:24 -03:00
TemporaryChange skip_cache_executable_validation { s_skip_bytecode_validation_for_prevalidated_cache, true };
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
executable = static_cast<Bytecode::Executable*>(rust_install_bytecode_cache_script(
blob, &realm.vm(), source_code.ptr(), source_code->length_in_code_units(), &existing_executable,
existing_shared_function_data_ptrs.data(), existing_shared_function_data_ptrs.size()));
}
if (executable)
executable->copy_runtime_caches_from(existing_executable);
return executable.ptr();
}
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
GC::Ref<Bytecode::Executable> install_generated_bytecode_cache_script(DecodedBytecodeCache& bytecode_cache, NonnullRefPtr<SourceCode const> source_code, Realm& realm, Bytecode::Executable& existing_executable, ReadonlySpan<SharedFunctionInstanceData*> existing_shared_function_data)
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
{
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
auto executable = try_install_bytecode_cache_script(bytecode_cache, move(source_code), realm, existing_executable, existing_shared_function_data);
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
VERIFY(executable);
return *executable;
}
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
Optional<ModuleBytecodeCacheInstallResult> try_install_bytecode_cache_module(DecodedBytecodeCache& bytecode_cache, NonnullRefPtr<SourceCode const> source_code, Realm& realm, Bytecode::Executable* existing_executable, ReadonlySpan<SharedFunctionInstanceData*> existing_shared_function_data, SharedFunctionInstanceData* existing_top_level_await_shared_data)
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
{
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
auto* blob = bytecode_cache.create_materialization_handle();
VERIFY(blob);
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<void*> existing_shared_function_data_ptrs;
existing_shared_function_data_ptrs.ensure_capacity(existing_shared_function_data.size());
for (auto* function : existing_shared_function_data)
existing_shared_function_data_ptrs.unchecked_append(function);
GC::DeferGC defer_gc(realm.vm().heap());
LibJS: Avoid revalidating cached bytecode executables Cache blobs already validate decoded bytecode before rebuilding C++ Bytecode::Executable objects. Keep that as the only cache validation pass and mark the decoded cache state once it completes. Materialization now asserts that cache blobs and lazy cached function records passed through validation before they can be installed or decoded. This keeps the invariant without re-running the same validator from rust_create_executable().
2026-06-03 17:56:24 -03:00
TemporaryChange skip_cache_executable_validation { s_skip_bytecode_validation_for_prevalidated_cache, true };
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
void* top_level_await_executable = nullptr;
auto* exec = static_cast<Bytecode::Executable*>(rust_install_bytecode_cache_module(
blob, &realm.vm(), source_code.ptr(), source_code->length_in_code_units(),
existing_executable, existing_shared_function_data_ptrs.data(), existing_shared_function_data_ptrs.size(),
existing_top_level_await_shared_data, &top_level_await_executable));
if (!exec && !top_level_await_executable)
return {};
ModuleBytecodeCacheInstallResult result;
if (exec) {
if (existing_executable)
exec->copy_runtime_caches_from(*existing_executable);
result.executable = exec;
}
if (top_level_await_executable) {
auto* executable = static_cast<Bytecode::Executable*>(top_level_await_executable);
if (existing_top_level_await_shared_data && existing_top_level_await_shared_data->m_executable)
executable->copy_runtime_caches_from(*existing_top_level_await_shared_data->m_executable);
result.top_level_await_executable = executable;
}
return result;
}
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
ModuleBytecodeCacheInstallResult install_generated_bytecode_cache_module(DecodedBytecodeCache& bytecode_cache, NonnullRefPtr<SourceCode const> source_code, Realm& realm, Bytecode::Executable* existing_executable, ReadonlySpan<SharedFunctionInstanceData*> existing_shared_function_data, SharedFunctionInstanceData* existing_top_level_await_shared_data)
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
{
LibWeb+LibJS: Cache decoded JS bytecode sidecars Add a ref-counted decoded bytecode cache backing so bytecode cache materialization can create fresh script or module records from a shared decoded sidecar without passing around one-shot raw blob ownership. Keep that backing in ExecutableBacking for records materialized from bytecode cache sidecars, so the immutable decoded data stays alive for as long as the installed record needs it. Cover the shared backing path with a bytecode-cache test that materializes and runs two scripts from one decoded backing.
2026-05-28 14:09:12 -03:00
auto result = try_install_bytecode_cache_module(bytecode_cache, move(source_code), realm, existing_executable, existing_shared_function_data, existing_top_level_await_shared_data);
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
VERIFY(result.has_value());
return result.release_value();
}
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
Optional<Result<ModuleResult, Vector<ParserError>>> compile_module(Utf16View source_text, Realm& realm, Utf16View display_filename)
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
{
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
auto source_code = SourceCode::create(
Utf16String::from_utf16(display_filename),
Utf16String::from_utf16(source_text));
return compile_module(move(source_code), 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
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
Optional<Result<ModuleResult, Vector<ParserError>>> compile_module(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
auto const* source_ptr = source_code->utf16_data();
auto length = source_code->length_in_code_units();
auto* parsed = rust_parse_program(source_ptr, length, static_cast<u8>(ProgramType::Module), 0, g_dump_ast, g_dump_ast_use_color);
LibJS: Remove pipeline comparison infrastructure Remove PipelineComparison.cpp/h and all LIBJS_COMPARE_PIPELINES support from RustIntegration.cpp. This includes: - The compare_pipelines_enabled() function - All comparison blocks in compile_script/eval/module/function - The pair_shared_function_data() helper - The m_cpp_comparison_sfd field on SharedFunctionInstanceData The Rust pipeline has been validated extensively through comparison testing and no longer needs the side-by-side verification harness.
2026-03-19 14:07:57 -03:00
return compile_parsed_module(parsed, source_code, 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
}
Libraries: Use UTF-16 for JS-visible runtime strings Produce JS-visible string results as UTF-16 at their source, including numeric formatting, BigInt and BigFraction formatting, URI encoding, console formatting, parser errors, regular expression errors, Intl and Temporal records, LibUnicode locale boundaries, and LibWeb bindings. Handle fractional radix formatting through the UTF-16 builder view.
2026-06-21 14:03:10 -03:00
Optional<Result<GC::Ref<SharedFunctionInstanceData>, Utf16String>> compile_dynamic_function(
Libraries: Parse JS strings from UTF-16 Thread UTF-16 string input through JSON, script parsing, Date parsing, Intl option parsing, Temporal parsing, and the helper library boundaries that feed those parsers. Preserve ASCII fast paths where the source data is known to be ASCII.
2026-06-21 14:03:06 -03:00
VM& vm, Utf16View source_text, Utf16View parameters_string, Utf16View body_parse_string,
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
FunctionKind kind)
{
Libraries: Parse JS strings from UTF-16 Thread UTF-16 string input through JSON, script parsing, Date parsing, Intl option parsing, Temporal parsing, and the helper library boundaries that feed those parsers. Preserve ASCII fast paths where the source data is known to be ASCII.
2026-06-21 14:03:06 -03:00
auto source_code = SourceCode::create({}, Utf16String::from_utf16(source_text));
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
auto const& code_view = source_code->code_view();
auto full_length = code_view.length_in_code_units();
auto prepare_utf16 = [](Utf16View const& view, Vector<u16>& buf) -> u16 const* {
if (view.has_ascii_storage()) {
auto ascii = view.ascii_span();
buf.ensure_capacity(view.length_in_code_units());
for (size_t i = 0; i < view.length_in_code_units(); ++i)
buf.unchecked_append(static_cast<u16>(ascii[i]));
return buf.data();
}
return reinterpret_cast<u16 const*>(view.utf16_span().data());
};
Vector<u16> full_buf, params_buf, body_buf;
auto const* full_data = prepare_utf16(code_view, full_buf);
Libraries: Parse JS strings from UTF-16 Thread UTF-16 string input through JSON, script parsing, Date parsing, Intl option parsing, Temporal parsing, and the helper library boundaries that feed those parsers. Preserve ASCII fast paths where the source data is known to be ASCII.
2026-06-21 14:03:06 -03:00
auto const* params_data = prepare_utf16(parameters_string, params_buf);
auto const* body_data = prepare_utf16(body_parse_string, body_buf);
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::DeferGC defer_gc(vm.heap());
Libraries: Use UTF-16 for JS-visible runtime strings Produce JS-visible string results as UTF-16 at their source, including numeric formatting, BigInt and BigFraction formatting, URI encoding, console formatting, parser errors, regular expression errors, Intl and Temporal records, LibUnicode locale boundaries, and LibWeb bindings. Handle fractional radix formatting through the UTF-16 builder view.
2026-06-21 14:03:10 -03:00
Utf16String parse_error;
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
void* sfd_ptr = rust_compile_dynamic_function(
full_data, full_length,
Libraries: Parse JS strings from UTF-16 Thread UTF-16 string input through JSON, script parsing, Date parsing, Intl option parsing, Temporal parsing, and the helper library boundaries that feed those parsers. Preserve ASCII fast paths where the source data is known to be ASCII.
2026-06-21 14:03:06 -03:00
params_data, parameters_string.length_in_code_units(),
body_data, body_parse_string.length_in_code_units(),
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, source_code.ptr(),
static_cast<u8>(kind),
&parse_error, collect_single_parse_error,
LibJS: Remove pipeline comparison infrastructure Remove PipelineComparison.cpp/h and all LIBJS_COMPARE_PIPELINES support from RustIntegration.cpp. This includes: - The compare_pipelines_enabled() function - All comparison blocks in compile_script/eval/module/function - The pair_shared_function_data() helper - The m_cpp_comparison_sfd field on SharedFunctionInstanceData The Rust pipeline has been validated extensively through comparison testing and no longer needs the side-by-side verification harness.
2026-03-19 14:07:57 -03:00
nullptr, nullptr);
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: Remove pipeline comparison infrastructure Remove PipelineComparison.cpp/h and all LIBJS_COMPARE_PIPELINES support from RustIntegration.cpp. This includes: - The compare_pipelines_enabled() function - All comparison blocks in compile_script/eval/module/function - The pair_shared_function_data() helper - The m_cpp_comparison_sfd field on SharedFunctionInstanceData The Rust pipeline has been validated extensively through comparison testing and no longer needs the side-by-side verification harness.
2026-03-19 14:07:57 -03:00
if (!sfd_ptr)
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
return parse_error;
auto& function_data = *static_cast<SharedFunctionInstanceData*>(sfd_ptr);
Libraries: Parse JS strings from UTF-16 Thread UTF-16 string input through JSON, script parsing, Date parsing, Intl option parsing, Temporal parsing, and the helper library boundaries that feed those parsers. Preserve ASCII fast paths where the source data is known to be ASCII.
2026-06-21 14:03:06 -03:00
function_data.m_source_text_owner = Utf16String::from_utf16(source_text);
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
return GC::Ref<SharedFunctionInstanceData> { function_data };
}
Optional<Vector<GC::Root<SharedFunctionInstanceData>>> compile_builtin_file(
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
Utf16View script_text, VM& vm)
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
{
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
auto code = SourceCode::create("BuiltinFile"_utf16, Utf16String::from_utf16(script_text));
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
auto const& code_view = code->code_view();
auto length = code_view.length_in_code_units();
LibJS: Defer GC during Rust-pipeline module and builtin compilation The Rust bytecode pipeline stores SharedFunctionInstanceData pointers as raw void pointers invisible to the GC. If garbage collection runs during compilation (triggered by heap allocation of a new SFD), it can collect previously created SFDs, leaving stale pointers that crash during the next GC marking phase. Every other Rust compilation entry point (compile_script, compile_eval, compile_shadow_realm_eval, compile_dynamic_function, compile_function) already uses GC::DeferGC to prevent this. Add the missing DeferGC to compile_module and compile_builtin_file.
2026-02-24 17:52:36 -03:00
GC::DeferGC defer_gc(vm.heap());
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
Vector<GC::Root<SharedFunctionInstanceData>> shared_data_list;
LibJS: Cache ASCII-to-UTF-16 source conversion for Rust compilation The Rust FFI requires UTF-16 source data, so ASCII-stored source code must be widened to UTF-16. Previously, this conversion was done into a temporary buffer on every call to compile_function, meaning the entire source file was converted for each lazily-compiled function. For large modules with many functions, this caused heavy spinning. Move the conversion into SourceCode::utf16_data() which lazily converts and caches the result once per source file. Subsequent compilations of functions from the same file reuse the cached data.
2026-02-24 18:07:27 -03:00
auto const* source_ptr = code->utf16_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
rust_compile_builtin_file(source_ptr, length, &vm, code.ptr(), &shared_data_list, collect_builtin_function,
LibJS: Remove pipeline comparison infrastructure Remove PipelineComparison.cpp/h and all LIBJS_COMPARE_PIPELINES support from RustIntegration.cpp. This includes: - The compare_pipelines_enabled() function - All comparison blocks in compile_script/eval/module/function - The pair_shared_function_data() helper - The m_cpp_comparison_sfd field on SharedFunctionInstanceData The Rust pipeline has been validated extensively through comparison testing and no longer needs the side-by-side verification harness.
2026-03-19 14:07:57 -03:00
nullptr, nullptr);
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
return shared_data_list;
}
GC::Ptr<Bytecode::Executable> compile_function(VM& vm, SharedFunctionInstanceData& shared_data, 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
if (shared_data.m_precompiled_bytecode_executable) {
GC::DeferGC defer_gc(vm.heap());
auto* exec = static_cast<Bytecode::Executable*>(rust_materialize_precompiled_bytecode_function(
shared_data.m_precompiled_bytecode_executable,
&vm,
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
shared_data.m_source_code.ptr(),
shared_data.m_owner_shared_function_data_list));
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
shared_data.m_precompiled_bytecode_executable = nullptr;
return exec;
}
if (shared_data.m_cached_bytecode_executable) {
GC::DeferGC defer_gc(vm.heap());
LibJS: Avoid revalidating cached bytecode executables Cache blobs already validate decoded bytecode before rebuilding C++ Bytecode::Executable objects. Keep that as the only cache validation pass and mark the decoded cache state once it completes. Materialization now asserts that cache blobs and lazy cached function records passed through validation before they can be installed or decoded. This keeps the invariant without re-running the same validator from rust_create_executable().
2026-06-03 17:56:24 -03:00
TemporaryChange skip_cache_executable_validation { s_skip_bytecode_validation_for_prevalidated_cache, true };
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
auto* exec = static_cast<Bytecode::Executable*>(rust_materialize_bytecode_cache_function(
shared_data.m_cached_bytecode_executable,
&vm,
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
shared_data.m_source_code.ptr(),
shared_data.m_owner_shared_function_data_list));
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
shared_data.m_cached_bytecode_executable = nullptr;
return exec;
}
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
if (!shared_data.m_use_rust_compilation)
return nullptr;
VERIFY(shared_data.m_rust_function_ast);
GC::DeferGC defer_gc(vm.heap());
LibJS: Cache ASCII-to-UTF-16 source conversion for Rust compilation The Rust FFI requires UTF-16 source data, so ASCII-stored source code must be widened to UTF-16. Previously, this conversion was done into a temporary buffer on every call to compile_function, meaning the entire source file was converted for each lazily-compiled function. For large modules with many functions, this caused heavy spinning. Move the conversion into SourceCode::utf16_data() which lazily converts and caches the result once per source file. Subsequent compilations of functions from the same file reuse the cached data.
2026-02-24 18:07:27 -03:00
auto const* source_ptr = shared_data.m_source_code->utf16_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
auto* exec = static_cast<Bytecode::Executable*>(rust_compile_function(
&vm,
shared_data.m_source_code.ptr(),
source_ptr,
LibJS: Cache ASCII-to-UTF-16 source conversion for Rust compilation The Rust FFI requires UTF-16 source data, so ASCII-stored source code must be widened to UTF-16. Previously, this conversion was done into a temporary buffer on every call to compile_function, meaning the entire source file was converted for each lazily-compiled function. For large modules with many functions, this caused heavy spinning. Move the conversion into SourceCode::utf16_data() which lazily converts and caches the result once per source file. Subsequent compilations of functions from the same file reuse the cached data.
2026-02-24 18:07:27 -03:00
shared_data.m_source_code->length_in_code_units(),
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
&shared_data,
shared_data.m_rust_function_ast,
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
builtin_abstract_operations_enabled,
shared_data.m_owner_shared_function_data_list));
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
shared_data.m_rust_function_ast = nullptr;
LibJS: Compare Rust and C++ bytecode for lazily compiled functions LIBJS_COMPARE_PIPELINES previously only compared top-level script/eval/module bytecodes. Function bodies are compiled lazily via compile_function(), and that path had no comparison at all. Fix this by pairing each Rust-compiled SharedFunctionInstanceData with its C++ counterpart during top-level compilation. When a function is later lazily compiled, compile_function() runs both pipelines and compares the bytecodes (crashing on mismatch, same as the top-level comparisons). The pairing is done recursively so nested functions are also covered.
2026-03-01 08:13:35 -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
return exec;
}
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
void* clone_function_ast(void const* ast)
{
return rust_clone_function_ast(ast);
}
CompiledFunction* compile_function_off_thread(void* function_ast, size_t length_in_code_units, bool builtin_abstract_operations_enabled)
{
return rust_compile_function_off_thread(function_ast, length_in_code_units, builtin_abstract_operations_enabled);
}
void materialize_compiled_function(CompiledFunction* compiled, VM& vm, SourceCode const& source_code, SharedFunctionInstanceData& shared_data)
{
GC::DeferGC defer_gc(vm.heap());
rust_materialize_compiled_function(compiled, &vm, &source_code, &shared_data);
}
void free_compiled_function(CompiledFunction* compiled)
{
rust_free_compiled_function(compiled);
}
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
void free_cached_bytecode_executable(void* executable)
{
if (executable)
rust_free_cached_bytecode_executable(executable);
}
void free_precompiled_bytecode_executable(void* executable)
{
if (executable)
rust_free_precompiled_bytecode_executable(executable);
}
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
void free_function_ast(void* ast)
{
if (ast)
rust_free_function_ast(ast);
}
}
// --- FFI factory functions (called by Rust to create C++ objects) ---
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 {
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
struct RustCompiledRegex {
LibRegex: Compile ECMAScript patterns from UTF-16 Accept Utf16View patterns at the LibRegex compile boundary and pass UTF-16 or ASCII storage directly into the Rust regex parser. This keeps JavaScript regular expression construction from converting patterns through UTF-8 when LibRegex can consume the same UTF-16 representation used by LibJS. Update RegExp construction, HTML pattern validation, the regex fuzzer, and LibRegex tests to use the UTF-16 compile API.
2026-06-22 08:07:20 -03:00
Utf16String parsed_pattern;
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
};
static Utf16View view_from_ffi(FFIUtf16Slice slice)
{
LibJS: Handle empty UTF-16 strings in Rust FFI Treat zero length UTF-16 slices from Rust as empty views at the FFI boundary instead of assuming a non null backing pointer. Add a regression test which crashed before these changes. Fixes a crash loading github.com/ladybirdbrowser/ladybird.
2026-03-31 13:27:42 -03:00
return JS::RustIntegration::utf16_view_from_bytes(slice.data, slice.length);
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
}
static Utf16String utf16_from_ffi(FFIUtf16Slice slice)
{
return Utf16String::from_utf16(view_from_ffi(slice));
}
static Utf16FlyString utf16_fly_from_ffi(FFIUtf16Slice slice)
{
return Utf16FlyString::from_utf16(view_from_ffi(slice));
}
LibJS: Reuse cached constant buffers when materializing Validate cached constant buffers without decoding them into Rust ConstantValue objects, then pass the bytes to the C++ executable factory. Align string constants in the FFI encoding so fresh and cached buffers use the same layout.
2026-05-18 17:00:24 -03:00
static void align_constant_cursor(uint8_t const* begin, uint8_t const*& cursor, uint8_t const* end, size_t alignment)
{
auto offset = static_cast<size_t>(cursor - begin);
auto aligned_offset = (offset + alignment - 1) & ~(alignment - 1);
VERIFY(aligned_offset <= static_cast<size_t>(end - begin));
cursor = begin + aligned_offset;
}
static bool constant_cursor_is_aligned(uint8_t const* cursor, size_t alignment)
{
return reinterpret_cast<FlatPtr>(cursor) % alignment == 0;
}
static JS::Value decode_constant(JS::VM& vm, uint8_t const* begin, uint8_t const*& cursor, uint8_t const* end)
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
{
VERIFY(cursor < end);
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
auto const tag = *cursor++;
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: 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
switch (static_cast<ConstantTag>(tag)) {
case ConstantTag::Number: {
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
VERIFY(cursor + 8 <= end);
double value;
memcpy(&value, cursor, 8);
cursor += 8;
return JS::Value(value);
}
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
case ConstantTag::BooleanTrue:
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
return JS::Value(true);
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
case ConstantTag::BooleanFalse:
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
return JS::Value(false);
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
case ConstantTag::Null:
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
return JS::js_null();
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
case ConstantTag::Undefined:
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
return JS::js_undefined();
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
case ConstantTag::Empty:
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
return JS::js_special_empty_value();
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
case ConstantTag::String: {
LibJS: Reuse cached constant buffers when materializing Validate cached constant buffers without decoding them into Rust ConstantValue objects, then pass the bytes to the C++ executable factory. Align string constants in the FFI encoding so fresh and cached buffers use the same layout.
2026-05-18 17:00:24 -03:00
align_constant_cursor(begin, cursor, end, alignof(char16_t));
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
VERIFY(cursor + 4 <= end);
uint32_t len;
memcpy(&len, cursor, 4);
cursor += 4;
LibJS: Reuse cached constant buffers when materializing Validate cached constant buffers without decoding them into Rust ConstantValue objects, then pass the bytes to the C++ executable factory. Align string constants in the FFI encoding so fresh and cached buffers use the same layout.
2026-05-18 17:00:24 -03:00
VERIFY(len <= static_cast<size_t>(end - cursor) / sizeof(char16_t));
LibJS: Avoid constructing Utf16View with a null pointer for empty string When decoding a zero length string, we would pass through the (null) data() of an empty Vector to the Utf16View constructor. Return an empty PrimitiveString early instead.
2026-03-30 20:58:04 -03:00
if (len == 0)
return JS::PrimitiveString::create(vm, Utf16String {});
LibJS: Reuse cached constant buffers when materializing Validate cached constant buffers without decoding them into Rust ConstantValue objects, then pass the bytes to the C++ executable factory. Align string constants in the FFI encoding so fresh and cached buffers use the same layout.
2026-05-18 17:00:24 -03:00
auto string_byte_length = static_cast<size_t>(len) * sizeof(char16_t);
auto str = [&] {
if (constant_cursor_is_aligned(cursor, alignof(char16_t)))
return Utf16String::from_utf16(Utf16View(reinterpret_cast<char16_t const*>(cursor), len));
Vector<char16_t> code_units;
code_units.resize(len);
memcpy(code_units.data(), cursor, string_byte_length);
return Utf16String::from_utf16(Utf16View(code_units.data(), len));
}();
cursor += string_byte_length;
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
return JS::PrimitiveString::create(vm, move(str));
}
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
case ConstantTag::BigInt: {
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
VERIFY(cursor + 4 <= end);
uint32_t len;
memcpy(&len, cursor, 4);
cursor += 4;
VERIFY(cursor + len <= end);
auto ascii = StringView(reinterpret_cast<char const*>(cursor), len);
cursor += len;
auto integer = [&] {
if (len >= 3 && ascii[0] == '0') {
if (ascii[1] == 'x' || ascii[1] == 'X')
return MUST(Crypto::SignedBigInteger::from_base(16, ascii.substring_view(2)));
if (ascii[1] == 'o' || ascii[1] == 'O')
return MUST(Crypto::SignedBigInteger::from_base(8, ascii.substring_view(2)));
if (ascii[1] == 'b' || ascii[1] == 'B')
return MUST(Crypto::SignedBigInteger::from_base(2, ascii.substring_view(2)));
}
return MUST(Crypto::SignedBigInteger::from_base(10, ascii));
}();
return JS::BigInt::create(vm, move(integer));
}
LibJS: Resolve VM constants during executable creation Rust bytecode generation still reached into the VM to encode well-known symbols and intrinsic abstract-operation functions as raw JS::Value constants. That is not compatible with running top-level code generation away from the main thread. Keep those constants symbolic in the Rust constant pool instead. The C++ Executable materialization step now resolves them into real VM values while it is already decoding the rest of the constant table on the main thread. This removes another VM dependency from Rust bytecode emission without changing when the resulting constants become visible to the bytecode interpreter.
2026-04-26 09:30:50 -03:00
case ConstantTag::WellKnownSymbol: {
VERIFY(cursor + 1 <= end);
auto symbol_id = static_cast<WellKnownSymbolKind>(*cursor++);
switch (symbol_id) {
case WellKnownSymbolKind::SymbolIterator:
return vm.well_known_symbol_iterator();
case WellKnownSymbolKind::SymbolAsyncIterator:
return vm.well_known_symbol_async_iterator();
default:
VERIFY_NOT_REACHED();
}
}
case ConstantTag::AbstractOperation: {
VERIFY(cursor + 1 <= end);
auto operation = static_cast<AbstractOperationKind>(*cursor++);
auto& intrinsics = vm.current_realm()->intrinsics();
switch (operation) {
case AbstractOperationKind::AsyncIteratorClose:
return JS::Value(intrinsics.async_iterator_close_abstract_operation_function().ptr());
case AbstractOperationKind::GetMethod:
return JS::Value(intrinsics.get_method_abstract_operation_function().ptr());
case AbstractOperationKind::GetIteratorDirect:
return JS::Value(intrinsics.get_iterator_direct_abstract_operation_function().ptr());
case AbstractOperationKind::GetIteratorFromMethod:
return JS::Value(intrinsics.get_iterator_from_method_abstract_operation_function().ptr());
case AbstractOperationKind::IteratorComplete:
return JS::Value(intrinsics.iterator_complete_abstract_operation_function().ptr());
}
VERIFY_NOT_REACHED();
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
}
default:
VERIFY_NOT_REACHED();
}
}
extern "C" void* rust_create_executable(
void* vm_ptr,
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
void const* source_code_ptr,
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
FFIExecutableData const* data)
{
auto& vm = *static_cast<JS::VM*>(vm_ptr);
auto& source_code = *static_cast<JS::SourceCode const*>(source_code_ptr);
LibJS: Keep cached bytecode file-backed Teach Bytecode::Executable to store its instruction stream as either an owned Vector or a retained Core::ImmutableBytes range. Cached bytecode materialization now clones the immutable blob owner and lets the executable point directly into the file-backed cache blob instead of copying instruction bytes back onto the heap. Keep a cached instruction data pointer inside the stream wrapper so the asm interpreter still has a direct hot-path load. Align executable bytecode payloads in the cache format so mmap-backed instruction streams satisfy validator and interpreter alignment requirements.
2026-05-18 08:29:29 -03:00
auto bytecode = [&] {
if (data->bytecode_owner) {
auto bytecode_owner = adopt_own_if_nonnull(static_cast<Core::ImmutableBytes*>(data->bytecode_owner));
VERIFY(bytecode_owner);
auto bytes = bytecode_owner->bytes();
size_t offset = 0;
if (!bytes.is_empty()) {
VERIFY(data->bytecode >= bytes.data());
offset = static_cast<size_t>(data->bytecode - bytes.data());
}
VERIFY(data->bytecode_length <= bytes.size());
VERIFY(offset <= bytes.size() - data->bytecode_length);
return JS::Bytecode::InstructionStream { move(*bytecode_owner), offset, data->bytecode_length };
}
Vector<u8> bytecode_vec;
bytecode_vec.append(data->bytecode, data->bytecode_length);
return JS::Bytecode::InstructionStream { move(bytecode_vec) };
}();
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
// Build identifier table
auto ident_table = make<JS::Bytecode::IdentifierTable>();
LibJS: Pre-size bytecode materialization tables Reserve bytecode tables and executable vectors from FFI counts before filling them during Rust bytecode materialization. This avoids repeated growth for data whose final size is already known.
2026-05-18 16:49:28 -03:00
ident_table->ensure_capacity(data->identifier_count);
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
for (size_t i = 0; i < data->identifier_count; ++i) {
ident_table->insert(utf16_fly_from_ffi(data->identifier_table[i]));
}
// Build property key table
auto prop_key_table = make<JS::Bytecode::PropertyKeyTable>();
LibJS: Pre-size bytecode materialization tables Reserve bytecode tables and executable vectors from FFI counts before filling them during Rust bytecode materialization. This avoids repeated growth for data whose final size is already known.
2026-05-18 16:49:28 -03:00
prop_key_table->ensure_capacity(data->property_key_count);
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
for (size_t i = 0; i < data->property_key_count; ++i) {
prop_key_table->insert(utf16_fly_from_ffi(data->property_key_table[i]));
}
// Build string table
auto str_table = make<JS::Bytecode::StringTable>();
LibJS: Pre-size bytecode materialization tables Reserve bytecode tables and executable vectors from FFI counts before filling them during Rust bytecode materialization. This avoids repeated growth for data whose final size is already known.
2026-05-18 16:49:28 -03:00
str_table->ensure_capacity(data->string_count);
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
for (size_t i = 0; i < data->string_count; ++i) {
str_table->insert(utf16_from_ffi(data->string_table[i]));
}
LibJS+LibRegex: Switch RegExp over to the Rust engine Switch LibJS `RegExp` over to the Rust-backed `ECMAScriptRegex` APIs. Route `new RegExp()`, regex literals, and the RegExp builtins through the new compile and exec APIs, and stop re-validating patterns with the deleted C++ parser on the way in. Preserve the observable error behavior by carrying structured compile errors and backtracking-limit failures across the FFI boundary. Cache compiled regex state and named capture metadata on `RegExpObject` in the new representation. Use the new API surface to simplify and speed up the builtin paths too: share `exec_internal`, cache compiled regex pointers, keep the legacy RegExp statics lazy, run global replace through batch `find_all`, and optimize replace, test, split, and String helper paths. Add regression tests for those JavaScript-visible paths.
2026-03-25 06:52:40 -03:00
// Build regex table from pre-compiled regex objects.
// NB: The regex table is no longer read at runtime (new_regexp uses pattern+flags directly),
// but we still need to iterate and free the RustCompiledRegex objects.
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
auto regex_tbl = make<JS::Bytecode::RegexTable>();
for (size_t i = 0; i < data->regex_count; ++i) {
auto* cr = static_cast<RustCompiledRegex*>(data->compiled_regexes[i]);
delete cr;
}
// Decode constants
Vector<JS::Value> constants_vec;
constants_vec.ensure_capacity(data->constants_count);
auto const* cursor = data->constants_data;
auto const* end = data->constants_data + data->constants_data_length;
for (size_t i = 0; i < data->constants_count; ++i) {
LibJS: Reuse cached constant buffers when materializing Validate cached constant buffers without decoding them into Rust ConstantValue objects, then pass the bytes to the C++ executable factory. Align string constants in the FFI encoding so fresh and cached buffers use the same layout.
2026-05-18 17:00:24 -03:00
constants_vec.append(decode_constant(vm, data->constants_data, cursor, end));
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
}
VERIFY(cursor == end);
// Create executable
auto executable = vm.heap().allocate<JS::Bytecode::Executable>(
LibJS: Keep cached bytecode file-backed Teach Bytecode::Executable to store its instruction stream as either an owned Vector or a retained Core::ImmutableBytes range. Cached bytecode materialization now clones the immutable blob owner and lets the executable point directly into the file-backed cache blob instead of copying instruction bytes back onto the heap. Keep a cached instruction data pointer inside the stream wrapper so the asm interpreter still has a direct hot-path load. Align executable bytecode payloads in the cache format so mmap-backed instruction streams satisfy validator and interpreter alignment requirements.
2026-05-18 08:29:29 -03:00
move(bytecode),
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
move(ident_table),
move(prop_key_table),
move(str_table),
move(regex_tbl),
move(constants_vec),
source_code,
data->property_lookup_cache_count,
data->global_variable_cache_count,
LibJS: Cache dynamic environment coordinates Dynamic environment binding opcodes lost the old coordinate warmup. They were split away from the static coordinate opcodes. Hot closures and eval-sensitive functions then resolved the same binding by name on every execution, which regressed JS benchmark throughput badly. Give each dynamic environment opcode a per-executable coordinate cache slot. The cache keeps the bytecode stream immutable while letting both interpreters take a direct declarative environment fast path after the first lookup. Keep the existing eval invalidation behavior and only warm caches for declarative-only chains so with environments continue to observe object shadowing. Reject cached bytecode that uses the no-cache sentinel for dynamic environment coordinate cache operands, since execution indexes those cache arrays unconditionally. Rebaseline bytecode expectations for the instruction size changes. Add coverage for with-object shadowing across repeated dynamic lookups and for rejecting corrupt dynamic environment cache indices.
2026-05-19 06:22:33 -03:00
data->environment_coordinate_cache_count,
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
data->template_object_cache_count,
data->object_shape_cache_count,
LibJS: Cache stable for-in iteration at bytecode sites Cache the flattened enumerable key snapshot for each `for..in` site and reuse a `PropertyNameIterator` when the receiver shape, dictionary generation, indexed storage kind and length, prototype chain validity, and magical-length state still match. Handle packed indexed receivers as well as plain named-property objects. Teach `ObjectPropertyIteratorNext` in `asmint.asm` to return cached property values directly and to fall back to the slow iterator logic when any guard fails. Treat arrays' hidden non-enumerable `length` property as a visited name for for-in shadowing, and include the receiver's magical-length state in the cache key so arrays and plain objects do not share snapshots. Add `test-js` and `test-js-bytecode` coverage for mixed numeric and named keys, packed receiver transitions, re-entry, iterator reuse, GC retention, array length shadowing, and same-site cache reuse.
2026-04-09 19:56:49 -03:00
data->object_property_iterator_cache_count,
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
data->number_of_registers,
data->is_strict ? JS::Strict::Yes : JS::Strict::No);
// Set exception handlers
LibJS: Pre-size bytecode materialization tables Reserve bytecode tables and executable vectors from FFI counts before filling them during Rust bytecode materialization. This avoids repeated growth for data whose final size is already known.
2026-05-18 16:49:28 -03:00
executable->exception_handlers.ensure_capacity(data->exception_handler_count);
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
for (size_t i = 0; i < data->exception_handler_count; ++i) {
executable->exception_handlers.append({
data->exception_handlers[i].start_offset,
data->exception_handlers[i].end_offset,
data->exception_handlers[i].handler_offset,
});
}
// Set source map
LibJS: Pre-size bytecode materialization tables Reserve bytecode tables and executable vectors from FFI counts before filling them during Rust bytecode materialization. This avoids repeated growth for data whose final size is already known.
2026-05-18 16:49:28 -03:00
executable->source_map.ensure_capacity(data->source_map_count);
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
for (size_t i = 0; i < data->source_map_count; ++i) {
executable->source_map.append({
data->source_map[i].bytecode_offset,
LibJS: Drop source ranges from bytecode source maps Store source map locations as bytecode offset, line, and column. Runtime consumers only emit the start line and column, so source end positions and source text offsets do not need to be carried through Executable source maps, bytecode cache serialization, or the Rust FFI. Keep SourceCode's internal position cache able to track source text offsets so callers can still translate source offsets to line and column pairs when needed. Hash dump-bytecode IDs from the name, first source position, and bytecode size instead of source slices that need end offsets. Bump the bytecode cache format version for the slimmer serialized source map entry shape.
2026-05-14 03:29:39 -03:00
data->source_map[i].source_start_line,
data->source_map[i].source_start_column,
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: Stop persisting basic_block_start_offsets on Executable Keep basic block offsets as construction-only metadata rather than storing them on every Executable. The validator now receives the offsets through a transient Rust FFI span, and the bytecode dump rebuilds block starts by scanning labels, terminators, and exception handler metadata. Drop the table from the bytecode cache format and bump the format version so old caches are rebuilt. This removes a field that was only used by validation and bytecode dump paths.
2026-05-13 15:36:54 -03:00
// Keep basic block offsets transient. They are only needed by the
// validator while this Executable is being constructed.
Vector<u32> basic_block_offsets;
basic_block_offsets.ensure_capacity(data->basic_block_count);
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
for (size_t i = 0; i < data->basic_block_count; ++i) {
LibJS: Stop persisting basic_block_start_offsets on Executable Keep basic block offsets as construction-only metadata rather than storing them on every Executable. The validator now receives the offsets through a transient Rust FFI span, and the bytecode dump rebuilds block starts by scanning labels, terminators, and exception handler metadata. Drop the table from the bytecode cache format and bump the format version so old caches are rebuilt. This removes a field that was only used by validation and bytecode dump paths.
2026-05-13 15:36:54 -03:00
VERIFY(data->basic_block_offsets[i] <= NumericLimits<u32>::max());
basic_block_offsets.append(static_cast<u32>(data->basic_block_offsets[i]));
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
}
// Set local variable names
LibJS: Pre-size bytecode materialization tables Reserve bytecode tables and executable vectors from FFI counts before filling them during Rust bytecode materialization. This avoids repeated growth for data whose final size is already known.
2026-05-18 16:49:28 -03:00
executable->local_variable_names.ensure_capacity(data->local_variable_count);
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
for (size_t i = 0; i < data->local_variable_count; ++i) {
LibJS: Remove unused C++ local variable wrapper The Rust bytecode generator only passes local variable names to C++ now, and no C++ code observes declaration kind metadata from LocalVariable. Store local names directly as Utf16FlyString values and remove the stale C++ wrapper type.
2026-06-14 16:09:41 -03:00
executable->local_variable_names.append(utf16_fly_from_ffi(data->local_variable_names[i]));
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
}
// Set layout indices
executable->local_index_base = data->number_of_registers;
executable->argument_index_base = data->number_of_registers + data->local_variable_count + data->constants_count;
executable->registers_and_locals_count = data->number_of_registers + data->local_variable_count;
executable->registers_and_locals_and_constants_count = data->number_of_registers + data->local_variable_count + data->constants_count;
LibJS: Tighten the bytecode validator's argument operand bound Until now the validator passed `u32::MAX` as the argument-region upper bound because nothing on Executable tracked how many argument slots a given bytecode buffer might reference. That left the largest validation hole open: any flat operand index above `registers + locals + constants` slid through the check. The Rust assembler already walks every operand during phase 1 so it can offset each one into the runtime's flat layout. This commit piggybacks on that walk to record the highest `Operand::argument` index touched and surfaces `(max + 1)` (or zero if no argument is ever referenced) on `AssembledBytecode`. The value rides through `FFIExecutableData` onto a new `Executable::number_of_arguments` field, which `Validator.cpp` then feeds into `FFIValidatorBounds`. The bound is now tight: every operand index in the encoded stream is range-checked against the actual runtime array size, including the argument region.
2026-05-02 05:49:32 -03:00
executable->number_of_arguments = data->number_of_arguments;
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
// Set length identifier (for GetLength optimization)
if (data->length_identifier.has_value)
executable->length_identifier = JS::Bytecode::PropertyKeyTableIndex(data->length_identifier.value);
// Set shared function data (inner function definitions)
LibJS: Pre-size bytecode materialization tables Reserve bytecode tables and executable vectors from FFI counts before filling them during Rust bytecode materialization. This avoids repeated growth for data whose final size is already known.
2026-05-18 16:49:28 -03:00
executable->shared_function_data.ensure_capacity(data->shared_function_data_count);
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
for (size_t i = 0; i < data->shared_function_data_count; ++i) {
auto* sfd = const_cast<JS::SharedFunctionInstanceData*>(
static_cast<JS::SharedFunctionInstanceData const*>(data->shared_function_data[i]));
executable->shared_function_data.append(sfd);
}
// Set class blueprints (move from heap-allocated objects)
LibJS: Pre-size bytecode materialization tables Reserve bytecode tables and executable vectors from FFI counts before filling them during Rust bytecode materialization. This avoids repeated growth for data whose final size is already known.
2026-05-18 16:49:28 -03:00
executable->class_blueprints.ensure_capacity(data->class_blueprint_count);
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
for (size_t i = 0; i < data->class_blueprint_count; ++i) {
auto* bp = static_cast<JS::Bytecode::ClassBlueprint*>(data->class_blueprints[i]);
executable->class_blueprints.append(move(*bp));
delete bp;
}
LibJS: Add bytecode validator scaffolding driven from Bytecode.def The plan is to start caching compiled JS bytecode on disk. Before loading anything from a cache we need confidence that the bytes are structurally well-formed, since a corrupted or tampered-with cache file could otherwise hand the interpreter an out-of-bounds jump or a constant-pool index that points past the end of the table. This commit lays down the scaffolding for that validator. The walker lives in Rust (Libraries/LibJS/Rust/src/bytecode/validator.rs) so that it can share the existing Bytecode.def-driven layout machinery with the encoder. C++ calls into it through cbindgen, the same way the rest of the Rust pipeline is wired up. For now, the validator only does Pass 1: walk the byte stream, verify each instruction is 8-byte aligned, the opcode byte is in range, and the reported length keeps us inside the buffer. The length lookup is generated from Bytecode.def so fixed-length and variable-length instructions stay in sync with the rest of the codegen automatically. Per-field bounds checks (operands, labels, table indices, cache indices) and structural extras (basic block offsets, exception handlers, source map) come in follow-up commits. The validator runs after every successful compilation in debug and sanitizer builds, gated on !NDEBUG || HAS_ADDRESS_SANITIZER, so we get an extra sanity check on every executable the encoder produces without paying for it in release builds. Failure trips a VERIFY_NOT_REACHED with the offset, opcode, and error category logged via dbgln().
2026-05-02 04:49:32 -03:00
#if !defined(NDEBUG) || defined(HAS_ADDRESS_SANITIZER)
LibJS: Avoid revalidating cached bytecode executables Cache blobs already validate decoded bytecode before rebuilding C++ Bytecode::Executable objects. Keep that as the only cache validation pass and mark the decoded cache state once it completes. Materialization now asserts that cache blobs and lazy cached function records passed through validation before they can be installed or decoded. This keeps the invariant without re-running the same validator from rust_create_executable().
2026-06-03 17:56:24 -03:00
auto const should_validate_bytecode = !JS::RustIntegration::s_skip_bytecode_validation_for_prevalidated_cache;
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
#else
LibJS: Avoid revalidating cached bytecode executables Cache blobs already validate decoded bytecode before rebuilding C++ Bytecode::Executable objects. Keep that as the only cache validation pass and mark the decoded cache state once it completes. Materialization now asserts that cache blobs and lazy cached function records passed through validation before they can be installed or decoded. This keeps the invariant without re-running the same validator from rust_create_executable().
2026-06-03 17:56:24 -03:00
auto const should_validate_bytecode = false;
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
#endif
if (should_validate_bytecode) {
LibJS: Store bytecode cache indexes instead of pointers Store compact cache indexes in bytecode instructions instead of raw pointers to the executable cache vectors. This keeps the instruction stream independent from heap addresses and removes pointer fixups when materializing cached bytecode. Resolve the mutable cache pointers at execution time from the current Executable. Bytecode test expectations are updated for the smaller cache operands and resulting instruction offsets.
2026-05-18 08:26:41 -03:00
if (auto validation = JS::Bytecode::validate_bytecode(*executable, basic_block_offsets.span()); validation.is_error()) {
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
#if !defined(NDEBUG) || defined(HAS_ADDRESS_SANITIZER)
VERIFY_NOT_REACHED();
#else
return nullptr;
LibJS: Add bytecode validator scaffolding driven from Bytecode.def The plan is to start caching compiled JS bytecode on disk. Before loading anything from a cache we need confidence that the bytes are structurally well-formed, since a corrupted or tampered-with cache file could otherwise hand the interpreter an out-of-bounds jump or a constant-pool index that points past the end of the table. This commit lays down the scaffolding for that validator. The walker lives in Rust (Libraries/LibJS/Rust/src/bytecode/validator.rs) so that it can share the existing Bytecode.def-driven layout machinery with the encoder. C++ calls into it through cbindgen, the same way the rest of the Rust pipeline is wired up. For now, the validator only does Pass 1: walk the byte stream, verify each instruction is 8-byte aligned, the opcode byte is in range, and the reported length keeps us inside the buffer. The length lookup is generated from Bytecode.def so fixed-length and variable-length instructions stay in sync with the rest of the codegen automatically. Per-field bounds checks (operands, labels, table indices, cache indices) and structural extras (basic block offsets, exception handlers, source map) come in follow-up commits. The validator runs after every successful compilation in debug and sanitizer builds, gated on !NDEBUG || HAS_ADDRESS_SANITIZER, so we get an extra sanity check on every executable the encoder produces without paying for it in release builds. Failure trips a VERIFY_NOT_REACHED with the offset, opcode, and error category logged via dbgln().
2026-05-02 04:49:32 -03:00
#endif
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
}
}
LibJS: Add bytecode validator scaffolding driven from Bytecode.def The plan is to start caching compiled JS bytecode on disk. Before loading anything from a cache we need confidence that the bytes are structurally well-formed, since a corrupted or tampered-with cache file could otherwise hand the interpreter an out-of-bounds jump or a constant-pool index that points past the end of the table. This commit lays down the scaffolding for that validator. The walker lives in Rust (Libraries/LibJS/Rust/src/bytecode/validator.rs) so that it can share the existing Bytecode.def-driven layout machinery with the encoder. C++ calls into it through cbindgen, the same way the rest of the Rust pipeline is wired up. For now, the validator only does Pass 1: walk the byte stream, verify each instruction is 8-byte aligned, the opcode byte is in range, and the reported length keeps us inside the buffer. The length lookup is generated from Bytecode.def so fixed-length and variable-length instructions stay in sync with the rest of the codegen automatically. Per-field bounds checks (operands, labels, table indices, cache indices) and structural extras (basic block offsets, exception handlers, source map) come in follow-up commits. The validator runs after every successful compilation in debug and sanitizer builds, gated on !NDEBUG || HAS_ADDRESS_SANITIZER, so we get an extra sanity check on every executable the encoder produces without paying for it in release builds. Failure trips a VERIFY_NOT_REACHED with the offset, opcode, and error category logged via dbgln().
2026-05-02 04:49:32 -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
return executable.ptr();
}
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
template<typename SharedFunctionDataList>
static GC::Ref<JS::SharedFunctionInstanceData> create_shared_function_instance_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
void* vm_ptr,
void const* source_code_ptr,
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
FFISharedFunctionData const* data,
SharedFunctionDataList&& shared_function_data_list)
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
{
auto& vm = *static_cast<JS::VM*>(vm_ptr);
auto& source_code = *static_cast<JS::SourceCode const*>(source_code_ptr);
auto fn_name = data->name_len > 0
? Utf16FlyString::from_utf16(Utf16View(reinterpret_cast<char16_t const*>(data->name), data->name_len))
: Utf16FlyString {};
Vector<Utf16FlyString> mapped_param_names;
if (data->has_simple_parameter_list) {
mapped_param_names.ensure_capacity(data->parameter_name_count);
for (size_t i = 0; i < data->parameter_name_count; ++i)
mapped_param_names.append(utf16_fly_from_ffi(data->parameter_names[i]));
}
auto shared = vm.heap().allocate<JS::SharedFunctionInstanceData>(
vm,
static_cast<JS::FunctionKind>(data->function_kind),
move(fn_name),
data->function_length,
data->formal_parameter_count,
data->strict,
data->is_arrow,
data->has_simple_parameter_list,
move(mapped_param_names),
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
forward<SharedFunctionDataList>(shared_function_data_list),
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
data->rust_function_ast);
// Set parsing insights that must be available before lazy compilation.
shared->m_uses_this = data->uses_this;
LibJS: Avoid function envs for lexical-this arrows Track whether a function needs environment-backed this resolution separately from whether it needs to allocate its own function environment. Arrow functions that only capture lexical this can now resolve through the outer environment without allocating an empty function environment for every call. Keep the asm Call path conservative by routing functions that still need lexical-this resolution through the C++ inline-call helper, so the call receiver is not cached as the arrow function's this value. Microbenchmark: function makeLexicalThisArrow() { return () => this.value; } let object = { value: 1, makeLexicalThisArrow }; let fn = object.makeLexicalThisArrow(); for (let i = 0; i < 20_000_000; ++i) fn(); Measured with the same Release build toggling this patch: baseline: 1069.2 ms mean over 12 runs optimized: 501.2 ms mean over 12 runs speedup: 2.13 times faster
2026-04-30 12:07:49 -03:00
shared->m_this_value_needs_environment_resolution = data->uses_this_from_environment;
if (data->uses_this_from_environment && !data->is_arrow)
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
shared->m_function_environment_needed = true;
LibJS: Pack asm Call shared-data metadata Pack the asm Call fast path metadata next to the executable pointer so the interpreter can fetch both values with one paired load. This removes several dependent shared-data loads from the hot path. Keep the executable pointer and packed metadata in separate registers through this binding so the fast path can still use the paired-load layout after any non-strict this adjustment. Lower the packed metadata flag checks correctly on x86_64 as well. Those bits now live above bit 31, so the generator uses bt for single- bit high masks and covers that path with a unit test. Add a runtime test that exercises both object and global this binding through the asm Call fast path.
2026-04-14 04:56:33 -03:00
shared->update_asm_call_metadata();
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: Keep cached script source text lazy Avoid decoding warm-cache script responses into full UTF-16 SourceCode buffers when a bytecode cache sidecar is available. SourceCode now keeps the original immutable source bytes and source encoding, then decodes only when full source text or a Function.toString() range is requested. Compute the bytecode cache source hash while streaming decoded code points from the response bytes, so cache validation does not force an intermediate UTF-8 string. Function and class source text metadata now stores SourceCode ranges instead of views into a materialized buffer.
2026-05-17 14:54:58 -03:00
shared->set_source_text_range(source_code, data->source_text_offset, data->source_text_length);
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
shared->m_bytecode_cache_source_text_offset = data->source_text_offset;
shared->m_bytecode_cache_source_text_length = data->source_text_length;
shared->m_has_bytecode_cache_source_text_range = true;
return shared;
}
extern "C" void* rust_create_sfd(
void* vm_ptr,
void const* source_code_ptr,
FFISharedFunctionData const* data)
{
return create_shared_function_instance_data(vm_ptr, source_code_ptr, data, JS::NoSharedFunctionDataList {}).ptr();
}
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: 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
extern "C" void* rust_create_sfd_in_list(
void* vm_ptr,
void const* source_code_ptr,
void* shared_function_data_list_ptr,
FFISharedFunctionData const* data)
{
auto& shared_function_data_list = *static_cast<JS::SharedFunctionInstanceDataList*>(shared_function_data_list_ptr);
return create_shared_function_instance_data(vm_ptr, source_code_ptr, data, shared_function_data_list).ptr();
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
}
extern "C" void rust_sfd_set_metadata(
void* sfd_ptr,
bool uses_this,
LibJS: Avoid function envs for lexical-this arrows Track whether a function needs environment-backed this resolution separately from whether it needs to allocate its own function environment. Arrow functions that only capture lexical this can now resolve through the outer environment without allocating an empty function environment for every call. Keep the asm Call path conservative by routing functions that still need lexical-this resolution through the C++ inline-call helper, so the call receiver is not cached as the arrow function's this value. Microbenchmark: function makeLexicalThisArrow() { return () => this.value; } let object = { value: 1, makeLexicalThisArrow }; let fn = object.makeLexicalThisArrow(); for (let i = 0; i < 20_000_000; ++i) fn(); Measured with the same Release build toggling this patch: baseline: 1069.2 ms mean over 12 runs optimized: 501.2 ms mean over 12 runs speedup: 2.13 times faster
2026-04-30 12:07:49 -03:00
bool this_value_needs_environment_resolution,
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 function_environment_needed,
size_t function_environment_bindings_count,
LibJS: Pass var environment binding counts through FFI Thread the var environment binding count through the Rust and C++ SFD metadata helpers wherever the function environment binding count already travels. This lets CreateVariableEnvironment use the cached var environment shape for functions with parameter expressions.
2026-05-18 12:16:40 -03:00
size_t var_environment_bindings_count,
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 might_need_arguments_object,
bool contains_direct_call_to_eval)
{
auto& shared = *static_cast<JS::SharedFunctionInstanceData*>(sfd_ptr);
shared.m_uses_this = uses_this;
LibJS: Avoid function envs for lexical-this arrows Track whether a function needs environment-backed this resolution separately from whether it needs to allocate its own function environment. Arrow functions that only capture lexical this can now resolve through the outer environment without allocating an empty function environment for every call. Keep the asm Call path conservative by routing functions that still need lexical-this resolution through the C++ inline-call helper, so the call receiver is not cached as the arrow function's this value. Microbenchmark: function makeLexicalThisArrow() { return () => this.value; } let object = { value: 1, makeLexicalThisArrow }; let fn = object.makeLexicalThisArrow(); for (let i = 0; i < 20_000_000; ++i) fn(); Measured with the same Release build toggling this patch: baseline: 1069.2 ms mean over 12 runs optimized: 501.2 ms mean over 12 runs speedup: 2.13 times faster
2026-04-30 12:07:49 -03:00
shared.m_this_value_needs_environment_resolution = this_value_needs_environment_resolution;
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
shared.m_function_environment_needed = function_environment_needed;
LibJS: Pack asm Call shared-data metadata Pack the asm Call fast path metadata next to the executable pointer so the interpreter can fetch both values with one paired load. This removes several dependent shared-data loads from the hot path. Keep the executable pointer and packed metadata in separate registers through this binding so the fast path can still use the paired-load layout after any non-strict this adjustment. Lower the packed metadata flag checks correctly on x86_64 as well. Those bits now live above bit 31, so the generator uses bt for single- bit high masks and covers that path with a unit test. Add a runtime test that exercises both object and global this binding through the asm Call fast path.
2026-04-14 04:56:33 -03:00
shared.update_asm_call_metadata();
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
shared.m_function_environment_bindings_count = function_environment_bindings_count;
LibJS: Pass var environment binding counts through FFI Thread the var environment binding count through the Rust and C++ SFD metadata helpers wherever the function environment binding count already travels. This lets CreateVariableEnvironment use the cached var environment shape for functions with parameter expressions.
2026-05-18 12:16:40 -03:00
shared.m_var_environment_bindings_count = var_environment_bindings_count;
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
shared.m_might_need_arguments_object = might_need_arguments_object;
shared.m_contains_direct_call_to_eval = contains_direct_call_to_eval;
}
extern "C" void rust_sfd_set_class_field_initializer_name(
void* sfd_ptr,
uint16_t const* name,
size_t name_len,
bool is_private)
{
auto& shared = *static_cast<JS::SharedFunctionInstanceData*>(sfd_ptr);
LibJS: Handle empty UTF-16 strings in Rust FFI Treat zero length UTF-16 slices from Rust as empty views at the FFI boundary instead of assuming a non null backing pointer. Add a regression test which crashed before these changes. Fixes a crash loading github.com/ladybirdbrowser/ladybird.
2026-03-31 13:27:42 -03:00
auto utf16_name = Utf16FlyString::from_utf16(JS::RustIntegration::utf16_view_from_bytes(name, name_len));
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
if (is_private) {
shared.m_class_field_initializer_name = JS::PrivateName(0, utf16_name);
} else {
shared.m_class_field_initializer_name = JS::PropertyKey(utf16_name.to_utf16_string());
}
}
LibJS: Precompile top-level IIFEs off-thread Mark direct calls to function expressions while generating top-level Rust bytecode, then compile those functions before returning the off-thread compilation result to WebContent. The main thread still performs all VM and GC-backed materialization. It now receives an already assembled executable for each eager IIFE and attaches it to the SharedFunctionInstanceData while creating the parent Executable. Nested functions owned by the eager executable remain lazy. This targets large wrapper IIFEs that are invoked as soon as top-level code starts running. Their bytecode generation now runs on the existing script compilation worker instead of blocking the main thread on first call.
2026-04-26 12:24:25 -03:00
extern "C" void rust_sfd_set_precompiled_executable(
void* sfd_ptr,
void* executable_ptr,
bool uses_this,
LibJS: Avoid function envs for lexical-this arrows Track whether a function needs environment-backed this resolution separately from whether it needs to allocate its own function environment. Arrow functions that only capture lexical this can now resolve through the outer environment without allocating an empty function environment for every call. Keep the asm Call path conservative by routing functions that still need lexical-this resolution through the C++ inline-call helper, so the call receiver is not cached as the arrow function's this value. Microbenchmark: function makeLexicalThisArrow() { return () => this.value; } let object = { value: 1, makeLexicalThisArrow }; let fn = object.makeLexicalThisArrow(); for (let i = 0; i < 20_000_000; ++i) fn(); Measured with the same Release build toggling this patch: baseline: 1069.2 ms mean over 12 runs optimized: 501.2 ms mean over 12 runs speedup: 2.13 times faster
2026-04-30 12:07:49 -03:00
bool this_value_needs_environment_resolution,
LibJS: Precompile top-level IIFEs off-thread Mark direct calls to function expressions while generating top-level Rust bytecode, then compile those functions before returning the off-thread compilation result to WebContent. The main thread still performs all VM and GC-backed materialization. It now receives an already assembled executable for each eager IIFE and attaches it to the SharedFunctionInstanceData while creating the parent Executable. Nested functions owned by the eager executable remain lazy. This targets large wrapper IIFEs that are invoked as soon as top-level code starts running. Their bytecode generation now runs on the existing script compilation worker instead of blocking the main thread on first call.
2026-04-26 12:24:25 -03:00
bool function_environment_needed,
size_t function_environment_bindings_count,
LibJS: Pass var environment binding counts through FFI Thread the var environment binding count through the Rust and C++ SFD metadata helpers wherever the function environment binding count already travels. This lets CreateVariableEnvironment use the cached var environment shape for functions with parameter expressions.
2026-05-18 12:16:40 -03:00
size_t var_environment_bindings_count,
LibJS: Precompile top-level IIFEs off-thread Mark direct calls to function expressions while generating top-level Rust bytecode, then compile those functions before returning the off-thread compilation result to WebContent. The main thread still performs all VM and GC-backed materialization. It now receives an already assembled executable for each eager IIFE and attaches it to the SharedFunctionInstanceData while creating the parent Executable. Nested functions owned by the eager executable remain lazy. This targets large wrapper IIFEs that are invoked as soon as top-level code starts running. Their bytecode generation now runs on the existing script compilation worker instead of blocking the main thread on first call.
2026-04-26 12:24:25 -03:00
bool might_need_arguments_object,
bool contains_direct_call_to_eval)
{
auto& shared = *static_cast<JS::SharedFunctionInstanceData*>(sfd_ptr);
auto& executable = *static_cast<JS::Bytecode::Executable*>(executable_ptr);
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
auto previous_executable = shared.m_executable;
if (previous_executable)
executable.copy_runtime_caches_from(*previous_executable);
LibJS: Precompile top-level IIFEs off-thread Mark direct calls to function expressions while generating top-level Rust bytecode, then compile those functions before returning the off-thread compilation result to WebContent. The main thread still performs all VM and GC-backed materialization. It now receives an already assembled executable for each eager IIFE and attaches it to the SharedFunctionInstanceData while creating the parent Executable. Nested functions owned by the eager executable remain lazy. This targets large wrapper IIFEs that are invoked as soon as top-level code starts running. Their bytecode generation now runs on the existing script compilation worker instead of blocking the main thread on first call.
2026-04-26 12:24:25 -03:00
shared.m_uses_this = uses_this;
LibJS: Avoid function envs for lexical-this arrows Track whether a function needs environment-backed this resolution separately from whether it needs to allocate its own function environment. Arrow functions that only capture lexical this can now resolve through the outer environment without allocating an empty function environment for every call. Keep the asm Call path conservative by routing functions that still need lexical-this resolution through the C++ inline-call helper, so the call receiver is not cached as the arrow function's this value. Microbenchmark: function makeLexicalThisArrow() { return () => this.value; } let object = { value: 1, makeLexicalThisArrow }; let fn = object.makeLexicalThisArrow(); for (let i = 0; i < 20_000_000; ++i) fn(); Measured with the same Release build toggling this patch: baseline: 1069.2 ms mean over 12 runs optimized: 501.2 ms mean over 12 runs speedup: 2.13 times faster
2026-04-30 12:07:49 -03:00
shared.m_this_value_needs_environment_resolution = this_value_needs_environment_resolution;
LibJS: Precompile top-level IIFEs off-thread Mark direct calls to function expressions while generating top-level Rust bytecode, then compile those functions before returning the off-thread compilation result to WebContent. The main thread still performs all VM and GC-backed materialization. It now receives an already assembled executable for each eager IIFE and attaches it to the SharedFunctionInstanceData while creating the parent Executable. Nested functions owned by the eager executable remain lazy. This targets large wrapper IIFEs that are invoked as soon as top-level code starts running. Their bytecode generation now runs on the existing script compilation worker instead of blocking the main thread on first call.
2026-04-26 12:24:25 -03:00
shared.m_function_environment_needed = function_environment_needed;
shared.m_function_environment_bindings_count = function_environment_bindings_count;
LibJS: Pass var environment binding counts through FFI Thread the var environment binding count through the Rust and C++ SFD metadata helpers wherever the function environment binding count already travels. This lets CreateVariableEnvironment use the cached var environment shape for functions with parameter expressions.
2026-05-18 12:16:40 -03:00
shared.m_var_environment_bindings_count = var_environment_bindings_count;
LibJS: Precompile top-level IIFEs off-thread Mark direct calls to function expressions while generating top-level Rust bytecode, then compile those functions before returning the off-thread compilation result to WebContent. The main thread still performs all VM and GC-backed materialization. It now receives an already assembled executable for each eager IIFE and attaches it to the SharedFunctionInstanceData while creating the parent Executable. Nested functions owned by the eager executable remain lazy. This targets large wrapper IIFEs that are invoked as soon as top-level code starts running. Their bytecode generation now runs on the existing script compilation worker instead of blocking the main thread on first call.
2026-04-26 12:24:25 -03:00
shared.m_might_need_arguments_object = might_need_arguments_object;
shared.m_contains_direct_call_to_eval = contains_direct_call_to_eval;
shared.set_executable(executable);
executable.name = shared.m_name;
if (Bytecode::g_dump_bytecode)
executable.dump();
shared.clear_compile_inputs();
}
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
extern "C" void rust_sfd_set_cached_bytecode_executable(
void* sfd_ptr,
void* cached_executable_ptr,
bool uses_this,
bool this_value_needs_environment_resolution,
bool function_environment_needed,
size_t function_environment_bindings_count,
LibJS: Pass var environment binding counts through FFI Thread the var environment binding count through the Rust and C++ SFD metadata helpers wherever the function environment binding count already travels. This lets CreateVariableEnvironment use the cached var environment shape for functions with parameter expressions.
2026-05-18 12:16:40 -03:00
size_t var_environment_bindings_count,
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
bool might_need_arguments_object,
bool contains_direct_call_to_eval)
{
auto& shared = *static_cast<JS::SharedFunctionInstanceData*>(sfd_ptr);
shared.m_uses_this = uses_this;
shared.m_this_value_needs_environment_resolution = this_value_needs_environment_resolution;
shared.m_function_environment_needed = function_environment_needed;
shared.m_function_environment_bindings_count = function_environment_bindings_count;
LibJS: Pass var environment binding counts through FFI Thread the var environment binding count through the Rust and C++ SFD metadata helpers wherever the function environment binding count already travels. This lets CreateVariableEnvironment use the cached var environment shape for functions with parameter expressions.
2026-05-18 12:16:40 -03:00
shared.m_var_environment_bindings_count = var_environment_bindings_count;
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
shared.m_might_need_arguments_object = might_need_arguments_object;
shared.m_contains_direct_call_to_eval = contains_direct_call_to_eval;
shared.m_cached_bytecode_executable = cached_executable_ptr;
shared.update_asm_call_metadata();
}
extern "C" void rust_sfd_set_precompiled_bytecode_executable(
void* sfd_ptr,
void* precompiled_executable_ptr,
bool uses_this,
bool this_value_needs_environment_resolution,
bool function_environment_needed,
size_t function_environment_bindings_count,
LibJS: Pass var environment binding counts through FFI Thread the var environment binding count through the Rust and C++ SFD metadata helpers wherever the function environment binding count already travels. This lets CreateVariableEnvironment use the cached var environment shape for functions with parameter expressions.
2026-05-18 12:16:40 -03:00
size_t var_environment_bindings_count,
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
bool might_need_arguments_object,
bool contains_direct_call_to_eval)
{
auto& shared = *static_cast<JS::SharedFunctionInstanceData*>(sfd_ptr);
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
shared.clear_compile_inputs();
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
shared.m_uses_this = uses_this;
shared.m_this_value_needs_environment_resolution = this_value_needs_environment_resolution;
shared.m_function_environment_needed = function_environment_needed;
shared.m_function_environment_bindings_count = function_environment_bindings_count;
LibJS: Pass var environment binding counts through FFI Thread the var environment binding count through the Rust and C++ SFD metadata helpers wherever the function environment binding count already travels. This lets CreateVariableEnvironment use the cached var environment shape for functions with parameter expressions.
2026-05-18 12:16:40 -03:00
shared.m_var_environment_bindings_count = var_environment_bindings_count;
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
shared.m_might_need_arguments_object = might_need_arguments_object;
shared.m_contains_direct_call_to_eval = contains_direct_call_to_eval;
shared.m_precompiled_bytecode_executable = precompiled_executable_ptr;
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
shared.update_asm_call_metadata();
}
extern "C" size_t rust_executable_shared_function_data_count(void const* executable_ptr)
{
if (!executable_ptr)
return 0;
auto& executable = *static_cast<JS::Bytecode::Executable const*>(executable_ptr);
return executable.shared_function_data.size();
}
extern "C" void* rust_executable_shared_function_data_at(void const* executable_ptr, size_t index)
{
if (!executable_ptr)
return nullptr;
auto& executable = *static_cast<JS::Bytecode::Executable const*>(executable_ptr);
if (index >= executable.shared_function_data.size())
return nullptr;
return executable.shared_function_data[index].ptr();
}
extern "C" void* rust_sfd_executable(void const* sfd_ptr)
{
if (!sfd_ptr)
return nullptr;
auto& shared = *static_cast<JS::SharedFunctionInstanceData const*>(sfd_ptr);
return shared.m_executable.ptr();
}
static size_t bytecode_cache_source_text_offset(JS::SharedFunctionInstanceData const& shared)
{
if (shared.m_has_bytecode_cache_source_text_range)
return shared.m_bytecode_cache_source_text_offset;
return shared.m_source_text_offset;
}
static size_t bytecode_cache_source_text_length(JS::SharedFunctionInstanceData const& shared)
{
if (shared.m_has_bytecode_cache_source_text_range)
return shared.m_bytecode_cache_source_text_length;
return shared.m_source_text_length;
}
extern "C" bool rust_sfd_matches_bytecode_cache_function(void const* sfd_ptr, FFISharedFunctionData const* data)
{
if (!sfd_ptr || !data)
return false;
auto& shared = *static_cast<JS::SharedFunctionInstanceData const*>(sfd_ptr);
return bytecode_cache_source_text_offset(shared) == data->source_text_offset
&& bytecode_cache_source_text_length(shared) == data->source_text_length
&& shared.m_function_length == data->function_length
&& shared.m_formal_parameter_count == data->formal_parameter_count
&& shared.m_kind == static_cast<JS::FunctionKind>(data->function_kind)
&& shared.m_strict == data->strict
&& shared.m_is_arrow_function == data->is_arrow
&& shared.m_has_simple_parameter_list == data->has_simple_parameter_list;
}
extern "C" void rust_sfd_install_bytecode_cache_executable(
void* sfd_ptr,
void* executable_ptr,
bool uses_this,
bool this_value_needs_environment_resolution,
bool function_environment_needed,
size_t function_environment_bindings_count,
size_t var_environment_bindings_count,
bool might_need_arguments_object,
bool contains_direct_call_to_eval)
{
auto& shared = *static_cast<JS::SharedFunctionInstanceData*>(sfd_ptr);
auto& executable = *static_cast<JS::Bytecode::Executable*>(executable_ptr);
auto previous_executable = shared.m_executable;
if (previous_executable)
executable.copy_runtime_caches_from(*previous_executable);
shared.m_uses_this = uses_this;
shared.m_this_value_needs_environment_resolution = this_value_needs_environment_resolution;
shared.m_function_environment_needed = function_environment_needed;
shared.m_function_environment_bindings_count = function_environment_bindings_count;
shared.m_var_environment_bindings_count = var_environment_bindings_count;
shared.m_might_need_arguments_object = might_need_arguments_object;
shared.m_contains_direct_call_to_eval = contains_direct_call_to_eval;
shared.set_executable(executable);
executable.name = shared.m_name;
if (Bytecode::g_dump_bytecode)
executable.dump();
shared.clear_compile_inputs();
}
extern "C" void rust_sfd_install_cached_bytecode_executable(
void* sfd_ptr,
void* cached_executable_ptr,
bool uses_this,
bool this_value_needs_environment_resolution,
bool function_environment_needed,
size_t function_environment_bindings_count,
size_t var_environment_bindings_count,
bool might_need_arguments_object,
bool contains_direct_call_to_eval)
{
auto& shared = *static_cast<JS::SharedFunctionInstanceData*>(sfd_ptr);
shared.clear_compile_inputs();
shared.m_uses_this = uses_this;
shared.m_this_value_needs_environment_resolution = this_value_needs_environment_resolution;
shared.m_function_environment_needed = function_environment_needed;
shared.m_function_environment_bindings_count = function_environment_bindings_count;
shared.m_var_environment_bindings_count = var_environment_bindings_count;
shared.m_might_need_arguments_object = might_need_arguments_object;
shared.m_contains_direct_call_to_eval = contains_direct_call_to_eval;
shared.m_cached_bytecode_executable = cached_executable_ptr;
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
shared.update_asm_call_metadata();
}
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
extern "C" void* rust_create_class_blueprint(
void* vm_ptr,
void const* source_code_ptr,
uint16_t const* name,
size_t name_len,
size_t source_text_offset,
size_t source_text_len,
uint32_t constructor_sfd_index,
bool has_super_class,
bool has_name,
FFIClassElement const* elements,
size_t element_count)
{
auto* blueprint = new JS::Bytecode::ClassBlueprint();
blueprint->constructor_shared_function_data_index = constructor_sfd_index;
blueprint->has_super_class = has_super_class;
blueprint->has_name = has_name;
if (name_len > 0)
LibJS: Handle empty UTF-16 strings in Rust FFI Treat zero length UTF-16 slices from Rust as empty views at the FFI boundary instead of assuming a non null backing pointer. Add a regression test which crashed before these changes. Fixes a crash loading github.com/ladybirdbrowser/ladybird.
2026-03-31 13:27:42 -03:00
blueprint->name = Utf16FlyString::from_utf16(JS::RustIntegration::utf16_view_from_bytes(name, name_len));
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: Keep cached script source text lazy Avoid decoding warm-cache script responses into full UTF-16 SourceCode buffers when a bytecode cache sidecar is available. SourceCode now keeps the original immutable source bytes and source encoding, then decodes only when full source text or a Function.toString() range is requested. Compute the bytecode cache source hash while streaming decoded code points from the response bytes, so cache validation does not force an intermediate UTF-8 string. Function and class source text metadata now stores SourceCode ranges instead of views into a materialized buffer.
2026-05-17 14:54:58 -03:00
blueprint->source_code = static_cast<JS::SourceCode const*>(source_code_ptr);
blueprint->source_text_offset = source_text_offset;
blueprint->source_text_length = source_text_len;
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
for (size_t i = 0; i < element_count; ++i) {
auto const& elem = elements[i];
JS::Bytecode::ClassElementDescriptor desc;
desc.kind = static_cast<JS::Bytecode::ClassElementDescriptor::Kind>(elem.kind);
desc.is_static = elem.is_static;
desc.is_private = elem.is_private;
if (elem.private_identifier_len > 0)
LibJS: Handle empty UTF-16 strings in Rust FFI Treat zero length UTF-16 slices from Rust as empty views at the FFI boundary instead of assuming a non null backing pointer. Add a regression test which crashed before these changes. Fixes a crash loading github.com/ladybirdbrowser/ladybird.
2026-03-31 13:27:42 -03:00
desc.private_identifier = Utf16FlyString::from_utf16(JS::RustIntegration::utf16_view_from_bytes(elem.private_identifier, elem.private_identifier_len));
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
if (elem.shared_function_data_index.has_value)
desc.shared_function_data_index = elem.shared_function_data_index.value;
desc.has_initializer = elem.has_initializer;
switch (elem.literal_value_kind) {
LibJS: Directly use LiteralValueKind enum across FFI boundary
2026-03-18 14:29:57 -03:00
case LiteralValueKind::None:
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
break;
LibJS: Directly use LiteralValueKind enum across FFI boundary
2026-03-18 14:29:57 -03:00
case LiteralValueKind::Number:
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
desc.literal_value = JS::Value(elem.literal_value_number);
break;
LibJS: Directly use LiteralValueKind enum across FFI boundary
2026-03-18 14:29:57 -03:00
case LiteralValueKind::BooleanTrue:
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
desc.literal_value = JS::Value(true);
break;
LibJS: Directly use LiteralValueKind enum across FFI boundary
2026-03-18 14:29:57 -03:00
case LiteralValueKind::BooleanFalse:
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
desc.literal_value = JS::Value(false);
break;
LibJS: Directly use LiteralValueKind enum across FFI boundary
2026-03-18 14:29:57 -03:00
case LiteralValueKind::Null:
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
desc.literal_value = JS::js_null();
break;
LibJS: Directly use LiteralValueKind enum across FFI boundary
2026-03-18 14:29:57 -03:00
case LiteralValueKind::String: {
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
auto& vm = *static_cast<JS::VM*>(vm_ptr);
LibJS: Handle empty UTF-16 strings in Rust FFI Treat zero length UTF-16 slices from Rust as empty views at the FFI boundary instead of assuming a non null backing pointer. Add a regression test which crashed before these changes. Fixes a crash loading github.com/ladybirdbrowser/ladybird.
2026-03-31 13:27:42 -03:00
auto str_view = JS::RustIntegration::utf16_view_from_bytes(elem.literal_value_string, elem.literal_value_string_len);
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
desc.literal_value = JS::Value(JS::PrimitiveString::create(vm, str_view));
break;
}
}
blueprint->elements.append(desc);
}
return blueprint;
}
extern "C" void module_sfd_set_name(
void* sfd_ptr,
uint16_t const* name,
size_t name_len)
{
auto& shared = *static_cast<JS::SharedFunctionInstanceData*>(sfd_ptr);
LibJS: Handle empty UTF-16 strings in Rust FFI Treat zero length UTF-16 slices from Rust as empty views at the FFI boundary instead of assuming a non null backing pointer. Add a regression test which crashed before these changes. Fixes a crash loading github.com/ladybirdbrowser/ladybird.
2026-03-31 13:27:42 -03:00
shared.m_name = Utf16FlyString::from_utf16(JS::RustIntegration::utf16_view_from_bytes(name, name_len));
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
}
extern "C" void* rust_compile_regex(
uint16_t const* pattern_data, size_t pattern_len,
uint16_t const* flags_data, size_t flags_len,
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
uint16_t const** error_out, size_t* error_len_out)
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
{
*error_out = nullptr;
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
*error_len_out = 0;
LibJS: Handle empty UTF-16 strings in Rust FFI Treat zero length UTF-16 slices from Rust as empty views at the FFI boundary instead of assuming a non null backing pointer. Add a regression test which crashed before these changes. Fixes a crash loading github.com/ladybirdbrowser/ladybird.
2026-03-31 13:27:42 -03:00
auto pattern = JS::RustIntegration::utf16_view_from_bytes(pattern_data, pattern_len);
auto flags_view = JS::RustIntegration::utf16_view_from_bytes(flags_data, flags_len);
LibJS+LibRegex: Switch RegExp over to the Rust engine Switch LibJS `RegExp` over to the Rust-backed `ECMAScriptRegex` APIs. Route `new RegExp()`, regex literals, and the RegExp builtins through the new compile and exec APIs, and stop re-validating patterns with the deleted C++ parser on the way in. Preserve the observable error behavior by carrying structured compile errors and backtracking-limit failures across the FFI boundary. Cache compiled regex state and named capture metadata on `RegExpObject` in the new representation. Use the new API surface to simplify and speed up the builtin paths too: share `exec_internal`, cache compiled regex pointers, keep the legacy RegExp statics lazy, run global replace through batch `find_all`, and optimize replace, test, split, and String helper paths. Add regression tests for those JavaScript-visible paths.
2026-03-25 06:52:40 -03:00
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
auto set_error = [&](Utf16String message) {
auto view = message.utf16_view();
auto* buffer = static_cast<uint16_t*>(kmalloc(view.length_in_code_units() * sizeof(uint16_t)));
for (size_t i = 0; i < view.length_in_code_units(); ++i)
buffer[i] = view.code_unit_at(i);
*error_out = buffer;
*error_len_out = view.length_in_code_units();
};
LibJS+LibRegex: Switch RegExp over to the Rust engine Switch LibJS `RegExp` over to the Rust-backed `ECMAScriptRegex` APIs. Route `new RegExp()`, regex literals, and the RegExp builtins through the new compile and exec APIs, and stop re-validating patterns with the deleted C++ parser on the way in. Preserve the observable error behavior by carrying structured compile errors and backtracking-limit failures across the FFI boundary. Cache compiled regex state and named capture metadata on `RegExpObject` in the new representation. Use the new API surface to simplify and speed up the builtin paths too: share `exec_internal`, cache compiled regex pointers, keep the legacy RegExp statics lazy, run global replace through batch `find_all`, and optimize replace, test, split, and String helper paths. Add regression tests for those JavaScript-visible paths.
2026-03-25 06:52:40 -03:00
// Extract unicode/unicode_sets from flags for parse_regex_pattern.
bool is_unicode = false;
bool is_unicode_sets = false;
for (size_t i = 0; i < flags_view.length_in_code_units(); ++i) {
auto ch = flags_view.code_unit_at(i);
if (ch == 'u')
is_unicode = true;
else if (ch == 'v')
is_unicode_sets = true;
}
auto parsed_pattern = JS::parse_regex_pattern(pattern, is_unicode, is_unicode_sets);
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
if (parsed_pattern.is_error()) {
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
set_error(Utf16String::formatted("RegExp compile error: {}", parsed_pattern.release_error().error));
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
return nullptr;
}
auto pattern_str = parsed_pattern.release_value();
LibJS+LibRegex: Switch RegExp over to the Rust engine Switch LibJS `RegExp` over to the Rust-backed `ECMAScriptRegex` APIs. Route `new RegExp()`, regex literals, and the RegExp builtins through the new compile and exec APIs, and stop re-validating patterns with the deleted C++ parser on the way in. Preserve the observable error behavior by carrying structured compile errors and backtracking-limit failures across the FFI boundary. Cache compiled regex state and named capture metadata on `RegExpObject` in the new representation. Use the new API surface to simplify and speed up the builtin paths too: share `exec_internal`, cache compiled regex pointers, keep the legacy RegExp statics lazy, run global replace through batch `find_all`, and optimize replace, test, split, and String helper paths. Add regression tests for those JavaScript-visible paths.
2026-03-25 06:52:40 -03:00
// Build compile flags from the flag characters.
regex::ECMAScriptCompileFlags compile_flags {};
for (size_t i = 0; i < flags_view.length_in_code_units(); ++i) {
auto ch = flags_view.code_unit_at(i);
switch (ch) {
case 'g':
compile_flags.global = true;
break;
case 'i':
compile_flags.ignore_case = true;
break;
case 'm':
compile_flags.multiline = true;
break;
case 's':
compile_flags.dot_all = true;
break;
case 'u':
compile_flags.unicode = true;
break;
case 'v':
compile_flags.unicode_sets = true;
break;
case 'y':
compile_flags.sticky = true;
break;
case 'd':
compile_flags.has_indices = true;
break;
default:
break;
}
}
LibRegex: Compile ECMAScript patterns from UTF-16 Accept Utf16View patterns at the LibRegex compile boundary and pass UTF-16 or ASCII storage directly into the Rust regex parser. This keeps JavaScript regular expression construction from converting patterns through UTF-8 when LibRegex can consume the same UTF-16 representation used by LibJS. Update RegExp construction, HTML pattern validation, the regex fuzzer, and LibRegex tests to use the UTF-16 compile API.
2026-06-22 08:07:20 -03:00
auto compiled = regex::ECMAScriptRegex::compile(pattern_str.utf16_view(), compile_flags);
LibJS+LibRegex: Switch RegExp over to the Rust engine Switch LibJS `RegExp` over to the Rust-backed `ECMAScriptRegex` APIs. Route `new RegExp()`, regex literals, and the RegExp builtins through the new compile and exec APIs, and stop re-validating patterns with the deleted C++ parser on the way in. Preserve the observable error behavior by carrying structured compile errors and backtracking-limit failures across the FFI boundary. Cache compiled regex state and named capture metadata on `RegExpObject` in the new representation. Use the new API surface to simplify and speed up the builtin paths too: share `exec_internal`, cache compiled regex pointers, keep the legacy RegExp statics lazy, run global replace through batch `find_all`, and optimize replace, test, split, and String helper paths. Add regression tests for those JavaScript-visible paths.
2026-03-25 06:52:40 -03:00
if (compiled.is_error()) {
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
auto error = compiled.release_error();
set_error(Utf16String::formatted("RegExp compile error: {}", Utf16String::from_utf8(error)));
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
return nullptr;
}
LibJS+LibRegex: Switch RegExp over to the Rust engine Switch LibJS `RegExp` over to the Rust-backed `ECMAScriptRegex` APIs. Route `new RegExp()`, regex literals, and the RegExp builtins through the new compile and exec APIs, and stop re-validating patterns with the deleted C++ parser on the way in. Preserve the observable error behavior by carrying structured compile errors and backtracking-limit failures across the FFI boundary. Cache compiled regex state and named capture metadata on `RegExpObject` in the new representation. Use the new API surface to simplify and speed up the builtin paths too: share `exec_internal`, cache compiled regex pointers, keep the legacy RegExp statics lazy, run global replace through batch `find_all`, and optimize replace, test, split, and String helper paths. Add regression tests for those JavaScript-visible paths.
2026-03-25 06:52:40 -03:00
return new RustCompiledRegex { move(pattern_str) };
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
}
extern "C" void rust_free_compiled_regex(void* ptr)
{
delete static_cast<RustCompiledRegex*>(ptr);
}
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
extern "C" void rust_free_error_string(uint16_t const* str)
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
{
Libraries: Clean up UTF-16 source text paths Store parser errors, source range filenames, source code filenames, module source, and Rust parser errors as UTF-16 where they flow back into JavaScript-visible strings. Keep byte-oriented source buffers byte-backed. Remove temporary PrimitiveString, ByteString, and UTF-8 detours from JSON, RegExp, module debug logging, print formatting, and tests.
2026-06-21 14:03:19 -03:00
kfree(const_cast<uint16_t*>(str));
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
}
extern "C" size_t rust_number_to_utf16(double value, uint16_t* buffer, size_t buffer_len)
{
auto str = JS::number_to_utf16_string(value);
auto view = str.utf16_view();
auto len = min(view.length_in_code_units(), buffer_len);
for (size_t i = 0; i < len; ++i)
buffer[i] = view.code_unit_at(i);
return len;
}
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
}
Reference in a new issue Copy permalink