This PR changes the following:
- Modifies `EphemeronBox` to be more akin to `GcBox`, with its own header, roots and markers. This also makes it more similar to [Racket's](https://docs.racket-lang.org/reference/ephemerons.html) implementation.
- Removes `EPHEMERON_QUEUE`.
- Ephemerons are now tracked on a special `weak_start` linked list, instead of `strong_start` which is where all other GC boxes live.
- Documents all unsafe blocks.
- Documents our current garbage collection algorithm. I hope this'll clarify a bit what exactly are we doing on every garbage collection.
- Renames/removes some functions.
This PR is a complete redesign of our current native functions and closures API.
I was a bit dissatisfied with our previous design (even though I created it 😆), because it had a lot of superfluous traits, a forced usage of `Gc<GcCell<T>>` and an overly restrictive `NativeObject` bound. This redesign, on the other hand, simplifies a lot our public API, with a simple `NativeCallable` struct that has several constructors for each type of required native function.
This new design doesn't require wrapping every capture type with `Gc<GcCell<T>>`, relaxes the trait requirement to `Trace + 'static` for captures, can be reused in both `JsObject` functions and (soonish) host defined functions, and is (in my opinion) a bit cleaner than the previous iteration. It also offers an `unsafe` API as an escape hatch for users that want to pass non-Copy closures which don't capture traceable types.
Would ask for bikeshedding about the names though, because I don't know if `NativeCallable` is the most precise name for this. Same about the constructor names; I added the `from` prefix to all of them because it's the "standard" practice, but seeing the API doesn't have any other method aside from `call`, it may be better to just remove the prefix altogether.
Let me know what you think :)
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
Per the [Standard Library development guide](https://std-dev-guide.rust-lang.org/code-considerations/performance/inline.html):
> You can add `#[inline]`:
>
> - To public, small, non-generic functions.
>
> You shouldn't need `#[inline]`:
> - On methods that have any generics in scope.
> - On methods on traits that don't have a default implementation.
>
> `#[inline]` can always be introduced later, so if you're in doubt they can just be removed.
This PR follows this guideline to reduce the number of `#[inline]` annotations in our code, removing the annotation in:
- Non-public functions
- Generic functions
- Medium and big functions.
Hopefully this shouldn't impact our perf at all, but let's wait to see the benchmark results.
<!---
Thank you for contributing to Boa! Please fill out the template below, and remove or add any
information as you feel necessary.
--->
Submitting this as a draft for feedback/second opinions. This draft contains some changes to the documentation.
Quick Overview:
- Potential `Boa` header for Boa's crates added to `boa_engine`.
- Changes the wording to a lot of module headers (See `builtins` module and `object/builtins` module).
- Updating built-in wrapper's code examples to use `?` operator.
- Adds the doc logo URL to a few crates that didn't have it.
The main idea of this draft is to move away from the "This module implements" wording as it feels a bit duplicative when listed under the Modules section (mainly focusing around changes in `boa_engine` to start).
While working on this, I had a question about whether we should be using JavaScript or ECMAScript in the Boa's documentation. We do seem to currently use both, and this draft uses JavaScript heavily in the wording.
<!---
Thank you for contributing to Boa! Please fill out the template below, and remove or add any
information as you feel necessary.
--->
This Pull Request fixes the current issue with the `boa_gc` when running `boa_tester` in parallel on Ubuntu. It looks like since we are running the `gc` in parallel something may not being cleaned up correctly that creates a reference cycle. The below changes should account for that.
It changes the following:
- Updates `weak_trace` to account for `Gc` reference cycles.
This Pull Request restructures the lint deny/warn/allow lists in almost all crates. `boa_engine` will be done in a follow up PR as the changes there are pretty extensive.
<!---
Thank you for contributing to Boa! Please fill out the template below, and remove or add any
information as you feel necessary.
--->
Not sure if anyone else may be working on something more substantial/in-depth, but I thought I'd post this. 😄
The basic rundown is that this is more of an untested (and in some ways naïve) draft than anything else. It builds rather heavily on `rust-gc`, and tries to keep plenty of the core aspects so as to not break anything too much, and also to minimize overarching changes were it to actually be merged at some point.
This implementation does add ~~a generational divide (although a little unoptimized) to the heap,~~ a GcAlloc/Collector struct with methods, and an ephemeron implementation that allows for the WeakPair and WeakGc pointers.
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.
So, @raskad and myself had a short discussion about the state of #736, and we came to the conclusion that it would be a good time to implement our own string interner; partly because the `string-interner` crate is a bit unmaintained (as shown by https://github.com/Robbepop/string-interner/pull/42 and https://github.com/Robbepop/string-interner/pull/47), and partly because it would be hard to experiment with custom optimizations for UTF-16 strings. I still want to thank @Robbepop for the original implementation though, because some parts of this design have been shamelessly stolen from it 😅.
Having said that, this PR is a complete reimplementation of the interner, but with some modifications to (hopefully!) make it a bit easier to experiment with UTF-16 strings, apply optimizations, and whatnot :)
<!---
Thank you for contributing to Boa! Please fill out the template below, and remove or add any
information as you feel neccesary.
--->
This Pull Request integrates an `ICU4X` data provider API in our codebase, to make use of the internationalization APIs that this crate provides.
It changes the following:
- Creates an API for pluggable icu data providers at `Context` creation, adding an `Icu` struct to store the provider (and some other internationalization tools) at runtime.
- Slightly changes locale related functions to preserve the `Locale` type and ensure correctness. (Will make some other changes related to this).
- Integrates the `sys_locale` crate to fetch the current default locale of an user instead of always returning `en-US`.
This Pull Request closes#1948.
It changes the following:
- set `readme` in `boa_engine` so `README.md` will be published to crates.io
- remove unnecessary `exclude` field from `Cargo.toml` in all apps
I was unsure whether using a path outside of the workspace root was allowed for `readme` since it [doesn't get included in the release tarball](https://github.com/rust-lang/cargo/issues/5911), but this exact path is used by [juniper](https://github.com/graphql-rust/juniper/blob/master/juniper/Cargo.toml#L13) and [seems to work there](https://crates.io/crates/juniper). I believe `cargo publish` does a bit more than just uploading the tarball, including pulling the `readme` from any arbitrary path.
The default behaviour of `cargo package`/`cargo publish` if neither `exclude` or `include` is specified is to include all files from the package root, excluding
- dotfiles
- .gitignore'd files
- subpackages (any subdirectory with a `Cargo.toml` file)
- the `/target` directory
There's no need to explicitly exclude files from the parent directory since they're already excluded by default. This can be verified by running `cargo package --list` inside any workspace app:
```plain
$ cd boa_wasm
$ cargo package --list
.gitignore
Cargo.toml
Cargo.toml.orig
src/lib.rs
```
You can read more [here](https://doc.rust-lang.org/cargo/reference/manifest.html#the-exclude-and-include-fields).
raskad
José Julián Espina
Kevin
Iban Eguia
dependabot[bot]
Aaron Ross
Jason Williams