|
|
|
|
[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.0"
|
|
|
|
|
chrono = { version = "0.4.31", default-features = false }
|
|
|
|
|
clap = "4.4.5"
|
|
|
|
|
colored = "2.0.4"
|
|
|
|
|
fast-float = "0.2.0"
|
|
|
|
|
hashbrown = { version = "0.14.0", default-features = false }
|
|
|
|
|
indexmap = "2.0.1"
|
|
|
|
|
indoc = "2.0.4"
|
|
|
|
|
jemallocator = "0.5.4"
|
|
|
|
|
num-bigint = "0.4.4"
|
|
|
|
|
num-traits = "0.2.16"
|
|
|
|
|
once_cell = { version = "1.18.0", default-features = false }
|
|
|
|
|
phf = { version = "0.11.2", default-features = false }
|
|
|
|
|
pollster = "0.3.0"
|
|
|
|
|
regex = "1.9.5"
|
|
|
|
|
regress = "0.7.1"
|
|
|
|
|
rustc-hash = { version = "1.1.0", default-features = false }
|
|
|
|
|
serde_json = "1.0.107"
|
|
|
|
|
serde = "1.0.188"
|
|
|
|
|
static_assertions = "1.1.0"
|
|
|
|
|
textwrap = "0.16.0"
|
|
|
|
|
thin-vec = "0.2.12"
|
|
|
|
|
|
|
|
|
|
# ICU4X
|
|
|
|
|
|
|
|
|
|
icu_provider = { version = "~1.3.0", default-features = false }
|
|
|
|
|
icu_locid = { version = "~1.3.0", default-features = false }
|
|
|
|
|
icu_locid_transform = { version = "~1.3.0", default-features = false }
|
|
|
|
|
icu_datetime = { version = "~1.3.0", default-features = false }
|
|
|
|
|
icu_calendar = { version = "~1.3.0", default-features = false }
|
|
|
|
|
icu_collator = { version = "~1.3.0", default-features = false }
|
|
|
|
|
icu_plurals = { version = "~1.3.0", default-features = false }
|
|
|
|
|
icu_list = { version = "~1.3.0", default-features = false }
|
|
|
|
|
icu_casemap = { version = "~1.3.0", default-features = false }
|
|
|
|
|
icu_segmenter = { version = "~1.3.0", 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.0", default-features = false }
|
|
|
|
|
icu_properties = { version = "~1.3.0", default-features = false }
|
|
|
|
|
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
|
