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

1504 lines
36 KiB
Text
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
# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
version = 4
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "adblock"
version = "0.12.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "db6fe7702c798519299bcbe011ff6f1dc9e3aedc1f3171178cddf71e1736bf95"
dependencies = [
"addr",
"arrayvec",
"base64",
"bitflags",
"flatbuffers",
"idna",
"itertools",
"memchr",
"percent-encoding",
"precomputed-hash",
"regex",
"rustc-hash 1.1.0",
"seahash",
"serde",
"serde_json",
"thiserror",
"url",
]
[[package]]
name = "addr"
version = "0.15.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a93b8a41dbe230ad5087cc721f8d41611de654542180586b315d9f4cf6b72bef"
dependencies = [
"psl",
"psl-types",
]
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
[[package]]
name = "aho-corasick"
version = "1.1.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ddd31a130427c27518df266943a5308ed92d4b226cc639f5a8f1002816174301"
dependencies = [
"memchr",
]
[[package]]
name = "allocator-api2"
version = "0.2.21"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "683d7910e743518b0e34f1186f92494becacb047c7b6bf616c96772180fef923"
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
[[package]]
name = "anstream"
version = "1.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "824a212faf96e9acacdbd09febd34438f8f711fb84e09a8916013cd7815ca28d"
dependencies = [
"anstyle",
"anstyle-parse",
"anstyle-query",
"anstyle-wincon",
"colorchoice",
"is_terminal_polyfill",
"utf8parse",
]
[[package]]
name = "anstyle"
version = "1.0.14"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "940b3a0ca603d1eade50a4846a2afffd5ef57a9feac2c0e2ec2e14f9ead76000"
[[package]]
name = "anstyle-parse"
version = "1.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "52ce7f38b242319f7cabaa6813055467063ecdc9d355bbb4ce0c68908cd8130e"
dependencies = [
"utf8parse",
]
[[package]]
name = "anstyle-query"
version = "1.1.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "40c48f72fd53cd289104fc64099abca73db4166ad86ea0b4341abe65af83dadc"
dependencies = [
"windows-sys",
]
[[package]]
name = "anstyle-wincon"
version = "3.0.11"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "291e6a250ff86cd4a820112fb8898808a366d8f9f58ce16d1f538353ad55747d"
dependencies = [
"anstyle",
"once_cell_polyfill",
"windows-sys",
]
[[package]]
name = "anyhow"
version = "1.0.102"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7f202df86484c868dbad7eaa557ef785d5c66295e41b460ef922eca0723b842c"
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
[[package]]
name = "arbitrary"
version = "1.4.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c3d036a3c4ab069c7b410a2ce876bd74808d2d0888a82667669f8e783a898bf1"
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "arrayvec"
version = "0.7.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7c02d123df017efcdfbd739ef81735b36c5ba83ec3c59c80a9d7ecc718f92e50"
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
[[package]]
name = "autocfg"
version = "1.5.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c08606f8c3cbf4ce6ec8e28fb0014a2c086708fe954eaa885384a6165172e7e8"
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "base64"
version = "0.22.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "72b3254f16251a8381aa12e40e3c4d2f0199f8c6508fbecb9d91f575e0fbb8c6"
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
[[package]]
name = "bitflags"
version = "2.11.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "843867be96c8daad0d758b57df9392b6d8d271134fce549de6ce169ff98a92af"
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
dependencies = [
"serde_core",
]
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
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
[[package]]
name = "bumpalo"
version = "3.20.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "5d20789868f4b01b2f2caec9f5c4e0213b41e3e5702a50157d699ae31ced2fcb"
dependencies = [
"allocator-api2",
]
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
[[package]]
name = "bytecode_def"
version = "0.1.0"
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
[[package]]
name = "calendrical_calculations"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
version = "0.2.4"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
checksum = "5abbd6eeda6885048d357edc66748eea6e0268e3dd11f326fff5bd248d779c26"
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
dependencies = [
"core_maths",
"displaydoc",
]
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
[[package]]
name = "cbindgen"
version = "0.29.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "befbfd072a8e81c02f8c507aefce431fe5e7d051f83d48a23ffc9b9fe5a11799"
dependencies = [
"clap",
"heck",
"indexmap",
"log",
"proc-macro2",
"quote",
"serde",
"serde_json",
"syn",
"tempfile",
"toml",
]
[[package]]
name = "cfg-if"
version = "1.0.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9330f8b2ff13f34540b44e946ef35111825727b38d33286ef986142615121801"
LibWeb: Implement `chardetng`-based encoding detection for HTML parsing
2026-05-23 06:00:51 -03:00
[[package]]
name = "chardetng"
version = "1.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "13de944a44b5064ee5d3a5ceccc49a41bfec50f2580e66f82e87703acdb88b53"
dependencies = [
"cfg-if",
"encoding_rs",
"memchr",
]
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
[[package]]
name = "clap"
version = "4.6.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b193af5b67834b676abd72466a96c1024e6a6ad978a1f484bd90b85c94041351"
dependencies = [
"clap_builder",
]
[[package]]
name = "clap_builder"
version = "4.6.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "714a53001bf66416adb0e2ef5ac857140e7dc3a0c48fb28b2f10762fc4b5069f"
dependencies = [
"anstream",
"anstyle",
"clap_lex",
"strsim",
]
[[package]]
name = "clap_lex"
version = "1.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c8d4a3bb8b1e0c1050499d1815f5ab16d04f0959b233085fb31653fbfc9d98f9"
[[package]]
name = "colorchoice"
version = "1.0.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1d07550c9036bf2ae0c684c4297d503f838287c83c53686d05370d0e139ae570"
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
[[package]]
name = "core_maths"
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "77745e017f5edba1a9c1d854f6f3a52dac8a12dd5af5d2f54aecf61e43d80d30"
dependencies = [
"libm",
]
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
[[package]]
name = "cranelift-bforest"
version = "0.116.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "e15d04a0ce86cb36ead88ad68cf693ffd6cda47052b9e0ac114bc47fd9cd23c4"
dependencies = [
"cranelift-entity",
]
[[package]]
name = "cranelift-bitset"
version = "0.116.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7c6e3969a7ce267259ce244b7867c5d3bc9e65b0a87e81039588dfdeaede9f34"
[[package]]
name = "cranelift-codegen"
version = "0.116.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "2c22032c4cb42558371cf516bb47f26cdad1819d3475c133e93c49f50ebf304e"
dependencies = [
"bumpalo",
"cranelift-bforest",
"cranelift-bitset",
"cranelift-codegen-meta",
"cranelift-codegen-shared",
"cranelift-control",
"cranelift-entity",
"cranelift-isle",
"gimli",
"hashbrown 0.14.5",
"log",
"regalloc2",
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
"rustc-hash 2.1.2",
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
"serde",
"smallvec",
"target-lexicon",
]
[[package]]
name = "cranelift-codegen-meta"
version = "0.116.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c904bc71c61b27fc57827f4a1379f29de64fe95653b620a3db77d59655eee0b8"
dependencies = [
"cranelift-codegen-shared",
]
[[package]]
name = "cranelift-codegen-shared"
version = "0.116.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "40180f5497572f644ce88c255480981ae2ec1d7bb4d8e0c0136a13b87a2f2ceb"
[[package]]
name = "cranelift-control"
version = "0.116.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "26d132c6d0bd8a489563472afc171759da0707804a65ece7ceb15a8c6d7dd5ef"
dependencies = [
"arbitrary",
]
[[package]]
name = "cranelift-entity"
version = "0.116.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4b2d0d9618275474fbf679dd018ac6e009acbd6ae6850f6a67be33fb3b00b323"
dependencies = [
"cranelift-bitset",
]
[[package]]
name = "cranelift-frontend"
version = "0.116.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4fac41e16729107393174b0c9e3730fb072866100e1e64e80a1a963b2e484d57"
dependencies = [
"cranelift-codegen",
"log",
"smallvec",
"target-lexicon",
]
[[package]]
name = "cranelift-isle"
version = "0.116.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1ca20d576e5070044d0a72a9effc2deacf4d6aa650403189d8ea50126483944d"
[[package]]
name = "cranelift-module"
version = "0.116.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4d55612bebcf16ff7306c8a6f5bdb6d45662b8aa1ee058ecce8807ad87db719b"
dependencies = [
"anyhow",
"cranelift-codegen",
"cranelift-control",
]
[[package]]
name = "cranelift-native"
version = "0.116.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b8dee82f3f1f2c4cba9177f1cc5e350fe98764379bcd29340caa7b01f85076c7"
dependencies = [
"cranelift-codegen",
"libc",
"target-lexicon",
]
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
[[package]]
name = "displaydoc"
version = "0.2.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "97369cbbc041bc366949bc74d34658d6cda5621039731c6310521892a3a20ae0"
dependencies = [
"proc-macro2",
"quote",
"syn",
]
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "either"
version = "1.16.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "91622ff5e7162018101f2fea40d6ebf4a78bbe5a49736a2020649edf9693679e"
LibWeb: Implement `chardetng`-based encoding detection for HTML parsing
2026-05-23 06:00:51 -03:00
[[package]]
name = "encoding_rs"
version = "0.8.35"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "75030f3c4f45dafd7586dd6780965a8c7e8e285a5ecb86713e63a79c5b2766f3"
dependencies = [
"cfg-if",
]
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
[[package]]
name = "equivalent"
version = "1.0.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "877a4ace8713b0bcf2a4e7eec82529c029f1d0619886d18145fea96c3ffe5c0f"
[[package]]
name = "errno"
version = "0.3.14"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "39cab71617ae0d63f51a36d69f866391735b51691dbda63cf6f96d042b63efeb"
dependencies = [
"libc",
"windows-sys",
]
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
[[package]]
name = "fallible-iterator"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "2acce4a10f12dc2fb14a218589d4f1f62ef011b2d0cc4b3cb1bba8e94da14649"
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
[[package]]
name = "fastrand"
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
version = "2.4.0"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
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
checksum = "a043dc74da1e37d6afe657061213aa6f425f855399a11d3463c6ecccc4dfda1f"
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
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "flatbuffers"
version = "25.12.19"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "35f6839d7b3b98adde531effaf34f0c2badc6f4735d26fe74709d8e513a96ef3"
dependencies = [
"bitflags",
"rustc_version",
]
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
[[package]]
name = "foldhash"
version = "0.1.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d9c4f5dac5e15c24eb999c26181a6ca40b39fe946cbe4c263c7209467bc83af2"
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "form_urlencoded"
version = "1.2.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "cb4cb245038516f5f85277875cdaa4f7d2c9a0fa0468de06ed190163b1581fcf"
dependencies = [
"percent-encoding",
]
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
[[package]]
name = "getrandom"
version = "0.4.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0de51e6874e94e7bf76d726fc5d13ba782deca734ff60d5bb2fb2607c7406555"
dependencies = [
"cfg-if",
"libc",
"r-efi",
"wasip2",
"wasip3",
]
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
[[package]]
name = "gimli"
version = "0.31.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "07e28edb80900c19c28f1072f2e8aeca7fa06b23cd4169cefe1af5aa3260783f"
dependencies = [
"fallible-iterator",
"indexmap",
"stable_deref_trait",
]
[[package]]
name = "hashbrown"
version = "0.14.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "e5274423e17b7c9fc20b6e7e208532f9b19825d82dfd615708b70edd83df41f1"
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
[[package]]
name = "hashbrown"
version = "0.15.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9229cfe53dfd69f0609a49f65461bd93001ea1ef889cd5529dd176593f5338a1"
dependencies = [
"foldhash",
]
[[package]]
name = "hashbrown"
version = "0.16.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "841d1cc9bed7f9236f321df977030373f4a4163ae1a7dbfe1a51a2c1a51d9100"
[[package]]
name = "heck"
version = "0.5.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "2304e00983f87ffb38b55b444b5e3b60a884b5d30c0fca7d82fe33449bbe55ea"
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
[[package]]
name = "icu_calendar"
LibUnicode: Update icu4x's calendar module to 2.2.1
2026-05-05 11:49:41 -03:00
version = "2.2.1"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
LibUnicode: Update icu4x's calendar module to 2.2.1
2026-05-05 11:49:41 -03:00
checksum = "a2b2acc6263f494f1df50685b53ff8e57869e47d5c6fe39c23d518ae9a4f3e45"
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
dependencies = [
"calendrical_calculations",
"displaydoc",
"icu_calendar_data",
"icu_locale",
"icu_locale_core",
"icu_provider",
"ixdtf",
"tinystr",
"zerovec",
]
[[package]]
name = "icu_calendar_data"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
version = "2.2.0"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
checksum = "118577bcf3a0fa7c6ac0a7d6e951814da84ee56b9b1f68fb4d8d10b08cefaf4d"
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
[[package]]
name = "icu_collections"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
version = "2.2.0"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
checksum = "2984d1cd16c883d7935b9e07e44071dca8d917fd52ecc02c04d5fa0b5a3f191c"
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
dependencies = [
"displaydoc",
"potential_utf",
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
"utf8_iter",
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
"yoke",
"zerofrom",
"zerovec",
]
[[package]]
name = "icu_locale"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
version = "2.2.0"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
checksum = "d5a396343c7208121dc86e35623d3dfe19814a7613cfd14964994cdc9c9a2e26"
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
dependencies = [
"icu_collections",
"icu_locale_core",
"icu_locale_data",
"icu_provider",
"potential_utf",
"tinystr",
"zerovec",
]
[[package]]
name = "icu_locale_core"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
version = "2.2.0"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
checksum = "92219b62b3e2b4d88ac5119f8904c10f8f61bf7e95b640d25ba3075e6cac2c29"
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
dependencies = [
"displaydoc",
"litemap",
"serde",
"tinystr",
"writeable",
"zerovec",
]
[[package]]
name = "icu_locale_data"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
version = "2.2.0"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
checksum = "d5fdcc9ac77c6d74ff5cf6e65ef3181d6af32003b16fce3a77fb451d2f695993"
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
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "icu_normalizer"
version = "2.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c56e5ee99d6e3d33bd91c5d85458b6005a22140021cc324cea84dd0e72cff3b4"
dependencies = [
"icu_collections",
"icu_normalizer_data",
"icu_properties",
"icu_provider",
"smallvec",
"zerovec",
]
[[package]]
name = "icu_normalizer_data"
version = "2.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "da3be0ae77ea334f4da67c12f149704f19f81d1adf7c51cf482943e84a2bad38"
[[package]]
name = "icu_properties"
version = "2.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "bee3b67d0ea5c2cca5003417989af8996f8604e34fb9ddf96208a033901e70de"
dependencies = [
"icu_collections",
"icu_locale_core",
"icu_properties_data",
"icu_provider",
"zerotrie",
"zerovec",
]
[[package]]
name = "icu_properties_data"
version = "2.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8e2bbb201e0c04f7b4b3e14382af113e17ba4f63e2c9d2ee626b720cbce54a14"
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
[[package]]
name = "icu_provider"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
version = "2.2.0"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
checksum = "139c4cf31c8b5f33d7e199446eff9c1e02decfc2f0eec2c8d71f65befa45b421"
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
dependencies = [
"displaydoc",
"icu_locale_core",
"serde",
"stable_deref_trait",
"writeable",
"yoke",
"zerofrom",
"zerotrie",
"zerovec",
]
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
[[package]]
name = "id-arena"
version = "2.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "3d3067d79b975e8844ca9eb072e16b31c3c1c36928edf9c6789548c524d0d954"
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "idna"
version = "1.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "3b0875f23caa03898994f6ddc501886a45c7d3d62d04d2d90788d47be1b1e4de"
dependencies = [
"idna_adapter",
"smallvec",
"utf8_iter",
]
[[package]]
name = "idna_adapter"
version = "1.2.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "cb68373c0d6620ef8105e855e7745e18b0d00d3bdb07fb532e434244cdb9a714"
dependencies = [
"icu_normalizer",
"icu_properties",
]
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
[[package]]
name = "indexmap"
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
version = "2.13.1"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
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
checksum = "45a8a2b9cb3e0b0c1803dbb0758ffac5de2f425b23c28f518faabd9d805342ff"
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
dependencies = [
"equivalent",
"hashbrown 0.16.1",
"serde",
"serde_core",
]
[[package]]
name = "is_terminal_polyfill"
version = "1.70.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a6cb138bb79a146c1bd460005623e142ef0181e3d0219cb493e02f7d08a35695"
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "itertools"
version = "0.13.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "413ee7dfc52ee1a4949ceeb7dbc8a33f2d6c088194d9f922fb8318faf1f01186"
dependencies = [
"either",
]
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
[[package]]
name = "itoa"
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
version = "1.0.18"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
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
checksum = "8f42a60cbdf9a97f5d2305f08a87dc4e09308d1276d28c869c684d7777685682"
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+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
[[package]]
name = "ixdtf"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
version = "0.6.5"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
checksum = "2ceaf4c6c48465bead8cb6a0b7c4ee0c86ecbb31239032b9c66ab9a08d2f3ee1"
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
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
[[package]]
name = "leb128fmt"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "09edd9e8b54e49e587e4f6295a7d29c3ea94d469cb40ab8ca70b288248a81db2"
[[package]]
name = "libc"
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
version = "0.2.184"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
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
checksum = "48f5d2a454e16a5ea0f4ced81bd44e4cfc7bd3a507b61887c99fd3538b28e4af"
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
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
[[package]]
name = "libgfx_rust"
version = "0.1.0"
dependencies = [
"cbindgen",
"yuv",
]
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
[[package]]
name = "libjs_rust"
version = "0.1.0"
dependencies = [
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
"bytecode_def",
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
"cbindgen",
LibJS: Use foldhash in parser and scope-collector hash maps The std default RandomState (SipHash) was using ~9 percentage points of CPU on hash_one and write across the parse hot path, with the string interner adding another ~3 pp on top. The cost was spread across the interner, the scope collector's IndexMap<Utf16String, _>, and several parser-side HashSet<Utf16String> declarations. Use foldhash::quality::RandomState for the parser, scope collector, and string interner via a new fast_hash module. Quality keeps HashDoS resistance (keys are lexer tokens, attacker-controlled in a browser context) while shedding SipHash's per-byte cost, and on this workload it benchmarks slightly faster than foldhash::fast.
2026-05-04 19:14:33 -03:00
"foldhash",
LibJS: Allocate local variable indices in source order The scope collector stored identifier_groups and variables in HashMaps and then sorted them alphabetically before assigning local register indices. The sorts existed only because HashMap iteration order is non-deterministic; alphabetical was a stable choice for comparing bytecode against the now-removed C++ port. Switch both maps to indexmap::IndexMap so iteration follows the order of first reference (= source order), and drop the alphabetical sorts. Local indices now reflect declaration order, which matches what shows up in bytecode dumps and is easier to read alongside the source. Add a focused bytecode test using zebra/yak/aardvark to pin the new allocation order; existing tests using let/var declarations have their local indices renumbered to match.
2026-04-26 15:47:25 -03:00
"indexmap",
LibJS+LibUnicode: Use LibUnicode as appropriate for lexing JavaScript Now that LibUnicode exports its character type APIs in Rust, we can use them to lex identifiers and whitespace. Fixes #8870.
2026-04-18 14:05:14 -03:00
"libunicode_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
"num-bigint",
"num-integer",
"num-traits",
]
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
[[package]]
name = "libm"
version = "0.2.16"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b6d2cec3eae94f9f509c767b45932f1ada8350c4bdb85af2fcab4a3c14807981"
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
[[package]]
name = "libregex_rust"
version = "0.1.0"
dependencies = [
"cbindgen",
LibRegex+LibUnicode: Migrate Unicode Rust FFI methods to LibUnicode Let's not have LibRegex be the home of LibUnicode FFI. Move these to LibUnicode so that we can: 1. Use these helpers in other libraries more easily. 2. Swap out icu4c methods with icu4x methods all within LibUnicode.
2026-04-18 14:29:10 -03:00
"libunicode_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
]
LibTextCodec: Use encoding_rs for legacy codecs Replace the generated C++ legacy codec implementations with a small Rust wrapper around encoding_rs. This keeps the existing LibTextCodec API while moving label lookup, legacy decode/encode, validation, and streaming decoder state to Rust. The generated index data and generator are no longer needed. It also fixes several TextDecoder EOF cases due to a more correct implementation. encoding_rs finalizes decoders according to the Encoding Standard, so incomplete UTF-8/Big5 tails and malformed UTF-16 surrogate tails produce the required single replacement at end-of-queue instead of being dropped, buffered, or double-counted by our old hand-written decoders.
2026-06-19 19:51:56 -03:00
[[package]]
name = "libtextcodec_rust"
version = "0.1.0"
dependencies = [
"cbindgen",
"encoding_rs",
]
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
[[package]]
name = "libunicode_rust"
version = "0.1.0"
dependencies = [
"calendrical_calculations",
LibUnicode: Generate FFI bindings with cbindgen This places the exported structs and functions in the Unicode::FFI namespace.
2026-03-17 21:03:57 -03:00
"cbindgen",
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
"icu_calendar",
]
LibURL: Implement a URL parser in rust
2026-03-14 14:05:06 -03:00
[[package]]
name = "liburl_rust"
version = "0.1.0"
dependencies = [
"cbindgen",
LibURL: Use encoding_rs for form URL encoding Replace the Rust URL form-encoding callback bridge into C++ TextCodec with a direct encoding_rs encoder. This keeps percent-encode-after-encoding entirely in Rust and removes liburl_rust's dependency on LibTextCodec. It also happens to fix ISO-2022-JP URL encoding of literal U+FFFD. The LibTextCodec reverse lookup treats generated 0xFFFD table holes as real JIS0208 mappings, so literal U+FFFD skipped the encoder-error path. encoding_rs treats U+FFFD as unmappable, so URL encoding emits the required numeric character reference.
2026-06-19 19:39:56 -03:00
"encoding_rs",
LibURL: Implement URLPattern in Rust
2026-04-04 20:39:52 -03:00
"libregex_rust",
LibURL: Implement a URL parser in rust
2026-03-14 14:05:06 -03:00
"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
[[package]]
name = "libwasm_cranelift"
version = "0.1.0"
dependencies = [
"cbindgen",
"cranelift-codegen",
"cranelift-frontend",
"cranelift-module",
"cranelift-native",
"libc",
"regex",
"target-lexicon",
]
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "libweb_content_blocker_rust"
version = "0.1.0"
dependencies = [
"adblock",
"cbindgen",
"serde_json",
]
LibWeb: Replace the HTML tokenizer with Rust Replace the C++ HTML tokenizer with a Rust implementation behind the existing HTMLTokenizer API. Keep the parser-facing integration points for streaming input, insertion points, document.write(), EOF insertion, parser aborts, speculative parser input, and last start tag tracking. The generated FFI handle stays an implementation detail of HTMLTokenizer, so callers keep a single tokenizer class. Preserve duplicate attributes through FFI so C++ token normalization can record the duplicate-attribute signal used by CSP nonce checks. Keep bulk tag-name and attribute scans capped at the active insertion point so streamed parser input is spliced at the right offset. Use generated DAFSA tables for named character references and intern common tag and attribute names to reduce FFI marshalling overhead. This also fixes attribute name source positions, nested old insertion points, and aborted fast-path handling. TestHTMLTokenizer covers duplicate attributes and insertion points in fast tag-name, attribute-name, and quoted-value scans. A CSP text test covers duplicate nonce attributes on parser-created script elements. The tokenizer dump fixtures still match, TestHTMLTokenizer passes, and the full release test-web run passes with 6981 tests and 226 skipped.
2026-05-15 10:13:43 -03:00
[[package]]
name = "libweb_html_tokenizer"
version = "0.1.0"
dependencies = [
"cbindgen",
]
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
[[package]]
name = "libweb_rust"
version = "0.1.0"
dependencies = [
"cbindgen",
LibWeb: Implement `chardetng`-based encoding detection for HTML parsing
2026-05-23 06:00:51 -03:00
"chardetng",
LibWeb: Replace the HTML tokenizer with Rust Replace the C++ HTML tokenizer with a Rust implementation behind the existing HTMLTokenizer API. Keep the parser-facing integration points for streaming input, insertion points, document.write(), EOF insertion, parser aborts, speculative parser input, and last start tag tracking. The generated FFI handle stays an implementation detail of HTMLTokenizer, so callers keep a single tokenizer class. Preserve duplicate attributes through FFI so C++ token normalization can record the duplicate-attribute signal used by CSP nonce checks. Keep bulk tag-name and attribute scans capped at the active insertion point so streamed parser input is spliced at the right offset. Use generated DAFSA tables for named character references and intern common tag and attribute names to reduce FFI marshalling overhead. This also fixes attribute name source positions, nested old insertion points, and aborted fast-path handling. TestHTMLTokenizer covers duplicate attributes and insertion points in fast tag-name, attribute-name, and quoted-value scans. A CSP text test covers duplicate nonce attributes on parser-created script elements. The tokenizer dump fixtures still match, TestHTMLTokenizer passes, and the full release test-web run passes with 6981 tests and 226 skipped.
2026-05-15 10:13:43 -03:00
"libweb_html_tokenizer",
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
]
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
[[package]]
name = "linux-raw-sys"
version = "0.12.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "32a66949e030da00e8c7d4434b251670a91556f4144941d37452769c25d58a53"
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
[[package]]
name = "litemap"
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
version = "0.8.2"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
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
checksum = "92daf443525c4cce67b150400bc2316076100ce0b3686209eb8cf3c31612e6f0"
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
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
[[package]]
name = "log"
version = "0.4.29"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "5e5032e24019045c762d3c0f28f5b6b8bbf38563a65908389bf7978758920897"
[[package]]
name = "memchr"
version = "2.8.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f8ca58f447f06ed17d5fc4043ce1b10dd205e060fb3ce5b979b8ed8e59ff3f79"
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
[[package]]
name = "num-bigint"
version = "0.4.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a5e44f723f1133c9deac646763579fdb3ac745e418f2a7af9cd0c431da1f20b9"
dependencies = [
"num-integer",
"num-traits",
]
[[package]]
name = "num-integer"
version = "0.1.46"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7969661fd2958a5cb096e56c8e1ad0444ac2bbcd0061bd28660485a44879858f"
dependencies = [
"num-traits",
]
[[package]]
name = "num-traits"
version = "0.2.19"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "071dfc062690e90b734c0b2273ce72ad0ffa95f0c74596bc250dcfd960262841"
dependencies = [
"autocfg",
]
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
[[package]]
name = "once_cell"
version = "1.21.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9f7c3e4beb33f85d45ae3e3a1792185706c8e16d043238c593331cc7cd313b50"
[[package]]
name = "once_cell_polyfill"
version = "1.70.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "384b8ab6d37215f3c5301a95a4accb5d64aa607f1fcb26a11b5303878451b4fe"
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "percent-encoding"
version = "2.3.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9b4f627cb1b25917193a259e49bdad08f671f8d9708acfd5fe0a8c1455d87220"
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
[[package]]
name = "potential_utf"
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
version = "0.1.5"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
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
checksum = "0103b1cef7ec0cf76490e969665504990193874ea05c85ff9bab8b911d0a0564"
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
dependencies = [
"serde_core",
"writeable",
"zerovec",
]
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "precomputed-hash"
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "925383efa346730478fb4838dbe9137d2a47675ad789c546d150a6e1dd4ab31c"
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
[[package]]
name = "prettyplease"
version = "0.2.37"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "479ca8adacdd7ce8f1fb39ce9ecccbfe93a3f1344b3d0d97f20bc0196208f62b"
dependencies = [
"proc-macro2",
"syn",
]
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
[[package]]
name = "proc-macro2"
version = "1.0.106"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8fd00f0bb2e90d81d1044c2b32617f68fcb9fa3bb7640c23e9c748e53fb30934"
dependencies = [
"unicode-ident",
]
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "psl"
version = "2.1.210"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "27fbd4d9b2eb0b6e0cbd654bce70243f460cbc8dc92df6747e3fb911ce1cd4a8"
dependencies = [
"psl-types",
]
[[package]]
name = "psl-types"
version = "2.0.11"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "33cb294fe86a74cbcf50d4445b37da762029549ebeea341421c7c70370f86cac"
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
[[package]]
name = "quote"
version = "1.0.45"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "41f2619966050689382d2b44f664f4bc593e129785a36d6ee376ddf37259b924"
dependencies = [
"proc-macro2",
]
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
[[package]]
name = "r-efi"
version = "6.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f8dcc9c7d52a811697d2151c701e0d08956f92b0e24136cf4cf27b57a6a0d9bf"
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
[[package]]
name = "regalloc2"
version = "0.11.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "dc06e6b318142614e4a48bc725abbf08ff166694835c43c9dae5a9009704639a"
dependencies = [
"allocator-api2",
"bumpalo",
"hashbrown 0.15.5",
"log",
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
"rustc-hash 2.1.2",
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
"smallvec",
]
[[package]]
name = "regex"
version = "1.12.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "e10754a14b9137dd7b1e3e5b0493cc9171fdd105e0ab477f51b72e7f3ac0e276"
dependencies = [
"aho-corasick",
"memchr",
"regex-automata",
"regex-syntax",
]
[[package]]
name = "regex-automata"
version = "0.4.14"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "6e1dd4122fc1595e8162618945476892eefca7b88c52820e74af6262213cae8f"
dependencies = [
"aho-corasick",
"memchr",
"regex-syntax",
]
[[package]]
name = "regex-syntax"
version = "0.8.10"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "dc897dd8d9e8bd1ed8cdad82b5966c3e0ecae09fb1907d58efaa013543185d0a"
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "rustc-hash"
version = "1.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "08d43f7aa6b08d49f382cde6a7982047c3426db949b1424bc4b7ec9ae12c6ce2"
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
[[package]]
name = "rustc-hash"
version = "2.1.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "94300abf3f1ae2e2b8ffb7b58043de3d399c73fa6f4b73826402a5c457614dbe"
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "rustc_version"
version = "0.4.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "cfcb3a22ef46e85b45de6ee7e79d063319ebb6594faafcf1c225ea92ab6e9b92"
dependencies = [
"semver",
]
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
[[package]]
name = "rustix"
version = "1.1.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b6fe4565b9518b83ef4f91bb47ce29620ca828bd32cb7e408f0062e9930ba190"
dependencies = [
"bitflags",
"errno",
"libc",
"linux-raw-sys",
"windows-sys",
]
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "seahash"
version = "4.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1c107b6f4780854c8b126e228ea8869f4d7b71260f962fefb57b996b8959ba6b"
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
[[package]]
name = "semver"
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
version = "1.0.28"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
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
checksum = "8a7852d02fc848982e0c167ef163aaff9cd91dc640ba85e263cb1ce46fae51cd"
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+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
[[package]]
name = "serde"
version = "1.0.228"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9a8e94ea7f378bd32cbbd37198a4a91436180c5bb472411e48b5ec2e2124ae9e"
dependencies = [
"serde_core",
"serde_derive",
]
[[package]]
name = "serde_core"
version = "1.0.228"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "41d385c7d4ca58e59fc732af25c3983b67ac852c1a25000afe1175de458b67ad"
dependencies = [
"serde_derive",
]
[[package]]
name = "serde_derive"
version = "1.0.228"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d540f220d3187173da220f885ab66608367b6574e925011a9353e4badda91d79"
dependencies = [
"proc-macro2",
"quote",
"syn",
]
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
[[package]]
name = "serde_json"
version = "1.0.149"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "83fc039473c5595ace860d8c4fafa220ff474b3fc6bfdb4293327f1a37e94d86"
dependencies = [
"itoa",
"memchr",
"serde",
"serde_core",
"zmij",
]
[[package]]
name = "serde_spanned"
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
version = "1.1.1"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
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
checksum = "6662b5879511e06e8999a8a235d848113e942c9124f211511b16466ee2995f26"
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
dependencies = [
"serde_core",
]
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
[[package]]
name = "smallvec"
version = "1.15.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "67b1b7a3b5fe4f1376887184045fcf45c69e92af734b7aaddc05fb777b6fbd03"
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
[[package]]
name = "stable_deref_trait"
version = "1.2.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "6ce2be8dc25455e1f91df71bfa12ad37d7af1092ae736f3a6cd0e37bc7810596"
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
[[package]]
name = "strsim"
version = "0.11.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7da8b5736845d9f2fcb837ea5d9e2628564b3b043a70948a3f0b778838c5fb4f"
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
[[package]]
name = "syn"
version = "2.0.117"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "e665b8803e7b1d2a727f4023456bbbbe74da67099c585258af0ad9c5013b9b99"
dependencies = [
"proc-macro2",
"quote",
"unicode-ident",
]
[[package]]
name = "synstructure"
version = "0.13.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "728a70f3dbaf5bab7f0c4b1ac8d7ae5ea60a4b5549c8a5914361c99147a709d2"
dependencies = [
"proc-macro2",
"quote",
"syn",
]
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
[[package]]
name = "target-lexicon"
version = "0.13.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "adb6935a6f5c20170eeceb1a3835a49e12e19d792f6dd344ccc76a985ca5a6ca"
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
[[package]]
name = "tempfile"
version = "3.27.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "32497e9a4c7b38532efcdebeef879707aa9f794296a4f0244f6f69e9bc8574bd"
dependencies = [
"fastrand",
"getrandom",
"once_cell",
"rustix",
"windows-sys",
]
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "thiserror"
version = "1.0.69"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b6aaf5339b578ea85b50e080feb250a3e8ae8cfcdff9a461c9ec2904bc923f52"
dependencies = [
"thiserror-impl",
]
[[package]]
name = "thiserror-impl"
version = "1.0.69"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4fee6c4efc90059e10f81e6d42c60a18f76588c3d74cb83a0b242a2b6c7504c1"
dependencies = [
"proc-macro2",
"quote",
"syn",
]
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
[[package]]
name = "tinystr"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
version = "0.8.3"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
checksum = "c8323304221c2a851516f22236c5722a72eaa19749016521d6dff0824447d96d"
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
dependencies = [
"displaydoc",
"serde_core",
"zerovec",
]
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
[[package]]
name = "toml"
version = "0.9.12+spec-1.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "cf92845e79fc2e2def6a5d828f0801e29a2f8acc037becc5ab08595c7d5e9863"
dependencies = [
"indexmap",
"serde_core",
"serde_spanned",
"toml_datetime",
"toml_parser",
"toml_writer",
"winnow 0.7.15",
]
[[package]]
name = "toml_datetime"
version = "0.7.5+spec-1.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "92e1cfed4a3038bc5a127e35a2d360f145e1f4b971b551a2ba5fd7aedf7e1347"
dependencies = [
"serde_core",
]
[[package]]
name = "toml_parser"
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
version = "1.1.2+spec-1.1.0"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
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
checksum = "a2abe9b86193656635d2411dc43050282ca48aa31c2451210f4202550afb7526"
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
dependencies = [
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
"winnow 1.0.1",
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
]
[[package]]
name = "toml_writer"
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
version = "1.1.1+spec-1.1.0"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
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
checksum = "756daf9b1013ebe47a8776667b466417e2d4c5679d441c26230efd9ef78692db"
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
[[package]]
name = "unicode-ident"
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
version = "1.0.24"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
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
checksum = "e6e4313cd5fcd3dad5cafa179702e2b244f760991f45397d14d4ebf38247da75"
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
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
[[package]]
name = "unicode-xid"
version = "0.2.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ebc1c04c71510c7f702b52b7c350734c9ff1295c464a03335b00bb84fc54f853"
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
[[package]]
name = "url"
version = "2.5.8"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ff67a8a4397373c3ef660812acab3268222035010ab8680ec4215f38ba3d0eed"
dependencies = [
"form_urlencoded",
"idna",
"percent-encoding",
"serde",
]
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
[[package]]
name = "utf8_iter"
version = "1.0.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b6c140620e7ffbb22c2dee59cafe6084a59b5ffc27a8859a5f0d494b5d52b6be"
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
[[package]]
name = "utf8parse"
version = "0.2.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "06abde3611657adf66d383f00b093d7faecc7fa57071cce2578660c9f1010821"
[[package]]
name = "wasip2"
version = "1.0.2+wasi-0.2.9"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9517f9239f02c069db75e65f174b3da828fe5f5b945c4dd26bd25d89c03ebcf5"
dependencies = [
"wit-bindgen",
]
[[package]]
name = "wasip3"
version = "0.4.0+wasi-0.3.0-rc-2026-01-06"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "5428f8bf88ea5ddc08faddef2ac4a67e390b88186c703ce6dbd955e1c145aca5"
dependencies = [
"wit-bindgen",
]
[[package]]
name = "wasm-encoder"
version = "0.244.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "990065f2fe63003fe337b932cfb5e3b80e0b4d0f5ff650e6985b1048f62c8319"
dependencies = [
"leb128fmt",
"wasmparser",
]
[[package]]
name = "wasm-metadata"
version = "0.244.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "bb0e353e6a2fbdc176932bbaab493762eb1255a7900fe0fea1a2f96c296cc909"
dependencies = [
"anyhow",
"indexmap",
"wasm-encoder",
"wasmparser",
]
[[package]]
name = "wasmparser"
version = "0.244.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "47b807c72e1bac69382b3a6fb3dbe8ea4c0ed87ff5629b8685ae6b9a611028fe"
dependencies = [
"bitflags",
"hashbrown 0.15.5",
"indexmap",
"semver",
]
[[package]]
name = "windows-link"
version = "0.2.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f0805222e57f7521d6a62e36fa9163bc891acd422f971defe97d64e70d0a4fe5"
[[package]]
name = "windows-sys"
version = "0.61.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ae137229bcbd6cdf0f7b80a31df61766145077ddf49416a728b02cb3921ff3fc"
dependencies = [
"windows-link",
]
[[package]]
name = "winnow"
version = "0.7.15"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "df79d97927682d2fd8adb29682d1140b343be4ac0f08fd68b7765d9c059d3945"
[[package]]
name = "winnow"
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
version = "1.0.1"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
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
checksum = "09dac053f1cd375980747450bfc7250c264eaae0583872e845c0c7cd578872b5"
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
[[package]]
name = "wit-bindgen"
version = "0.51.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d7249219f66ced02969388cf2bb044a09756a083d0fab1e566056b04d9fbcaa5"
dependencies = [
"wit-bindgen-rust-macro",
]
[[package]]
name = "wit-bindgen-core"
version = "0.51.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ea61de684c3ea68cb082b7a88508a8b27fcc8b797d738bfc99a82facf1d752dc"
dependencies = [
"anyhow",
"heck",
"wit-parser",
]
[[package]]
name = "wit-bindgen-rust"
version = "0.51.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b7c566e0f4b284dd6561c786d9cb0142da491f46a9fbed79ea69cdad5db17f21"
dependencies = [
"anyhow",
"heck",
"indexmap",
"prettyplease",
"syn",
"wasm-metadata",
"wit-bindgen-core",
"wit-component",
]
[[package]]
name = "wit-bindgen-rust-macro"
version = "0.51.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0c0f9bfd77e6a48eccf51359e3ae77140a7f50b1e2ebfe62422d8afdaffab17a"
dependencies = [
"anyhow",
"prettyplease",
"proc-macro2",
"quote",
"syn",
"wit-bindgen-core",
"wit-bindgen-rust",
]
[[package]]
name = "wit-component"
version = "0.244.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9d66ea20e9553b30172b5e831994e35fbde2d165325bec84fc43dbf6f4eb9cb2"
dependencies = [
"anyhow",
"bitflags",
"indexmap",
"log",
"serde",
"serde_derive",
"serde_json",
"wasm-encoder",
"wasm-metadata",
"wasmparser",
"wit-parser",
]
[[package]]
name = "wit-parser"
version = "0.244.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ecc8ac4bc1dc3381b7f59c34f00b67e18f910c2c0f50015669dde7def656a736"
dependencies = [
"anyhow",
"id-arena",
"indexmap",
"log",
"semver",
"serde",
"serde_derive",
"serde_json",
"unicode-xid",
"wasmparser",
]
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
[[package]]
name = "writeable"
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
version = "0.6.3"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
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
checksum = "1ffae5123b2d3fc086436f8834ae3ab053a283cfac8fe0a0b8eaae044768a4c4"
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
[[package]]
name = "yoke"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
version = "0.8.2"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
checksum = "abe8c5fda708d9ca3df187cae8bfb9ceda00dd96231bed36e445a1a48e66f9ca"
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
dependencies = [
"stable_deref_trait",
"yoke-derive",
"zerofrom",
]
[[package]]
name = "yoke-derive"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
version = "0.8.2"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
checksum = "de844c262c8848816172cef550288e7dc6c7b7814b4ee56b3e1553f275f1858e"
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
dependencies = [
"proc-macro2",
"quote",
"syn",
"synstructure",
]
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
[[package]]
name = "yuv"
version = "0.8.13"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "47d3a7e2cda3061858987ee2fb028f61695f5ee13f9490d75be6c3900df9a4ea"
dependencies = [
"num-traits",
]
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
[[package]]
name = "zerofrom"
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
version = "0.1.7"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
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
checksum = "69faa1f2a1ea75661980b013019ed6687ed0e83d069bc1114e2cc74c6c04c4df"
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
dependencies = [
"zerofrom-derive",
]
[[package]]
name = "zerofrom-derive"
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
version = "0.1.7"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
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
checksum = "11532158c46691caf0f2593ea8358fed6bbf68a0315e80aae9bd41fbade684a1"
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
dependencies = [
"proc-macro2",
"quote",
"syn",
"synstructure",
]
[[package]]
name = "zerotrie"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
version = "0.2.4"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
checksum = "0f9152d31db0792fa83f70fb2f83148effb5c1f5b8c7686c3459e361d9bc20bf"
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
dependencies = [
"displaydoc",
LibWeb: Add adblock-rust FFI hooks Add adblock-rust to a dedicated LibWeb content blocker Rust crate and expose FFI entry points for creating an engine, matching network requests, and producing cosmetic CSS. Export a string result type for returning generated CSS to C++ callers. Regenerate the Flatpak cargo source list for the new Rust dependencies.
2026-05-23 17:14:22 -03:00
"yoke",
"zerofrom",
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
"zerovec",
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
]
[[package]]
name = "zerovec"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
version = "0.11.6"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
checksum = "90f911cbc359ab6af17377d242225f4d75119aec87ea711a880987b18cd7b239"
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
dependencies = [
"serde",
"yoke",
"zerofrom",
"zerovec-derive",
]
[[package]]
name = "zerovec-derive"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
version = "0.11.3"
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
source = "registry+https://github.com/rust-lang/crates.io-index"
LibJS+LibUnicode: Update icu4x's calendar module to 2.2.0 First: We now pin the icu4x version to an exact number. Minor version upgrades can result in noisy deprecation warnings and API changes which cause tests to fail. So let's pin the known-good version exactly. This patch updates our Rust calendar module to use the new APIs. This initially caused some test failures due to the new Date::try_new API (which is the recommended replacement for Date::try_new_from_codes) having quite a limited year range of +/-9999. So we must use other APIs (Date::try_from_fields and calendrical_calculations::gregorian) to avoid these limits. http://github.com/unicode-org/icu4x/blob/main/CHANGELOG.md#icu4x-22
2026-04-14 17:00:37 -03:00
checksum = "625dc425cab0dca6dc3c3319506e6593dcb08a9f387ea3b284dbd52a92c40555"
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
dependencies = [
"proc-macro2",
"quote",
"syn",
]
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
[[package]]
name = "zmij"
version = "1.0.21"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b8848ee67ecc8aedbaf3e4122217aff892639231befc6a1b58d29fff4c2cabaa"
Reference in a new issue Copy permalink