* Remove direct conversion from `&str` to `JsValue`/`PropertyKey`.
* Allow unused static strings
* Introduce DHAT to benchmark data usage
* Create new release profile
* Fix docs
This Pull Request fixes/closes #718.
It changes the following:
- Adds a new `boa_runtime` crate, that will only include `console` for now
- Changes the `boa_cli` crate to use the new `boa_runtime` crate for the console, instead of the `console` feature of `boa_engine`
- Removes the `console` feature in `boa_engine`
- Adds a new `boa_testing` helper crate with some useful functions for testing `boa`. This part duplicates the code from `boa_engine`, but I could not make `boa_engine` work with this crate as a dependency due to circular dependencies. Maybe doing it a bit generic could work, but didn't have enough time to check it.
To be checked: wether the WASM example works as expected with the console.
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>
It changes the following:
- Remove Just-in-time compilation from description in `Cargo.toml`
- Change `FlowgraphFormat` to be terminal friendly
- Update `README.md` cli options section
This Pull Request fixes/closes #1180. (I'll open a tracking issue for the progress)
It changes the following:
- Redesigns the internal API of Intl to (hopefully!) make it easier to implement a service.
- Implements the `Intl.Locale` service.
- Implements the `Intl.Collator` service.
- Implements the `Intl.ListFormat` service.
On the subject of the failing tests. Some of them are caused by missing locale data in the `icu_testdata` crate; we would need to regenerate that with the missing locales, or vendor a custom default data.
On the other hand, there are some tests that are bugs from the ICU4X crate. The repo https://github.com/jedel1043/icu4x-test262 currently tracks the found bugs when running test262. I'll sync with the ICU4X team to try to fix those.
cc @sffc
This Pull Request updates the codebase to the newest version of rustc (1.65.0).
It changes the following:
- Bumps `rust-version` to 1.65.0.
- Rewrites some snippets to use the new let else, ok_or_else and some other utils.
- Removes the `rustdoc::missing_doc_code_examples` allow lint from our codebase. (Context: https://github.com/rust-lang/rust/pull/101732)
This should hopefully improve our compilation times, both from a clean build and from an incremental compilation snapshot.
Next would be the parser, but it imports `Context`, so it'll require a bit more work.
The number of file changes is obviously big, but almost nothing was changed, I just moved everything to another crate and readjusted the imports of the `parser` module. (Though, I did have to change some details, because there were some functions on the ast that returned `ParseError`s, and the tests had to be moved to the parser)
Currently we run 7 different jobs:
- tests linux
- tests macos
- tests windows
- rustfmt
- clippy
- examples
- documentation
With this change I reduced them to 4 and hopefully sped them up.
The total execution time is limited by the tests, especially linux that calculates coverage. Having separate jobs for clippy and rustfmt (which take a very small amount of time) is a waste of energy.
With this PR:
Introduced a new cargo profile, `ci`, that should create smaller sized binaries and reduce the our cache usage.
I changed the test runner for macos and windows to [nextest](https://nexte.st/), which should be faster and is specifically designed for CI.
I merged all smaller tasks in a single job, misc, the steps clearly identify what is being tested so it shouldn't affect clarity.
Switched to using the [rust-cache](https://github.com/Swatinem/rust-cache) GH action, this simplifies our work by no longer having to worry about which directories to cache, rust-cache handles all that for us.
~~The bors task should also be modified, I'll get to it as soon as I have time. I believe it should be possible for us to have a single workflow described and have it both be the normal CI and the bors test.~~
I think it's time to address the elephant in the room.
This Pull Request will (hopefully!) solve part of #736.
This is a complete rewrite of `JsString`, but instead of storing `u8` bytes it stores `u16` words. The `encode!` macro (renamed to `utf16!` for simplicity) from the `const-utf16` crate allows us to create UTF-16 encoded arrays at compilation time. `JsString` implements `Deref<Target=[u16]>` to unlock the slice methods and possibly make some manipulations easier. However, we would need to create our own library of utilities for `JsString`.
This Pull Request switches our codebase to the brand new [workspace inherited keys](https://doc.rust-lang.org/cargo/reference/workspaces.html#the-package-table), which allows us to define common package options that are usable within each crate's Cargo.toml file.
It also allows to share dependency versions between crates, but I defined only shared versions for our workspace members. It would be a good follow-up to lift all the shared dependencies between crates into the global Cargo.toml.
This adds cargo-workspaces to our repo for easier publishing.
(I think we may need to do a dry run of this first to test)
fixes https://github.com/boa-dev/boa/issues/2001
Iban Eguia Moraza
dependabot[bot]
José Julián Espina
Kevin
Andrea Frigido
Haled Odat
raskad
João Borges
Jason Williams