This Pull Request is currently unfinished but will fix/close #1808 after some review and more work
It changes the following:
- Divides byte compiler logic into separate files
I would like some review on the current code I have to know if the patterns I'm using are acceptable for the codebase, if everything looks good I will try to separate more code into different small modules to finish the work here.
<!---
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.
This Pull Request changes the following:
- Remove false early error when a class expression was missing a binding identifier.
- Simplify/fix environment truncation on function returns.
The new failed tests where false positives before that will be fixed in another PR.
<!---
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 is related to the #2058 and the discussion in the discord chat.
It changes the following:
- Adds a `take` method to `JsArrayBuffer`
- Builds out `JsArrayBuffer` docs
- Adds a `JsArrayBuffer::take()` example to `jsarraybuffer.rs` in `boa_examples`
This Pull Request restructures the lint deny/warn/allow lists in `boa_engine`. It adds a lot of documentation to pup functions. There are still a few clippy lints that are not fixed, mainly regarding casting of number types. Fixing those lints effectiveley would in some cases probably require bigger refactors.
This should probably wait for #2449 to be merged, because that PR already fixes that lints regarding the `Date` built-in.
This PR is a WIP implementation of a vm instruction flowgraph generator
This aims to make the vm easier to debug and understand for both newcomers and experienced devs.
For example if we have the following code:
```js
let i = 0;
while (i < 10) {
if (i == 3) {
break;
}
i++;
}
```
It generates the following instructions (which is hard to read, especially jumps):
<details>
```
----------------------Compiled Output: '<main>'-----------------------
Location Count Opcode Operands
000000 0000 PushZero
000001 0001 DefInitLet 0000: 'i'
000006 0002 LoopStart
000007 0003 LoopContinue
000008 0004 GetName 0000: 'i'
000013 0005 PushInt8 10
000015 0006 LessThan
000016 0007 JumpIfFalse 78
000021 0008 PushDeclarativeEnvironment 0, 1
000030 0009 GetName 0000: 'i'
000035 0010 PushInt8 3
000037 0011 Eq
000038 0012 JumpIfFalse 58
000043 0013 PushDeclarativeEnvironment 0, 0
000052 0014 Jump 78
000057 0015 PopEnvironment
000058 0016 GetName 0000: 'i'
000063 0017 IncPost
000064 0018 RotateRight 2
000066 0019 SetName 0000: 'i'
000071 0020 Pop
000072 0021 PopEnvironment
000073 0022 Jump 7
000078 0023 LoopEnd
Literals:
<empty>
Bindings:
0000: i
Functions:
<empty>
```
</details>
And the flow graph is generated:
The beginning of the function is marked by the `start` node (in green) and end (in red). In branching the "yes" branch is marked in green and "no" in red.
~~This only generates in [graphviz format](https://en.wikipedia.org/wiki/DOT_(graph_description_language)) (a widely used format) but it would be nice to also generate to a format that `mermaid.js` can understand and that could be put in articles https://github.com/boa-dev/boa-dev.github.io/issues/26~~
TODO:
- [x] Generate graphviz format
- [x] Generate mermaid format
- [x] Programmatically generate colors push and pop env instructions
- [x] Display nested functions in sub-sub-graphs.
- [x] Put under a feature (`"flowgraph"`)
- [x] Handle try/catch, switch instructions
- [x] CLI option for configuring direction of flow (by default it is top down)
- [x] Handle `Throw` instruction (requires keeping track of try blocks)
- [x] Documentation
- [x] Prevent node name collisions (functions with the same name)
Just a general cleanup of the `Date` builtin to use slightly better patterns and to fix our warnings about deprecated functions.
About the regressed tests. It seems to be a `chrono` bug, so I opened up an issue (https://github.com/chronotope/chrono/issues/884) for it and they've already opened a PR fixing it (https://github.com/chronotope/chrono/pull/885).
However, while checking out the remaining failing tests, I realized there's a more fundamental limitation with the library. Currently, [`chrono`](https://github.com/chronotope/chrono) specifies:
> Date types are limited in about +/- 262,000 years from the common epoch.
While the [ECMAScript spec](https://tc39.es/ecma262/#sec-time-values-and-time-range) says:
> The smaller range supported by a time value as specified in this section is approximately -273,790 to 273,790 years relative to 1970.
The range allowed by the spec is barely outside of the range supported by `chrono`! This is why the remaining `Date` tests fail.
Seeing that, I would like to ping @djc and @esheppa (the maintainers of `chrono`) to ask if it would be feasible to add a feature, akin to the `large-dates` feature from the `time` crate, that expands the supported range of `chrono`.
EDIT: Filed https://github.com/chronotope/chrono/issues/886
This Pull Request offers a basic VM fuzzer which relies on implied oracles (namely, "does it crash or timeout?").
It changes the following:
- Adds an insns_remaining field to Context, denoting the number of instructions remaining to execute (only available when fuzzing)
- Adds a JsNativeError variant, denoting when the number of instructions has been exceeded (only available when fuzzing)
- Adds a VM fuzzer which looks for cases where Boa may crash on an input
This offers no guarantees about correctness, only assertion violations. Depends on #2400.
Any issues I raise in association with this fuzzer will link back to this fuzzer.
You may run the fuzzer using the following commands:
```bash
$ cd boa_engine
$ cargo +nightly fuzz run -s none vm-implied
```
Co-authored-by: Addison Crump <addison.crump@cispa.de>
<!---
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 PR adds a safe wrapper around JavaScript `JsDate` from `builtins::date`, and is being tracked at #2098.
#### Implements following methods
- [x] `new Date()`
- [x] `Date.prototype.getDate()`
- [x] `Date.prototype.getDay()`
- [x] `Date.prototype.getFullYear()`
- [x] `Date.prototype.getHours()`
- [x] `Date.prototype.getMilliseconds()`
- [x] `Date.prototype.getMinutes()`
- [x] `Date.prototype.getMonth()`
- [x] `Date.prototype.getSeconds()`
- [x] `Date.prototype.getTime()`
- [x] `Date.prototype.getTimezoneOffset()`
- [x] `Date.prototype.getUTCDate()`
- [x] `Date.prototype.getUTCDay()`
- [x] `Date.prototype.getUTCFullYear()`
- [x] `Date.prototype.getUTCHours()`
- [x] `Date.prototype.getUTCMilliseconds()`
- [x] `Date.prototype.getUTCMinutes()`
- [x] `Date.prototype.getUTCMonth()`
- [x] `Date.prototype.getUTCSeconds()`
- [x] `Date.prototype.getYear()`
- [x] `Date.now()`
- [ ] `Date.parse()` Issue 4
- [x] `Date.prototype.setDate()`
- [x] `Date.prototype.setFullYear()`
- [ ] `Date.prototype.setHours()` Issue 3
- [x] `Date.prototype.setMilliseconds()`
- [ ] `Date.prototype.setMinutes()` Issue 3
- [x] `Date.prototype.setMonth()`
- [x] `Date.prototype.setSeconds()`
- [x] `Date.prototype.setTime()`
- [x] `Date.prototype.setUTCDate()`
- [x] `Date.prototype.setUTCFullYear()`
- [x] `Date.prototype.setUTCHours()`
- [x] `Date.prototype.setUTCMilliseconds()`
- [x] `Date.prototype.setUTCMinutes()`
- [x] `Date.prototype.setUTCMonth()`
- [x] `Date.prototype.setUTCSeconds()`
- [x] `Date.prototype.setYear()`
- [ ] `Date.prototype.toDateString()` Issue 5
- [ ] `Date.prototype.toGMTString()` Issue 5
- [ ] `Date.prototype.toISOString()` Issue 5
- [ ] `Date.prototype.toJSON()` Issue 5
- [ ] `Date.prototype.toLocaleDateString()` Issue 5 and 6
- [ ] `Date.prototype.toLocaleString()` Issue 5 and 6
- [ ] `Date.prototype.toLocaleTimeString()` Issue 5 and 6
- [ ] `Date.prototype.toString()` Issue 5
- [ ] `Date.prototype.toTimeString()` Issue 5
- [ ] `Date.prototype.toUTCString()` Issue 5
- [x] `Date.UTC()`
- [x] `Date.prototype.valueOf()`
### Issues
1. ~~`get_*()` and some other methods - They take `&self` as input internally, and internal struct shouldn't be used in a wrapper API. Therefore, these would require input to be `this: &JsValue, args: &[JsValue], context: &mut Context` like others and use `this_time_value()`?~~ Fixed using `this_time_value()`
2. ~~`to_string()`- how can I use `Date::to_string()` rather than `alloc::string::ToString`.~~ My bad it compiles, just `rust-analyzer` was showing it as an issue.
3. `set_hours()` and `set_minutes()` - they subtract local timezones when setting the value, e.g.
- On further look:
```rust
// both function call `builtins:📅:mod.rs#L1038
this.set_data(ObjectData::date(t));
// `ObjectData::date` creates a new `Date` object `object::mods.rs#L423
// | this date is chrono::Date<Tz(TimezoneOffset)> and Tz default is being used here which is GMT+0
pub fn date(date: Date) -> Self {
Self {
kind: ObjectKind::Date(date),
internal_methods: &ORDINARY_INTERNAL_METHODS,
}
}
```
- BTW, in `object::mod.rs`'s `enum ObjectKind` there is `Date(chrono::Date)` and it requires
the generic argument, how is it being bypassed here?
- Also in `set_minutes()` step 6, `LocalTime` should be used.
```rust
// reference date = 2000-01-01T06:26:53.984
date.set_hours(&[23.into(), 23.into(), 23.into(), 23.into()], context)?;
// would add tiemzone(+5:30) to it
// Is 2000-01-01T17:53:23.023
// Should be 2000-01-01T23:23:23.023
```
4. `parse()` - it uses `chrono::parse_from_rfc3339` internally, while es6 spec recommends ISO8601. And it can also parse other formats like from [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse) `04 Dec 1995 00:12:00 GMT` which fails. So what should be done about it.
5. `to_*()` - This is more general, as the internal date object uses `chrono::NaiveDateTime` which doesn't have timezone. It doesn't account for `+4:00` in example below.
```rust
// Creates new `Date` object from given rfc3339 string.
let date = JsDate::new_from_parse(&JsValue::new("2018-01-26T18:30:09.453+04:00"), context);
println!("to_string: {:?}", date2.to_string(context)?);
// IS: Sat Jan 27 2018 00:00:09 GMT+0530
// Should: Fri Jan 26 2018 20:00:09 GMT+0530
```
6. `to_locale_*()` - requires [`ToDateTimeOptions`](https://402.ecma-international.org/9.0/#sec-todatetimeoptions) and localization would require chrono's `unstable-locales` feature, which is available for `DateTime` and not for `NaiveDateTime`.
- I should have looked properly, `to_date_time_options` is already implemented in `builtins::intl`. Anyway, I would still need some tips on how to use it. What would function signature be like in wrapper API, how would `options` be passed to the said API.
- So `to_date_time_options()` takes `options: &JsValue` as an argument and build an object from it and fetch properties through `Object.get()`. If I want `options` to be `{ weekday: 'long', year: 'numeric', month: 'long', day: 'numeric' }` what would `JsValue` look like to make it all work.
```rust
date.to_locale_date_string(&[JsValue::new("en_EN"), OPTIONS], context)?;
// OPTIONS need to be a JsValue which when converted into an object
// have these properties { weekday: 'long', year: 'numeric', month: 'long', day: 'numeric' };
```
### Possible improvements
1. Right now, `object::jsdate::set_full_year()` and alike (input is a slice) are like below, `into()` doesn't feel ergonomic.
```rust
#[inline]
pub fn set_full_year(&self, values: &[JsValue], context: &mut Context) -> JsResult<JsValue> {
Date::set_full_year(&self.inner.clone().into(), values, context)
}
// Usage
date.set_full_year(&[2000.into(), 0.into(), 1.into()], context)?;
// How can something like this be made to work
#[inline]
pub fn set_full_year<T>(&self, values: &[T], context: &mut Context) -> JsResult<JsValue>
where
T: Into<JsValue>,
{
| expected reference `&[value::JsValue]`
| found reference `&[T]`
Date::set_full_year(&self.inner.clone().into(), values, context)
}
```
2. Any other suggestion?
This PR adds an `OrAbrupt` trait, with the `or_abrupt()` function. This function is equivalent to the previous `?.ok_or(ParseError::AbruptEnd)`, but it's cleaner. It's implemented for the parser cursor results types.
It also adds an `advance()` function to the parser cursor (which might be possible to optimize further), that just advances the cursor without returning any token. This shows a clearer intent in many places where it's being used.
I also used `ParseResult` in more places, since we were not using it in many places.
This PR rewrites some patterns of the `JsString` implementation in order to pass all its miri tests. This can be verified by running:
```bash
cargo +nightly miri test -p boa_engine string::tests -- --skip builtins --skip parser
```
Basically, we were doing two operations that were Undefined Behaviour per the [Stacked Borrows](https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md) model:
- Casting `&JsString` to `&mut RawJsString` to `&[u16]`. The intermediate mutable borrow must not exist, or Miri considers this as Undefined Behaviour.
- Trying to access `RawJsString.data` using the dot operator. Miri complains with `this is a zero-size retag ([0x10..0x10]) so the tag in question does not exist anywhere`. To fix this, we can recompute the position of `data` every time we want to access it.
This PR rewrites all syntax-directed operations that find declared names and variables using visitors.
Hopefully, this should be the last step before finally being able to separate the parser from the engine.
I checked the failing [tests](85373b4ce1/test/language/statements/for-await-of/async-gen-decl-dstr-obj-prop-elem-target-yield-expr.js (L49)) and they're apparently false positives, since they return `Promise { <rejected> ReferenceError: x is not initialized }` on the main branch.
Right now our promises print `{ }` on display. This PR improves a bit the display and ergonomics of promises in general. Now, promises will print...
- When pending: `Promise { <pending> }`
- When fulfilled: `Promise { "hi" }`
- When rejected: `Promise { <rejected> ReferenceError: x is not initialized }`
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 Pull Request fixes#1805.
It changes the following:
- Implement async arrow function parsing and execution.
- Handle special case when a function expressions binding identifier need to be bound in the function body.
- Implement special silent ignored assignment for the above case.
- Fix issue with getting the correct promise capability for function returns.
- Complete function object `toString` todo.
I will fix the two failing assignmenttargettype tests in a follow up PR.
This Pull Request replaces `contains`, `contains_arguments`, `has_direct_super` and `function_contains_super` with visitors. (~1000 removed lines!)
Also, the new visitor implementation caught a bug where we weren't setting the home object of async functions, generators and async generators for methods of classes, which caused a stack overflow on `super` calls, and I think that's pretty cool!
Next is `var_declared_names`, `lexically_declared_names` and friends, which will be on another PR.
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)
This Pull Request closes no specific issue, but allows for analysis and post-processing passes by both internal and external developers.
It changes the following:
- Adds a Visitor trait, to be implemented by visitors of a particular node type.
- Adds `Type`Visitor traits which offer access to private members of a node.
- Adds an example which demonstrates the use of Visitor traits by walking over an AST and printing its contents.
At this time, the PR is more of a demonstration of intent rather than a full PR. Once it's in a satisfactory state, I'll mark it as not a draft.
Co-authored-by: Addison Crump <addison.crump@cispa.de>
This Pull Request implements `delete` for variable references:
```Javascript
x = 5;
console.log(x) // 5;
delete x;
console.log(x) // ReferenceError
```
It changes the following:
- Implements delete for references.
- Fixes tests related to deletions of function definitions inside `eval`.
- Implements an op to throw an error on super property deletion.
This puts us at a conformance of 97.98% for the `test/language/expressions/delete` suite. The last 2 failing tests are related to `with` statements ([11.4.1-4.a-5.js](b5d3192914/test/language/expressions/delete/11.4.1-4.a-5.js (L1)) and [11.4.1-4.a-6.js](b5d3192914/test/language/expressions/delete/11.4.1-4.a-6.js (L18))).
Fixes#1917 (fixes the code example given with the hashes)
Fixes the order dependent execution of assignment, so the following code works correctly:
```javascript
function f(x) { console.log(x) } // used to check the order of execution
let a = [[]]
(f(1), a)[(f(2), 0)][(f(3), 0)] = (f(4), 123) // 🤮
```
Prints out:
```bash
1
2
3
4
123
```
As expected
This introduces some opcodes:
- ~~`Swap3`: currently used only to keep some previous code working that needs refactoring.~~
- ~~`RotateRight n`: Rotates the `n` top values from the top of the stack to the right by `1`.~~ Already added by #2390
~~Besides the new opcodes,~~ Some opcodes pop and push order of values on the stack have been changed. To eliminate many swaps and to make this change easier.
~~This PR is still a WIP and needs more refactoring~~
This is now ready for review/merge :)
This Pull Request implements optional chains.
Example:
```Javascript
const adventurer = {
name: 'Alice',
cat: {
name: 'Dinah'
}
};
console.log(adventurer.cat?.name); // Dinah
console.log(adventurer.dog?.name); // undefined
```
Since I needed to implement `Opcode::RotateLeft`, and #2378 had an implementation for `Opcode::RotateRight`, I took the opportunity to integrate both ops into this PR (big thanks to @HalidOdat for the original implementation!).
This PR almost has 100% conformance for the `optional-chaining` test suite. However, there's this one [test](85373b4ce1/test/language/expressions/optional-chaining/member-expression.js) that can't be solved until we properly set function names for function expressions in object and class definitions.
<!---
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 is related to #2098.
It changes the following:
- Implements a wrapper for the `Generator` built-in object
- Adds to some of the documentation across the builtin wrappers with the goal of trying to clean up the documentation by making it a bit more consistent [on boa's docs](https://boa-dev.github.io/boa/doc/boa_engine/object/builtins/index.html)
This Pull Request allows collisions of var declarations with already existing lexical bindings if the `eval` call is strict or occurs within strict code. In short, it allows:
```Javascript
{
let x;
{
eval('"use strict"; var x;');
}
}
```
and
```Javascript
"use strict";
{
let x;
{
eval('var x;');
}
}
```
This is valid since in strict code all `eval` calls get their own function environment, making it impossible to declare a new var in the outer function environment. This change also skips poisoning environments on strict code, because `eval` cannot add new declarations for the current environment in that situation.
This Pull Request implements member accessors in `for ... in` and `for ... of` loops. This unlocks patterns like:
```Javascript
let obj = {a: 0, b: 1};
for (obj.a of [1,2,3]) {
}
console.log(obj.a) // 3
```
In most cases, the `ToInternedString` was just calling `self.to_indented_string(interner, 0)`. This avoids all this duplicate code by adding a new trait, `ToIndentedString`. Any type implementing that automatically implements `ToInternedString`.
I have also added a bunch of `#[inline]` in one-liners, and some one-line documentations for some functions.
I have noticed that we also use `contains()` and `contains_arguments()` a lot. Would it make sense to create traits for this?
<!---
Thank you for contributing to Boa! Please fill out the template below, and remove or add any
information as you feel necessary.
--->
Hi!
This isn't really related to a pull request that I know of. I was trying to better wrap my head around Boa's VM and thought I'd break it apart so that the file wasn't 2500+ lines. I figured I'd submit it as a draft and get feedback/see if anyone was interested in it. The way the modules were broken apart was primarily based off the opcode name (`GetFunction` & `GetFunctionAsync` -> `./get/function.rs`).
It changes the following:
- Adds an `Operation` trait to opcode/mod.rs
- Implements `Operation` for each Opcode variant, moving the executable instruction code from `vm/mod.rs` to the respective module
Co-authored-by: raskad <32105367+raskad@users.noreply.github.com>
This Pull Request changes the following:
- Fix error in `Proxy` set implementation
After this all other failing `Proxy` tests fail because of us missing the `with` implementation.
Co-authored-by: RageKnify <RageKnify@gmail.com>
This Pull Request changes the following:
- Implements the `LabelledStatement` Parse node.
- Removes `label` from all label-able items (switch, blocks and loop statements).
- Adjusts parsing to the new AST.
#2295 isn't fixed by this, but with this change it should be easier to fix.
This Pull Request fixes a small error in the documentation of `Context::register_global_function()` method, and a few clippy errors we were getting in the tests.
This is an experiment that tries to migrate the codebase from eager `Error` objects to lazy ones.
In short words, this redefines `JsResult = Result<JsValue, JsError>`, where `JsError` is a brand new type that stores only the essential part of an error type, and only transforms those errors to `JsObject`s on demand (when having to pass them as arguments to functions or store them inside async/generators).
This change is pretty big, because it unblocks a LOT of code from having to take a `&mut Context` on each call. It also paves the road for possibly making `JsError` a proper variant of `JsValue`, which can be a pretty big optimization for try/catch.
A downside of this is that it exposes some brand new error types to our public API. However, we can now implement `Error` on `JsError`, making our `JsResult` type a bit more inline with Rust's best practices.
~Will mark this as draft, since it's missing some documentation and a lot of examples, but~ it's pretty much feature complete. As always, any comments about the design are very much appreciated!
Note: Since there are a lot of changes which are essentially just rewriting `context.throw` to `JsNativeError::%type%`, I'll leave an "index" of the most important changes here:
- [boa_engine/src/error.rs](https://github.com/boa-dev/boa/pull/2283/files#diff-f15f2715655440626eefda5c46193d29856f4949ad37380c129a8debc6b82f26)
- [boa_engine/src/builtins/error/mod.rs](https://github.com/boa-dev/boa/pull/2283/files#diff-3eb1e4b4b5c7210eb98192a5277f5a239148423c6b970c4ae05d1b267f8f1084)
- [boa_tester/src/exec/mod.rs](https://github.com/boa-dev/boa/pull/2283/files#diff-fc3d7ad7b5e64574258c9febbe56171f3309b74e0c8da35238a76002f3ee34d9)
This Pull Request fixes#1371. And yeah, the number of file changes is real...
It changes the following:
- Split the ast `Node` into `Statement` and `Expression`.
- Rewrite the parser and bytecompiler to conform to this change.
- Refactor some ast nodes into reusable structures.
- Rewrite `contains_arguments` and `contains` to ease the transition into a future ast visitor.
List of things that were apparently fixed by this refactor?:
- Implement read-assign operation for private accessors (e.g. `this.#field ||= 5`).
- `var await` declaration now allowed outside `async` functions and inside functions nested in async functions.
- Reject redeclarations of variables declared in the init list of a for loop.
Still missing some documentation adjustments, will try to do it ASAP.
<!---
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 is related to #2098.
It changes the following:
- Implements `JsRegExp`
- Adds a brief `JsRegExp` example under `boa_examples`
e-codes-stuff
raskad
Kevin
Arjun Kavi
Halid Odat
José Julián Espina
Addison Crump
Anuvrat
Iban Eguia Moraza
Choongwoo Han
