dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Cargo.toml

39 lines
859 B
TOML
Raw Normal View History

LibJS: Add alternative source-to-bytecode pipeline in Rust Implement a complete Rust reimplementation of the LibJS frontend: lexer, parser, AST, scope collector, and bytecode code generator. The Rust pipeline is built via Corrosion (CMake-Cargo bridge) and linked into LibJS as a static library. It is gated behind a build flag (ENABLE_RUST, on by default except on Windows) and two runtime environment variables: - LIBJS_CPP: Use the C++ pipeline instead of Rust - LIBJS_COMPARE_PIPELINES=1: Run both pipelines in lockstep, aborting on any difference in AST or bytecode generated. The C++ side communicates with Rust through a C FFI layer (RustIntegration.cpp/h) that passes source text to Rust and receives a populated Executable back via a BytecodeFactory interface.
2026-02-23 07:50:46 -03:00
[workspace]
members = [
LibGfx: Implement YUV->RGBA color conversion for CPU painting Using the Rust yuv crate, eagerly convert from YUV to RGBA on the CPU when a GPU context is unavailable. Time spent converting an 8-bit YUV frame with this crate is better than libyuv on ARM by about 20%, and on x86 with AVX2, it achieves similar numbers to libyuv.
2026-04-16 22:43:09 -03:00
"Libraries/LibGfx/Rust",
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/LibJS/Rust",
LibRegex/Rust: Add the ECMA-262 regex engine Add LibRegex's new Rust ECMAScript regular expression engine. Replace the old parser's direct pattern-to-bytecode pipeline with a split architecture: parse patterns into a lossless AST first, then lower that AST into bytecode for a dedicated backtracking VM. Keep the syntax tree as the place for validation, analysis, and optimization instead of teaching every transformation to rewrite partially built bytecode. Specialize this backend for the job LibJS actually needs. The old C++ engine shared one generic parser and matcher stack across ECMA-262 and POSIX modes and supported both byte-string and UTF-16 inputs. The new engine focuses on ECMA-262 semantics on WTF-16 data, which lets it model lone surrogates and other JavaScript-specific behavior directly instead of carrying POSIX and multi-encoding constraints through the whole implementation. Fill in the ECMAScript features needed to replace the old engine for real web workloads: Unicode properties and sets, lookahead and lookbehind, named groups and backreferences, modifier groups, string properties, large quantifiers, lone surrogates, and the parser and VM corner cases those features exercise. Reshape the runtime around compile-time pattern hints and a hotter VM loop. Pre-resolve Unicode properties, derive first-character, character-class, and simple-scan filters, extract safe trailing literals for anchored patterns, add literal and literal-alternation fast paths, and keep reusable scratch storage for registers, backtracking state, and modifier stacks. Teach `find_all` to stay inside one VM so global searches stop paying setup costs on every match. Make those shortcuts semantics-aware instead of merely fast. In Unicode mode, do not use literal fast paths for lone surrogates, since ECMA-262 must not let `/\ud83d/u` match inside a surrogate pair. Likewise, only derive end-anchor suffix hints when the suffix lies on every path to `Match`, so lookarounds and disjunctions cannot skip into a shared tail and produce false negatives. This commit lands the Rust crate, the C++ wrapper, the build integration, and the initial LibJS-side plumbing needed to exercise the new engine under real RegExp callers before removing the legacy backend.
2026-03-25 10:41:38 -03:00
"Libraries/LibRegex/Rust",
LibJS+LibUnicode: Use icu4x for Temporal calendar operations Replace the icu4c-based calendar implementation with one built on the icu4x Rust crate (icu_calendar). The icu4c API does not expose the píngqì month-assignment algorithm used by the Chinese and Dangi lunisolar calendars. Our old code had to approximate this by walking months via epoch millisecond arithmetic and manually tracking leap month positions, which produced incorrect month codes and ordinal month numbers for certain years. The icu4x calendar crate handles píngqì natively. With this patch, which is almost a 1-to-1 mapping of ICU invocations, we pass 100% of all Temporal test262 tests. The end goal might be to use icu4x for all of our ICU needs. But it does not yet provide the APIs needed for all ECMA-402 prototypes.
2026-03-10 10:19:29 -03:00
"Libraries/LibUnicode/Rust",
LibWasm+Meta: Add Cranelift AOT compilation backend Add an optional Cranelift-based AOT compiler for WebAssembly functions, enabled via -DENABLE_CRANELIFT_JIT=ON.
2026-04-22 06:48:56 -03:00
"Libraries/LibWasm/Rust",
LibWeb/CSS: Port the CSS Tokenizer to Rust test-css-tokenizer is updated to run both the C++ and Rust tokenizers and compare their output, to ensure they behave identically. The Parser still uses the C++ Tokenizer. The LibWeb crate, FFI layer etc are all based on the existing ones for other libraries. This is a direct AI translation to get us started, and not idiomatic Rust. Future work can be done to make it more sensible.
2026-04-15 07:53:15 -03:00
"Libraries/LibWeb/Rust",
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: Extract BytecodeDef into a shared Rust crate Move the Bytecode.def parser, field type info, and layout computation out of Rust/build.rs into a standalone BytecodeDef crate. This allows both the Rust bytecode codegen (build.rs) and the upcoming AsmIntGen tool to share a single source of truth for instruction field offsets and sizes. The AsmIntGen directory is excluded from the workspace since it has its own Cargo.toml and is built separately by CMake.
2026-03-06 18:07:06 -03:00
exclude = [
"Libraries/LibJS/AsmIntGen",
]
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
resolver = "2"
LibJS/Rust: Add aggressive optimisations for distribution Enable fat LTO and other Rust optimisations, mirroring the C++ distribution target
2026-02-25 06:14:49 -03:00
[profile.release]
panic = "abort"
[profile.distribution]
inherits = "release"
incremental = false
codegen-units = 1
lto = true
Meta: Add lints to Rust workspace lint configuration
2026-03-03 10:52:25 -03:00
[workspace.lints.clippy]
all = "deny" # includes lintgroups: correctness, suspicious, style, complexity, perf
# from clippy:nursery:
redundant_clone = "deny"
# from clippy:pedantic:
uninlined_format_args = "deny"
semicolon_if_nothing_returned = "deny"
manual_let_else = "deny"
unnecessary_wraps = "deny"
manual_assert = "deny"
ref_option = "deny"
elidable_lifetime_names = "deny"
unnested_or_patterns = "deny"
borrow_as_ptr = "deny"
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
explicit_iter_loop = "deny"
Reference in a new issue Copy permalink