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.

68 lines
1.9 KiB

[workspace]
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_unicode",
"boa_wasm",
]
[workspace.package]
edition = "2021"
version = "0.16.0"
rust-version = "1.66"
authors = ["boa-dev"]
repository = "https://github.com/boa-dev/boa"
license = "Unlicense/MIT"
description = "Boa is a Javascript lexer, parser and compiler written in Rust. Currently, it has support for some of the language."
[workspace.dependencies]
boa_ast = { version = "0.16.0", path = "boa_ast" }
boa_engine = { version = "0.16.0", path = "boa_engine" }
boa_gc = { version = "0.16.0", path = "boa_gc" }
boa_icu_provider = { version = "0.16.0", path = "boa_icu_provider" }
boa_interner = { version = "0.16.0", path = "boa_interner" }
boa_macros = { version = "0.16.0", path = "boa_macros" }
boa_parser = { version = "0.16.0", path = "boa_parser" }
boa_profiler = { version = "0.16.0", path = "boa_profiler" }
boa_runtime = { version = "0.16.0", path = "boa_runtime" }
boa_unicode = { version = "0.16.0", path = "boa_unicode" }
[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
# 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