Rust编写的JavaScript引擎,该项目是一个试验性质的项目。
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

119 lines
3.6 KiB

[workspace]
resolver = "2"
members = [
Initial version of a JS -> Rust conversion trait. (#2276) This Pull Request closes #1975. It's still a work in progress, but tries to go in that direction. It changes the following: - Adds a new `TryFromJs` trait, that can be derived using a new `boa_derive` crate. - Adds a new `try_js_into()` function that, similarly to the standard library `TryInto` trait Things to think about: - Should the `boa_derive` crate be re-exported in `boa_engine` using a `derive` feature, similar to how it's done in `serde`? - The current implementation only converts perfectly valid values. So, if we try to convert a big integer into an `i8`, or any floating point number to an `f32`. So, you cannot derive `TryFromJs` for structures that contain an `f32` for example (you can still manually implement the trait, though, and decide in favour of a loss of precision). Should we also provide some traits for transparent loss of precision? - Currently, you cannot convert between types, so if the JS struct has an integer, you cannot cast it to a boolean, for example. Should we provide a `TryConvertJs` trait, for example to force conversions? - Currently we only have basic types and object conversions. Should add `Array` to `Vec` conversion, for example, right? Should we also add `TypedArray` conversions? What about `Map` and `Set`? Does this step over the fine grained APIs that we were creating? Note that this still requires a bunch of documentation, tests, and validation from the dev team and from the users that requested this feature. I'm particularly interested in @lastmjs's thoughts on this API. I already added an usage example in `boa_examples/src/bin/derive.rs`. Co-authored-by: jedel1043 <jedel0124@gmail.com>
2 years ago
"boa_ast",
"boa_cli",
"boa_engine",
Initial version of a JS -> Rust conversion trait. (#2276) This Pull Request closes #1975. It's still a work in progress, but tries to go in that direction. It changes the following: - Adds a new `TryFromJs` trait, that can be derived using a new `boa_derive` crate. - Adds a new `try_js_into()` function that, similarly to the standard library `TryInto` trait Things to think about: - Should the `boa_derive` crate be re-exported in `boa_engine` using a `derive` feature, similar to how it's done in `serde`? - The current implementation only converts perfectly valid values. So, if we try to convert a big integer into an `i8`, or any floating point number to an `f32`. So, you cannot derive `TryFromJs` for structures that contain an `f32` for example (you can still manually implement the trait, though, and decide in favour of a loss of precision). Should we also provide some traits for transparent loss of precision? - Currently, you cannot convert between types, so if the JS struct has an integer, you cannot cast it to a boolean, for example. Should we provide a `TryConvertJs` trait, for example to force conversions? - Currently we only have basic types and object conversions. Should add `Array` to `Vec` conversion, for example, right? Should we also add `TypedArray` conversions? What about `Map` and `Set`? Does this step over the fine grained APIs that we were creating? Note that this still requires a bunch of documentation, tests, and validation from the dev team and from the users that requested this feature. I'm particularly interested in @lastmjs's thoughts on this API. I already added an usage example in `boa_examples/src/bin/derive.rs`. Co-authored-by: jedel1043 <jedel0124@gmail.com>
2 years ago
"boa_examples",
"boa_gc",
Initial version of a JS -> Rust conversion trait. (#2276) This Pull Request closes #1975. It's still a work in progress, but tries to go in that direction. It changes the following: - Adds a new `TryFromJs` trait, that can be derived using a new `boa_derive` crate. - Adds a new `try_js_into()` function that, similarly to the standard library `TryInto` trait Things to think about: - Should the `boa_derive` crate be re-exported in `boa_engine` using a `derive` feature, similar to how it's done in `serde`? - The current implementation only converts perfectly valid values. So, if we try to convert a big integer into an `i8`, or any floating point number to an `f32`. So, you cannot derive `TryFromJs` for structures that contain an `f32` for example (you can still manually implement the trait, though, and decide in favour of a loss of precision). Should we also provide some traits for transparent loss of precision? - Currently, you cannot convert between types, so if the JS struct has an integer, you cannot cast it to a boolean, for example. Should we provide a `TryConvertJs` trait, for example to force conversions? - Currently we only have basic types and object conversions. Should add `Array` to `Vec` conversion, for example, right? Should we also add `TypedArray` conversions? What about `Map` and `Set`? Does this step over the fine grained APIs that we were creating? Note that this still requires a bunch of documentation, tests, and validation from the dev team and from the users that requested this feature. I'm particularly interested in @lastmjs's thoughts on this API. I already added an usage example in `boa_examples/src/bin/derive.rs`. Co-authored-by: jedel1043 <jedel0124@gmail.com>
2 years ago
"boa_icu_provider",
"boa_interner",
Initial version of a JS -> Rust conversion trait. (#2276) This Pull Request closes #1975. It's still a work in progress, but tries to go in that direction. It changes the following: - Adds a new `TryFromJs` trait, that can be derived using a new `boa_derive` crate. - Adds a new `try_js_into()` function that, similarly to the standard library `TryInto` trait Things to think about: - Should the `boa_derive` crate be re-exported in `boa_engine` using a `derive` feature, similar to how it's done in `serde`? - The current implementation only converts perfectly valid values. So, if we try to convert a big integer into an `i8`, or any floating point number to an `f32`. So, you cannot derive `TryFromJs` for structures that contain an `f32` for example (you can still manually implement the trait, though, and decide in favour of a loss of precision). Should we also provide some traits for transparent loss of precision? - Currently, you cannot convert between types, so if the JS struct has an integer, you cannot cast it to a boolean, for example. Should we provide a `TryConvertJs` trait, for example to force conversions? - Currently we only have basic types and object conversions. Should add `Array` to `Vec` conversion, for example, right? Should we also add `TypedArray` conversions? What about `Map` and `Set`? Does this step over the fine grained APIs that we were creating? Note that this still requires a bunch of documentation, tests, and validation from the dev team and from the users that requested this feature. I'm particularly interested in @lastmjs's thoughts on this API. I already added an usage example in `boa_examples/src/bin/derive.rs`. Co-authored-by: jedel1043 <jedel0124@gmail.com>
2 years ago
"boa_macros",
"boa_macros_tests",
"boa_parser",
"boa_profiler",
"boa_runtime",
"boa_tester",
"boa_wasm",
]
[workspace.package]
edition = "2021"
version = "0.17.0"
rust-version = "1.71.0"
authors = ["boa-dev"]
repository = "https://github.com/boa-dev/boa"
license = "Unlicense OR MIT"
description = "Boa is a Javascript lexer, parser and compiler written in Rust. Currently, it has support for some of the language."
[workspace.dependencies]
# Repo Crates
boa_ast = { version = "~0.17.0", path = "boa_ast" }
boa_engine = { version = "~0.17.0", path = "boa_engine" }
boa_gc = { version = "~0.17.0", path = "boa_gc" }
boa_icu_provider = { version = "~0.17.0", path = "boa_icu_provider" }
boa_interner = { version = "~0.17.0", path = "boa_interner" }
boa_macros = { version = "~0.17.0", path = "boa_macros" }
boa_parser = { version = "~0.17.0", path = "boa_parser" }
boa_profiler = { version = "~0.17.0", path = "boa_profiler" }
boa_runtime = { version = "~0.17.0", path = "boa_runtime" }
# Shared deps
arbitrary = "1"
bitflags = "2.4.1"
chrono = { version = "0.4.31", default-features = false }
clap = "4.4.6"
colored = "2.0.4"
fast-float = "0.2.0"
hashbrown = { version = "0.14.1", default-features = false }
indexmap = { version = "2.0.2", default-features = false }
indoc = "2.0.4"
jemallocator = "0.5.4"
num-bigint = "0.4.4"
num-traits = "0.2.17"
once_cell = { version = "1.18.0", default-features = false }
phf = { version = "0.11.2", default-features = false }
pollster = "0.3.0"
regex = "1.10.1"
regress = "0.7.1"
rustc-hash = { version = "1.1.0", default-features = false }
serde_json = "1.0.107"
serde = "1.0.189"
static_assertions = "1.1.0"
textwrap = "0.16.0"
thin-vec = "0.2.12"
# ICU4X
icu_provider = { version = "~1.3.1", default-features = false }
icu_locid = { version = "~1.3.2", default-features = false }
icu_locid_transform = { version = "~1.3.1", default-features = false }
icu_datetime = { version = "~1.3.2", default-features = false }
icu_calendar = { version = "~1.3.2", default-features = false }
icu_collator = { version = "~1.3.2", default-features = false }
icu_plurals = { version = "~1.3.0", default-features = false }
icu_list = { version = "~1.3.2", default-features = false }
icu_casemap = { version = "~1.3.2", default-features = false }
icu_segmenter = { version = "~1.3.2", default-features = false }
icu_datagen = { version = "~1.3.0", default-features = false }
icu_provider_adapters = { version = "~1.3.0", default-features = false }
icu_provider_blob = { version = "~1.3.2", default-features = false }
icu_properties = { version = "~1.3.0", default-features = true }
writeable = "~0.5.3"
yoke = "~0.7.2"
zerofrom = "~0.1.3"
fixed_decimal = "~0.5.4"
[workspace.metadata.workspaces]
allow_branch = "main"
# The ci profile, designed to reduce size of target directory
[profile.ci]
inherits = "dev"
debug = false
incremental = false
# The release profile, used for `cargo build --release`.
[profile.release]
# Enables "fat" LTO, for faster release builds
lto = "fat"
# Makes sure that all code is compiled together, for LTO
codegen-units = 1
[profile.release-dbg]
inherits = "release"
debug = true
# The test profile, used for `cargo test`.
[profile.test]
# Enables thin local LTO and some optimizations.
opt-level = 1
# The benchmark profile, used for `cargo bench`.
[profile.bench]
# Enables "fat" LTO, for faster benchmark builds
lto = "fat"
# Makes sure that all code is compiled together, for LTO
codegen-units = 1