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
Added boa examples as per issue #446
Overtaken https://github.com/boa-dev/boa/pull/634
Somehow screwed that branch up by rebasing it and losing access
pings @elasmojs
This Pull Request fixes/closes #446 .
Co-authored-by: Jason Williams <jase.williams@gmail.com>
Co-authored-by: Iban Eguia (Razican) <razican@protonmail.ch>
Co-authored-by: jasonwilliams <jase.williams@gmail.com>
Co-authored-by: jedel1043 <jedel0124@gmail.com>
This Pull Request is part of #279.
It adds a string interner to Boa, which allows many types to not contain heap-allocated strings, and just contain a `NonZeroUsize` instead. This can move types to the stack (hopefully I'll be able to move `Token`, for example, maybe some `Node` types too.
Note that the internet is for now only available in the lexer. Next steps (in this PR or future ones) would include also using interning in the parser, and finally in execution. The idea is that strings should be represented with a `Sym` until they are displayed.
Talking about display. I have changed the `ParseError` type in order to not contain anything that could contain a `Sym` (basically tokens), which might be a bit faster, but what is important is that we don't depend on the interner when displaying errors.
The issue I have now is in order to display tokens. This requires the interner if we want to know identifiers, for example. The issue here is that Rust doesn't allow using a `fmt::Formatter` (only in nightly), which is making my head hurt. Maybe someone of you can find a better way of doing this.
Then, about `cursor.expect()`, this is the only place where we don't have the expected token type as a static string, so it's failing to compile. We have the option of changing the type definition of `ParseError` to contain an owned string, but maybe we can avoid this by having a `&'static str` come from a `TokenKind` with the default values, such as "identifier" for an identifier. I wanted for you to think about it and maybe we can just add that and avoid allocations there.
Oh, and this depends on the VM-only branch, so that has to be merged before :)
Another thing to check: should the interner be in its own module?
Also updated Cargo.toml to adapt it to the common license syntax,
and upgraded dependencies. I also had to remove the check for unsafe
code, but this might need some extra care (using a feature or something
in that sense).
Kevin
Andrea Frigido
José Julián Espina
Iban Eguia Moraza
Haled Odat
raskad
João Borges
Jason Williams
Jason Williams
Jevan Chan
Iban Eguia
Victor Tuekam
Jason Williams
Julian Laubstein
Jason Williams
Sophie Tauchert