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 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>
Boa's `Context::eval()` and `Context::parse()` functions allow reading a byte slice directly, apart from a string. We were not showing this properly in our examples, so this modifies the `loadfile.rs` example to use a byte vector instead of a string, which allows us to use UTF-16 files, if I'm not mistaken.
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)
<!---
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`
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 closes#2080.
It moves all implementors of the `JsObjectType` trait into their own `js_object` module.
This should simplify documentation and by doing a `pub(crate)` export in `object` little to no imports within the crate need to be changed, simplifying the usage of this module within the boa_engine crate.
Documentation within the `object` module has been updated to reflect this change and in a way that it is shown on the home page of the documentation.
<!---
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 `DataView`
- Adds an example of `JsDataView` to the `JsArrayBuffer` example file under boa_examples
Co-authored-by: jedel1043 <jedel0124@gmail.com>
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 PR adds the `ArrayBuffer` rust wrapper. It also provides a capability to construct a `JsArrayBuffer` from a user defined blob of data ( `Vec<u8>` ) and it is not cloned, it is directly used as the internal buffer.
This allows us to replace the inifficent `Vec<u8>` to `JsArray` then to `TypedArray` (in typed arrays `from_iter`), with a `JsArrayBuffer` created from user data to `TypedArray`. With this `Vec<u8>` to `JsTypedArray` should be fully fixed as discussed in #2058.
This PR adds a safe wrapper around JavaScript `JsSet` from `builtins::set`, and is being tracked at #2098.
Implements following methods
- [x] `Set.prototype.size`
- [x] `Set.prototype.add(value)`
- [x] `Set.prototype.clear()`
- [x] `Set.prototype.delete(value)`
- [x] `Set.prototype.has(value)`
- [x] `Set.prototype.forEach(callbackFn[, thisArg])`
Implement wrapper for `builtins::set_iterator`, to be used by following.
- [x] `Set.prototype.values()`
- [x] `Set.prototype.keys()`
- [x] `Set.prototype.entries()`
*Note: Are there any other functions that should be added?
Also adds `set_create()` and made `get_size()` public in `builtins::set`.
<!---
Thank you for contributing to Boa! Please fill out the template below, and remove or add any
information as you feel neccessary.
--->
This Pull Request related to JsMap for #2098.
Any feedback on implementing JsMapIterator would be welcome. I wasn't entirely sure if it was the right approach, but as I worked on the example file, it felt like something at least similar would be needed to use Map's .entries(), .keys(), and .values() methods.
It changes the following:
- Implements JsMap Wrapper
- Implements JsMapIterator Wrapper
- Creates JsMap example in boa_examples
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
This Pull Request supersedes #2018 and #2017.
It changes the following:
- Updates the wasm-bindgen dependency now that a new version without the clippy bug has been released
- Updates all dependencies to their latest versions
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>
Anuvrat
José Julián Espina
Addison Crump
Iban Eguia Moraza
Kevin
Calli
Halid Odat
Jason Williams
Jason Williams