dash
dash copied to clipboard
Experimental JavaScript implementation in Rust
To speed up startup times, it may be useful to make it possible to snapshot the JavaScript heap and compiled bytecode. - [x] Bytecode ([snapshot branch](https://github.com/y21/dash/tree/snapshot)) - [x] Serialize -...
```js let z = {}; let y = {__proto__:z}; z.__proto__ = y; y.a ``` running this crashes dash with a stack overflow because it gets stuck in a recursive "loop"...
```js console.log(/.+a/.test('bba')); ``` This should return true, but currently returns false, because `.+` eagerly consumes the whole string. Instead it should work its way backwards and realize that `.+` should...
```js let f; function F() { this.a = 1; f = () => console.log(this); } new F(); f(); ``` should print `F { a: 1 }` but prints undefined
Currently dash tries to apply some optimizations at compile time, e.g. given ```js for (let i = 0; i < 1000; i++); ``` The comparison and increment get special opcodes...
When the other end disconnects, `TcpStream` will continue yielding empty `ArrayBuffer`s. This is probably wrong.
... when it should be treated as setting its internal prototype slot. E.g. ```js let b = { __proto__: null }; console.log(b.__proto__); // not null!! ```
A major problem with the current GC is that the vm has no way of telling that a variable in a native function is holding a reference to a JavaScript...
It might be worth in a lot of cases, especially for function calls. I'm guessing that an overwhelming number of function calls in any JS program usually only has up...
`std::any::TypeId` will be (is, on nightly) 128 bits, to mitigate collisions (iiuc). I'm not sure if this will have a perf impact (I've seen u128 be significantly slower than u64...