<!---
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 meant to address #1900. While working on it, there was a decent amount of refactoring/restructuring. Initially, I had kept with the current approach of just keeping track of a kind and counter on the environment stack, especially because that kept the size of each stack entry to a minimum.
I did, however, make a switch to having the opcode create the `EnvStackEntry` with a start address and exit address for a bit more precision.
It changes the following:
- Consolidates `loop_env_stack` and `try_env_stack` into one `EnvStackEntry` struct.
- Changes `Continue`, `Break`, `LoopStart`, `LoopContinue`, `FinallyStart`, `FinallyEnd` and various others. Most of this primarily revolves around the creating of `EnvStackEntry` and interacting with the `env_stack`.
- Changes/updates the try-catch-finally, break and continue statement compilations as necessary
- Adds an `AbruptCompletionRecord` in place of the `finally_jump` vector.
- Adds some tests for try-catch-finally blocks with breaks.
I'm creating this draft PR, since I wanted to have some early feedback, and because I though I would have time to finish it last week, but I got caught up with other stuff. Feel free to contribute :)
The main thing here is that I have divided `eval()`, `parse()` and similar functions so that they can decide if they are parsing scripts or modules. Let me know your thoughts.
Then, I was checking the import & export parsing, and I noticed we are using `TokenKind::Identifier` for `IdentifierName`, so I changed that name. An `Identifier` is an `IdentifierName` that isn't a `ReservedWord`. This means we should probably also adapt all `IdentifierReference`, `BindingIdentifier` and so on parsing. I already created an `Identifier` parser.
Something interesting there is that `await` is not a valid `Identifier` if the goal symbol is `Module`, as you can see in the [spec](https://tc39.es/ecma262/#prod-LabelIdentifier), but currently we don't have that information in the `InputElement` enumeration, we only have `Div`, `RegExp` and `TemplateTail`. How could we approach this?
Co-authored-by: jedel1043 <jedel0124@gmail.com>
Hi,
the `vm-implied` fuzzer panics when executing this testcase:
```javascript
try {
new function() {
while (this) {}
}();
} catch {
}
```
`internal error: entered unreachable code: The NoInstructionsRemain native error cannot be converted to an opaque type`
Handling the `NoInstructionsRemain` error upfront instead of going through the VM exception handling logic seems to work.
<!---
Thank you for contributing to Boa! Please fill out the template below, and remove or add any
information as you feel necessary.
--->
Adding a feature flag to the console import in `builtins`. I think this should fix the failing action on the `Upload docs and run benchmarks` step
This Pull Request changes the following:
- Implement binary `in` operation with private names.
- Adding a separate `BinaryInPrivate` expression in addition to the existing `Binary` expression seems like the best way to implement this in a typesafe manner. Other methods like adding an enum for the `Binary` lhs result in having to make assertions.
Small (ish?) step towards having proper realm records
This PR changes the following:
- Moves `Intrinsics` to `Realm`.
- Cleans up the initialization logic of our intrinsics to not depend on `Context`, unblocking things like #2314.
- Adds hooks to initialize the global object and the global this per the corresponding [`InitializeHostDefinedRealm ( )`](https://tc39.es/ecma262/#sec-initializehostdefinedrealm) hook. Though, this is currently broken because the vm uses `GlobalPropertyMap` instead of the `JsObject` API to initialize global properties.
This Pull Request changes the following:
- Move postfix/prefix increment and decrement operations from the `Unary` expression to a new `Update` expression.
- Add a special type for the `Update` expression target as it is very limited in comparision to an `Unary` target.
- This makes bytecode compilation more typesafe for these operations and removes syntax errors from the bytecompiler without introducing panics (see #1907).
Another change extracted from #2411.
This PR changes the following:
- Improves our identifier parsing with a new `Identifier` parser that unifies parsing for `IdentifierReference`, `BindingIdentifier` and `LabelIdentifier`.
- Slightly improves some error messages.
- Extracts our manual initialization of static `Sym`s with a new `static_syms` proc macro.
- Adds `set_module_mode` and `module_mode` to the cursor to prepare for modules.
Slightly related to #2411 since we need an API to pass module files, but more useful for #1760, #1313 and other error reporting issues.
It changes the following:
- Introduces a new `Source` API to store the path of a provided file or `None` if the source is a plain string.
- Improves the display of `boa_tester` to show the path of the tests being run. This also enables hyperlinks to directly jump to the tested file from the VS terminal.
- Adjusts the repo to this change.
Hopefully, this will improve our error display in the future.
Currently the compilation of assignment operators leads to a double object property access, both on the get and set access.
While this refactor adds special access handling instead of using the existing `access_set` and `access_get` functions, it fixes the double access and should also make the resulting code more efficient.
This Pull Request changes the following:
- Remove wrong early errors for static class methods with the computed property name `prototype`.
- Switch static class method definition opcodes from `__define_own_property__` to `define_property_or_throw` to correctly throw runtime errors on property redefinitions.
When compiling a statement list we need to make sure that the last expression that returns a value is compiled with the `use_expr` flag. Currently we set `use_expr` on the last statement of the statement list. This leads to incorrect returns when the last statement does not return a value. This PR fixes this by looking up the last value returning expression in a statement list and setting the `use_expr` appropriately.
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.
<!---
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 addresses #2295, and another case that I came across when I was adding `Break` to the `ByteCompiler`
I did have a question that came up during this regarding the spec. We currently don't implement the [BreakableStatement](https://tc39.es/ecma262/#prod-BreakableStatement). Any thoughts on whether we should be? Especially since `BreakableStatement` seems to be a bit of a inaccurate since `LabelledStatement` is breakable too.
It changes the following:
- Moves handling of label jump out of `compile_block` and into `compile_labelled`.
- Adds a couple more tests to keep track of `LabelledStatement` breaks.
Co-authored-by: Ness <Kevin.Ness@Staples.com>
Follows from #2528, and should complement #2411 to implement the module import hooks.
~~Similarly to the Intl/ICU4X PR (#2478), this has a lot of trivial changes caused by the new lifetimes. I thought about passing the queue and the hooks by value, but it was very painful having to wrap everything with `Rc` in order to be accessible by the host.
In contrast, `&dyn` can be easily provided by the host and has the advantage of not requiring additional allocations, with the downside of adding two more lifetimes to our `Context`, but I think it's worth.~~ I was able to unify all lifetimes into the shortest one of the three, making our API just like before!
Changes:
- Added a new `HostHooks` trait and a `&dyn HostHooks` field to `Context`. This allows hosts to implement the trait for their custom type, then pass it to the context.
- Added a new `JobQueue` trait and a `&dyn JobQueue` field to our `Context`, allowing custom event loops and other fun things.
- Added two simple implementations of `JobQueue`: `IdleJobQueue` which does nothing and `SimpleJobQueue` which runs all jobs until all successfully complete or until any of them throws an error.
- Modified `boa_cli` to run all jobs until the queue is empty, even if a job returns `Err`. This also prints all errors to the user.
The section about `Symbol` on the [specification](https://tc39.es/ecma262/#sec-ecmascript-language-types-symbol-type) says:
> The Symbol type is the set of all non-String values that may be used as the key of an Object property ([6.1.7](https://tc39.es/ecma262/#sec-object-type)).
Each possible Symbol value is unique and immutable.
Our previous implementation of `JsSymbol` used `Rc` and a thread local `Cell<usize>`. However, this meant that two different symbols in two different threads could share the same hash, making symbols not unique.
Also, the [GlobalSymbolRegistry](https://tc39.es/ecma262/#table-globalsymbolregistry-record-fields) is meant to be shared by all realms, including realms that are not in the same thread as the main one; this forces us to replace our current thread local global symbol registry with a thread-safe one that uses `DashMap` for concurrent access. However, the global symbol registry uses `JsString`s as keys and values, which forces us to either use `Vec<u16>` instead (wasteful and needs to allocate to convert to `JsString` on each access) or make `JsString` thread-safe with an atomic counter. For this reason, I implemented the second option.
This PR changes the following:
- Makes `JsSymbol` thread-safe by using Arc instead of Rc, and making `SYMBOL_HASH_COUNT` an `AtomicU64`.
- ~~Makes `JsString` thread-safe by using `AtomicUsize` instead of `Cell<usize>` for its ref count.~~ EDIT: Talked with @jasonwilliams and we decided to use `Box<[u16]>` for the global registry instead, because this won't penalize common usage of `JsString`, which is used a LOT more than `JsSymbol`.
- Makes the `GLOBAL_SYMBOL_REGISTRY` truly global, using `DashMap` as our global map that is shared by all threads.
- Replaces some thread locals with thread-safe alternatives, such as static arrays and static indices.
- Various improvements to all related code for this.
This Pull Request changes the following:
- Do not skip consecutive semicolons while parsing a `StatementList`.
- Expect semicolon in `LexicalDeclaration` and add an special case for `for` loop parsing.
- Adjust `StatementList` compilation to skip empty statements.
- Adjust/add tests to make sure consecutive semicolons are correctly parsed.
<!---
Thank you for contributing to Boa! Please fill out the template below, and remove or add any
information as you feel necessary.
--->
Some small changes to the VM with the hopes of making it a bit more clear and concise.
It changes the following:
- Changes `code` to `code_block` and `code` to `bytecode` in `CallFrame` and `CodeBlock`, respectively.
- Adds some creation methods to `CallFrame`.
- Implements `Default` for `Vm`.
This Pull Request fixes various bugs related to classes.
The biggest changes are:
- Changed private names to be unique across multiple classes.
- Changed private name resolution to work via a visitor after a class is parsed. The way class early errors are defined makes it impossible to perform private name resolution while parsing.
- Added function names to class methods.
- Added class name binding to method function environments.
- Separated opcodes for `static` and non-`static` class method definitions to make the above operations possible.
There are still some bugs and further issues with classes but this is already a lot.
As part of the new modules PR, I was working on implementing the [host hooks](https://tc39.es/ecma262/#sec-host-hooks-summary) for the module import hooks and custom job queues. However, the promises module needed a bit of a refactor in order to couple with the new API. So, I thought it was a good idea to separate the promises refactor into its own PR, since the other PR is already big as it is.
- Replaced some usages of `JobCallback` with a new `NativeJob` that isn't traced by the GC, since those closures are always rooted and executed by the `Context` globally. This will also allow hosts to pass their custom jobs to the job queue, and maybe could also accept futures in the Future (pun intended 😆).
- Refactored several functions to account for the `HostPromiseRejectionTracker` hook which needs the promise `JsObject`.
- Rewrote some patterns with newer Rust idioms.
<!---
Thank you for contributing to Boa! Please fill out the template below, and remove or add any
information as you feel necessary.
--->
Hi all! 😄
This Pull Request addresses #2424. There are also a few changes made to the `ByteCompiler`, the majority of which are involving `JumpControlInfo`.
It changes the following:
- Adds `Break` Opcode
- Shifts `compile_stmt` into the `statement` module.
- Moves `JumpControlInfo` to it's own module.
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 changes the following:
- Pass a receiver value to the object `get` function in the `GetPropertyBy*` opcodes. The receiver value may be different from the object, because `ToObject` is not called on it.
<!---
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/closes #2512 .
Removes `Literal::Undefined` so that `undefined` is treated as an identifier name. Ran the parser's idempotency fuzzer and ensured the bug doesn't reproduce.
<!---
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/closes #2416.
Previously, prefix increment and decrement operations on `this` caused a panic. This PR makes the parser issue a syntax error when the operand UnaryExpression is not simple (as mentioned in https://tc39.es/ecma262/#sec-update-expressions-static-semantics-early-errors).
Just a general cleanup of the APIs of our `Context`.
- Reordered the `pub` and `pub(crate)/fn` methods to have a clear separation between our public and private APIs.
- Removed the call method and added it to `JsValue` instead, which semantically makes a bit more sense.
- Removed the `construct_object` method, and added an utility method `new` to `JsObject` instead.
- Rewrote some patterns I found while rewriting the calls of the removed function.
`execute_instruction` is heavily used. After decoding an opcode, `match` is used to find a proper `execute` function for the opcode. But, the `match` may not be able to be optimized into a table jump by rust compiler, so it may use multiple branches to find the function. When I tested with a toy program, only `enum -> &'static str` case was optimized to use a table while `enum -> function call` uses multiple branches. ([gotbolt](https://rust.godbolt.org/z/1rzK5vj6f))
This change makes the opcode to use a table explicitly. It improves the benchmark score of Richards by 1-2% (22.8 -> 23.2).
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.
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?
raskad
Kevin
Iban Eguia Moraza
Mrmaxmeier
raskad
José Julián Espina
Veera
Choongwoo Han
e-codes-stuff
Arjun Kavi
Halid Odat
Addison Crump
Anuvrat
