This Pull Request changes the following:
- Creates a new `PromiseCapability` after every async function call instead of sharing the same capability for all calls of the same async function.
The new ICU4X release stabilized the `icu_segmenter` component, so this PR implements `Intl.Segmenter` using that as a base.
Also, I opted for importing `itertools` instead of copy-pasting the implementation of `TupleWindows` because its design is a lot more complex than `Intersperse`, which we copy-pasted previously. Though, I disabled all `std` features of `itertools` to make it a lot more lightweight, so it shouldn't make much difference in compilation times.
Depends on #2837.
This Pull Request changes the following:
- Fix the remaining `language/expressions/yield` tests.
- Align the sync generator execution more to the spec.
This breaks one async generator test. We can ignore that one as async generators are currently very broken. I will try to fix async generators next.
This Pull Request fixes some additional Annex B tests.
It changes the following:
- Fixes bugs related to parsing HTML closing comments (`-->`).
- Implements `RegExp::compile` behind the `annex-b` feature.
- Ignores the `legacy-regexp` feature flag, since it's still stage 3.
This PR upgrades ICU to 1.2.
Unfortunately we still have some breaking changes, so this is being handled in https://github.com/unicode-org/icu4x/issues/3332
Co-authored-by: jedel1043 <jedel0124@gmail.com>
Just some small improvements that increase the strictness of our generator state handling.
Also rollbacks the implementation of `GeneratorValidate` because I forgot to remove it after I did modifications to #2821, and it doesn't make sense to have that if it isn't used by async functions.
This Pull Request changes the following:
- Adds two new hooks to `HostHooks` to access the current UTC time and the current timezone offset.
- Replaces usages of `Local` with the host hook.
- Replaces usages of `Utc::now` and `Local::now` with the hooks.
cc @lastmjs
This fixes some more ES5 tests that were failing because the functions haven't been implemented.
It changes the following:
- Adds `String::to_locale_case`, which uses ICU4X to convert strings to uppercase or lowercase.
- Refactors `String::to_uppercase` and `String::to_lowercase` into a single `String::to_case` which uses a const generic to distinguish each case.
- Adds utility functions on `JsString` to avoid code repetition.
This should hopefully fix more async/futures issues related to resuming execution in the future, since we can leverage generator logic to handle this for us.
It changes the following:
- Refactors `GeneratorContext` to handle context preparation.
- Reuses the functionality of `GeneratorContext` in `Await`.
- Removes `EarlyReturnType` in favour of a single `r#await` bool flag in `CallFrame`.
Small steps towards ES5 conformance.
This PR changes the following:
- Implements HTML comments parsing (`<!--`, `-->`).
- Gates the functionality behind a new `annex-b` feature for `boa_parser`.
- Renames `strict_mode` to `strict` to be consistent with `Parser::set_strict`.
This allows `thread_local` contexts to have owned `HostHooks` and `JobQueues`.
It changes the following:
- Creates a new `MaybeShared` struct that can hold either a reference or an `Rc`.
- Changes the `job_queue` and `host_hooks` parameters of `Context` to use `MaybeShared`.
This PR also allows us to make `SimpleJobQueue` the default promise runner, which I think it's pretty cool :)
cc @lastmjs
This Pull Request lifts the `InternalObjectMethods` vtable from `Object`, which should technically improve performance, since we now won't need to call `borrow` to use any of the internal methods, but let's see what the benchmarks show.
It changes the following:
- Adds a new `VTableObject` struct, containing the old `GcRefCell<Object>` and the lifted `InternalObjectMethods`.
- Changes the definition of `JsObject` to `Gc<VTableObject>`. Note that this means the `InternalObjectMethods` are accessible through the `Gc` pointer.
- Reestructures intrinsic initialization and initialization APIs to accommodate this change.
This change allows using built-in `JsObject` wrappers with the `TryFromJs` logic, which makes it easier to derive it in complex objects containing known built-ins, being able to use all the power of the wrappers even inside complex structures.
It changes the following:
* Implements `TryFromJs` for all `JsObject` wrappers ~, except for `JsProxy` and `Js<Int>Array` wrappers~ -> This has now been added.
* Adds checker functions for individual typed array objects.
* Adds some missing checker functions from `Object` to `JsObject`
~The reason for not implementing it for `JsProxy` is that we don't have a way (as far as I can tell) to know if a `JsObject` is a `Proxy` object. The reason for the typed arrays (note that `JsTypedArray` implements `TryFromJs`) is that I didn't find an easy way to know which type of typed array a `JsObject` was. Do we have a way of using a `JsObject` to create a Rust `JsUint8Array` or the like?~
This Pull Request changes the following:
- Fix the assignment of variables in destructive for-of initializers.
- Fix the environment handling in the compilation of `for-of/in` loops.
- Close iterators in destructive for-of loop assignments, when the code throws during the assignment.
With this and #2805 , `annex-b/builtins/string` should have 100% conformance, also fixed the `normalize` method incorrect `length` value, which was the last failing tests in `normalize` test suite
Fixes the remaining failing tests on `String.prototype.substr()`
It changes the following:
- Fixes the remaining failing tests on `String.prototype.substr()
- Move `substr` under the `"annex-b"` feature flag.
Implements all Annex-B string html methods, they are deprecated but still part of the ES5 spec. They have been feature gated under the `"annex-b"` feature flag
This Pull Request fixes#2317 and #1835, finally giving our engine proper realms 🥳.
It changes the following:
- Extracts the compile environment stack from `Realm` and into `Vm`.
- Adjusts the bytecompiler to accommodate this change.
- Adjusts `call/construct_internal` to accommodate this change. This also coincidentally fixed#2317, which I'm pretty happy about.
- Adjusts several APIs (`NativeJob`, `Realm`) and builtins (`eval`, initializers) to accommodate this change.
- Adjusts `JsNativeError`s to hold a reference to the Realm from which they were created. This only affects errors created within calls to function objects. Native calls don't need to set the realm because it's inherited by the next outer active function object. TLDR: `JsError` API stays the same, we just set the origin Realm of errors in `JsObject::call/construct_internal`.
It changes the following:
- Fixes`Symbol.prototype[@@iterator]` so it calls `RequireObjectCoercible` and then `ToString`
- Makes string iterator store a `JsString` which should be faster, instead of `JsValue` then calling `ToString` on every iteration
This Pull Request fixes test [`assert-throws-same-realm.js`](eb44f67274/test/harness/assert-throws-same-realm.js).
It changes the following:
- Handles global variables through the global object, instead of the `context`.
- Adds an `active_function` field to the vm, which is used as the `NewTarget` when certain builtins aren't called with `new`.
- Adds a `realm_intrinsics` field to `Function`.
Currently some debugging stuff in JavaScript land is difficult to impossible, like triggering a GC collect, this is not impossible to do in JavaScript the way I triggered it was by creating a huge amount of object `for (let i = 0; i < 100000; ++i) { ({}) }` but this is cumbersome and not guaranteed to trigger a gc.
This PR implements `--debug-object` flag that injects the `$boa` debug object in the context, the object is separated into modules currently `gc`, `function`, `object`.
We can now do `$boa.gc.collect()`, which force triggers a GC collect.
Or sometimes I wanted a trace (the current solution is great, you can trace stuff like `>>> 1 + 1` but that is also it's limitation), it traces everything, I sometimes have a scenario and just want to trace a single function in that scenario, that's why I added the `$boa.function.trace(func, this, ...args)` It only traces the function.
```js
>> $boa.function.trace((a, b) => a + b, undefined, 1, 2)
-------------------------Compiled Output: ''--------------------------
Location Count Opcode Operands
000000 0000 DefInitArg 0000: 'a'
000005 0001 DefInitArg 0001: 'b'
000010 0002 RestParameterPop
000011 0003 GetName 0000: 'a'
000016 0004 GetName 0001: 'b'
000021 0005 Add
000022 0006 Return
000023 0007 PushUndefined
000024 0008 Return
... (cut for brevity) ...
```
It also implements `$boa.function.flowgraph(func, options)`:
```js
$boa.function.flowgraph(func, 'graphviz')
$boa.function.flowgraph(func, { format: 'mermaid', direction: 'TopBottom' })
```
Printing the object pointer:
```js
$boa.object.id({}) // '0x566464F33'
```
It currently implements some functionality which we can grow it with our debugging needs since we are not restricted by a spec we can add whatever we want :)
I was originally going to implement this in #2723 (but the PR is too big), for shapes having functions like:
```js
$boa.shape.type({}) // Shared shape
$boa.shape.id({}) // 0x8578FG355 (objects, shape pointer)
$boa.shape.flowgraph({}) // printing the shape transition chain, like $boa.function.flowgraph
```
Shapes chains are very hard to debug once they are big... so having this type of debugging capability would make it much easier.
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>
Currently we have no explicit representation for parenthesized expressions which makes some behaviours impossible to detect. A bonus is that we can now turn AST that contains parenthesized expressions back to code.
This Pull Request changes the following:
- Add an AST node for parenthesized expressions.
- Adjust some conversions and checks to "ignore"/"expand" parenthesized expressions.
- Fix some tests that had parenthesized expressions.
Most objects don't have indexed properties, and those who have, have dense properties, this PR uses `ThinVec` to reduce the size of dense properties.
It changes the following:
- Trim `16` bytes from `IndexedProperties`, this reduces all objects size
This PR implements an optimizer, It currently implements the [constant folding optimization][cfo]. this optimization is responsible for "folding"/evaluating constant expressions.
For example:
```js
let x = ((1 + 2 + -4) * 8) << 4
```
Generates the following instruction(s) (`cargo run -- -t`):
```
000000 0000 PushOne
000001 0001 PushInt8 2
000003 0002 Add
000004 0003 PushInt8 4
000006 0004 Neg
000007 0005 Add
000008 0006 PushInt8 8
000010 0007 Mul
000011 0008 PushInt8 4
000013 0009 ShiftLeft
000014 0010 DefInitLet 0000: 'x'
```
With constant folding it generates the following instruction(s) (`cargo run -- -t -O`):
```
000000 0000 PushInt8 -128
000002 0001 DefInitLet 0000: 'x'
```
It changes the following:
- Implement ~~WIP~~ constant folding optimization, ~~only works with integers for now~~
- Add `--optimize, -O` flag to boa_cli
- Add `--optimizer-statistics` flag to boa_cli for optimizer statistics
- Add `--optimize, -O` flag to boa_tester
After I finish with this, will try to implement other optimizations :)
[cfo]: https://en.wikipedia.org/wiki/Constant_folding
This Pull Request fixes/closes #2672.
It changes the following:
- Get the super constructor and the new target before executing arguments in super calls.
This Pull Request closes#2687.
It changes the following:
- Adds a `JsPromise` wrapper to manipulate promises from Rust.
- Cleans up the `promise` module to ease the integration of `JsPromise` with it.
cc @lastmjs
The fields like `[[PrivateElements]]` are hardly used but they occupy `24` bytes (on 64-bit arch.) the `ThinVec` type stores the `len` and `cap` right before the elements (like our `JsString` implementation) and only a pointer is kept (if not used it does not allocate!), was going to use this in #2723 , since it uses a `Vec` as a dense storage, but the PR is already too big.
It changes the following:
- Shrink object from `328` to `288` bytes (40 bytes reduction)
- Add the `thin_vec` lightweight crate (single file)
This PR changes the following:
- Adds a new (very simple) security policy, to comply with GitHub standards
- Changes the internal links of the documentation to point to the new boajs.dev domain
- The developer documentation link now lies in the CONTRIBUTING.md file
Currently update expressions get values multiple times. This can lead to multiple executions of object property getters.
This is very similar to #2551. Unfortunateley it seems like we have to sacrifice some code duplication for correctness in these cases. But that is probably for the best, as we can generate more optimized bytecode for each of these `get/set` cases.
This Pull Request changes the following:
- Add locking for `Set`s during iteration. We already do this for `Map`s.
- Properly implement negative zero handling for `add`, `has` and `delete`.
- Refactor some `Set` functions and add spec comments.
This Pull Request fixes#2673.
It changes the following:
- Add early errors to dynamic function constructors.
- Add tests that check for syntax errors when `super` is passed to the function constructor.
~Depends on #2683.~ Merged.
This Pull Request fixes#2658.
It changes the following:
- Makes `for .. of` loop execution more spec compliant.
- Rewrites iterator related opcodes to be able to use it on all for .. of/in loops.
- Adds some utility op codes.
This PR adds the `"trace"` feature flag that enables vm opcode tracing (off by default), most users aren't interested in tracing/debugging that's why I think it should be made out-in.
This Pull Request changes the following:
- Implement `with` statement parsing, ast node, compilation and excution.
- Implement object environments that are used in the `with` statement excution.
The implementation of object environments can probably be optimized further by using more compile-time information about when object environments can exist. Maybe there could also be a separate environment stack for object environments to reduce the filtering and iteration that is needed with the current implementation.
This does not fix all tests in the `test/language/statements/with` suite yet. But for most failing tests that I have looked at we are missing other features / have bugs elsewhere.
As a note for the review:
The functions in the `impl Context` block in `boa_engine/src/environments/runtime.rs` are mostly copied / moved from the existing functions. The only change there should be the addition of the object environment logic. They had to be moved to `Context` because of borrow semantics.
This Pull Request changes the following:
- Add the additional required condition in the Object constructor that checks if the `NewTarget` is the Object constructor itself.
José Julián Espina
raskad
Iban Eguia Moraza
Haled Odat