The binding of 'this' in an arrow function should be 'lexical this'.

test code:

this.a = 50
let f = () => {
  console.log(this.a)
}
let g = function() {
  console.log(this.a)
}
f() // 50
let obj = { a: 70, f: f, g: g }
obj.f() // should be 50, 70 in rapidus
obj.g() // 70

In the example below, 'this' in the execution context of 'adder()' function should be set to global.
But in rapidus, it seems that 'this' takes over the lexical context when 'up' method was declared in 'c'.
This happens in only limited situations using function() syntax.
object.method() syntax work properly.

ex)

count = 100
var c = {
  count: 0,
  up: function() {
    console.log(++this.count)
  }
}
adder = c.up
c.up()  // node: 1, rapidus: 1
adder()  // node: 101, rapidus: 2

probably due to improperly set next_pos in the second iter.next() of Lexer.skip_char(), when the first iter.next() returned EOF.

ex)
$ cat examples/test.js
console.log(1); // 異常$ cargo run examples/test.js
Compiling rapidus v0.1.1 (~/Documents/GitHub/rapidus)
Finished dev [unoptimized + debuginfo] target(s) in 6.17s
Running target/debug/rapidus examples/test.js
thread 'main' panicked at 'byte index 23 is not a char boundary; it is inside '常' (bytes 22..25) of console.log(1); // 異常', libcore/str/mod.rs:2111:5
note: Run with RUST_BACKTRACE=1 for a backtrace.
thread 'main' panicked at 'exited. status: 101', src/main.rs:104:25
note: Run with RUST_BACKTRACE=1 for a backtrace.

found some bug in parsing Number literals.
1: can not parse floating point literals like "5e3" or "5e-3" correctly. (maybe parsed as integer literals -> 53)

may be some problem in Lexer.read_number().
checking floating point syntax in the statement
let is_f = "eEpP".contains(last) && "+-".contains(c);
but is_f seems not properly working.
and, maybe, "eEpP" and "+-" should be "eE" and "+-0123456789".

2: (tiny) problem in parsing integer literals like "0nnn".

0779 -> Decimal (in JS) vs Octal (parsed as octal number "77" in Rapidus)
0777 -> Octal (in JS or Rapidus)
this syntax is very confusing, and deprecated in strict mode.
I think using new Octal syntax in ECMAScript2015 ("0o777") only is better.

$ cat examples/test.js
console.log(0779)
console.log(0777)
console.log(5e3)
console.log(5e+3)
console.log(5e-3)

$ cargo run examples/test.js
Finished dev [unoptimized + debuginfo] target(s) in 0.15s
Running target/debug/rapidus examples/test.js
63
511
53
53
53
$ node examples/test.js
779
511
5000
5000
0.005

function f(...arg, b){
    console.log(arg, b)  //  [ 1, 3, 4, 5 ]   2
}
f(1,2,3,4,5)

Parser accept rest parameter (or even plural number of rest parameters) placed other than last in formal parameter.

Ref: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence#Table

Node.js:

console.log(1 + 2*3 ** 2 - 1);
// Output: 18

Rapidus (WASM):

print(1 + 2*3 ** 2 - 1);
// Output: 7

I recommend making some comment about this in the top page of this repo!
I feel it is very exciting.

https://maekawatoshiki.github.io/rapidus/

Hey there! Incredible work being done here, but I have a question, that can potentially become an important feature.

Is there a way to import functions written in rust (which are defined in the code embedding the rapidus) into the JavaScript context, for the to be used? If not, as for me, it is one of the most important features for an embeddable JavaScript engine. Also, easily operating on JavaScript values and passing callbacks, as well as calling JavaScript functions from Rust as callbacks.

I haven't read though too much code, so I might be wrong in my conclusions, but as for now it seems like the only way to "introduce" some rust to the engine is to declare it in the code with attributes.

Thanks for your amazing work,
Alex.

assignment expression should return value (ex. 5 for "a=5") according to ECMA-262 spec.
In rapidus, example codes (listed below) are correctly parsed, but go panic while bytecode execution.
no value seems to push to VM.state.stack in VM.set_name() function.

ex)
console.log(a=5)
a=b=5

The sequence of [LeftHandSideExpression][LineTerminator][++ or --] seems to be parsed wrong as [Expression][++ or --].

ex)
$ cat test.js
a = 1
b = a
++b // parsed as "b = a; ++b;" in node, "b = a++; b;" in rapidus
console.log( a, b )
$ node test.js
1 2
$ cargo run test.js
2 1
$ cargo run -- --debug test.js
Finished dev [unoptimized + debuginfo] target(s) in 0.21s
Running target/debug/rapidus --debug test.js
Lexer:
Token { kind: Identifier("a"), pos: 0 }
Token { kind: Symbol(Assign), pos: 2 }
Token { kind: Number(1.0), pos: 4 }
Token { kind: Identifier("b"), pos: 6 }
Token { kind: Symbol(Assign), pos: 8 }
Token { kind: Identifier("a"), pos: 10 }
Token { kind: Symbol(Inc), pos: 13 }
Token { kind: Identifier("b"), pos: 15 }
Token { kind: Identifier("console"), pos: 80 }
Token { kind: Symbol(Point), pos: 87 }
Token { kind: Identifier("log"), pos: 88 }
Token { kind: Symbol(OpeningParen), pos: 91 }
Token { kind: Identifier("a"), pos: 93 }
Token { kind: Symbol(Comma), pos: 94 }
Token { kind: Identifier("b"), pos: 96 }
Token { kind: Symbol(ClosingParen), pos: 98 }
Parser:
Node { base: StatementList([Node { base: Assign(Node { base: Identifier("a"), pos: 0 }, Node { base: Number(1.0), pos: 4 }), pos: 1 }, Node { base: Assign(Node { base: Identifier("b"), pos: 6 }, Node { base: UnaryOp(Node { base: Identifier("a"), pos: 10 }, PoInc), pos: 11 }), pos: 7 }, Node { base: Identifier("b"), pos: 15 }, Node { base: Call(Node { base: Member(Node { base: Identifier("console"), pos: 80 }, "log"), pos: 87 }, [Node { base: Identifier("a"), pos: 93 }, Node { base: Identifier("b"), pos: 96 }]), pos: 87 }]), pos: 0 }

...

I see that using ECMAScript's specification is exceedingly difficult. Would it sound more reasonable to use Rapidus for a strictly-typed version of TypeScript? Much like how strictly-typed TypeScript code can be compiled into a WASM module (except the WASM compilation part).

seems to be parser logic problem.

ConditionalExpression:
LogicalORExpression
LogicalORExpression ? AssignmentExpression : AssignmentExpression
http://www.ecma-international.org/ecma-262/9.0/index.html#sec-conditional-operator

ex)
$ cat test.js
console.log( false ? a = 1 : b = 2 )
$ node test.js
2
$ cargo run test.js
Finished dev [unoptimized + debuginfo] target(s) in 0.15s
Running target/debug/rapidus test.js
thread 'main' panicked at 'assertion failed: (left == right)
left: Symbol(Assign),
right: Symbol(Colon)', src/parser.rs:414:17
thread 'main' panicked at 'exited. status: 101', src/main.rs:104:25

test code

var a = 0
new f()
console.log(a)

function f() {
  var a = 10
}

$ node test.js
0
$ cargo run test.js
    Finished dev [unoptimized + debuginfo] target(s) in 0.25s
     Running `target/debug/rapidus examples/test.js`
10

It seems a bug in vm.set_member() function.

    ValueBase::Number(n) if n - n.floor() == 0.0 => {
        if n as usize >= map.length as usize {
            map.length = n as usize;
            map.elems.set_len(n as usize);
        }
        map.elems[n as usize] = val;    // <= index out of bounds
    }

ex)

var ary = []
console.log(ary[5] = 4)

$ node array.js
4
$ cargo run array.js
    Finished dev [unoptimized + debuginfo] target(s) in 0.15s
     Running `target/debug/rapidus array.js`
thread 'main' panicked at 'index out of bounds: the len is 5 but the index is 5', /rustc/96064eb61dc703c289fae61bdf90593d3e7b2449/src/libcore/slice/mod.rs:2454:14
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread 'main' panicked at 'exited. status: 101', src/main.rs:177:25
note: Run with `RUST_BACKTRACE=1` for a backtrace.

In ECMA spec, an ArrowFunction is a variant of an AssignmentExpression.
But in rapidus, an arrow function is parsed as a variant of a primary expression.
Thus, the parser can not detect a syntax error in such a code as follows.

let i = 1 + (x) => x   // no error
let j = (x) => { return x } + 1   // no error

Hi, this is a cool work.
It seems that identifiers starting with '$' can not be used.
Is it intentional?

maybe lexer.skip(Kind::Symbol(Symbol::Semicolon)) is needed after self.read_expression()? in "init" section of parser.read_for_statement().

ex)

for (i = 1; i <= 3; i++) {
    console.log(i);
}

$ cargo run examples/for.js
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
     Running `target/debug/rapidus examples/for.js`
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `Symbol(Semicolon)`,
 right: `Symbol(ClosingParen)`', src/parser.rs:304:13
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread 'main' panicked at 'exited. status: 101', src/main.rs:104:25
note: Run with `RUST_BACKTRACE=1` for a backtrace.
$ node examples/for.js
1
2
3

func call incorrectly initialize a variable in the parent scope which has the same name as the argument.
callobj.clear_args_vals() in vm.call_function() / vm.construct() seem to do this.

(test.js)
var i = 100
console.log("->", i)
f(5)
console.log("<-", i)
function f(i) { }

$ node test.js
-> 100
<- 100
$ cargo run test.js
    Finished dev [unoptimized + debuginfo] target(s) in 0.23s
     Running `target/debug/rapidus examples/for.js`
-> 100
<- undefined

CodeLine: https://github.com/maekawatoshiki/rapidus/blob/new-gen/src/parser.rs#L860

Ref: http://kangax.github.io/compat-table/es5/

Immutable globals:

• undefined
• NaN
• Infinity

So, the undefined/NaN/Infinity is just a global immutable property.

Update:
Spec: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-value-properties-of-the-global-object

Currently the spread operator (https://github.com/tc39/proposal-object-rest-spread) is unimplemented. Are there plans to implement this?

It seems parsing logic for ExponentiationExpression in rapidus is slightly different from that of ECMAScript syntax definition.

ex)
$ cat examples/test.js
console.log( 2 ** 2 ** 2 )
$ node examples/test.js
16
$ cargo run examples/test.js
Finished dev [unoptimized + debuginfo] target(s) in 0.15s
Running target/debug/rapidus examples/test.js
error(4): unexpected token
console.log( 2 ** 2 ** 2 )
^
thread 'main' panicked at 'explicit panic', src/parser.rs:48:9
note: Run with RUST_BACKTRACE=1 for a backtrace.
thread 'main' panicked at 'exited. status: 101', src/main.rs:104:25
note: Run with RUST_BACKTRACE=1 for a backtrace.

Hey, this is great project, thanks for your effort!

Maybe you could use https://github.com/nbp/holyjit to get JIT for free. Not sure in which state it is now but at least this was the idea I had when I was thinking about doing js engine in rust myself.

builtin_function_with_obj_and_prototype() do this the right way instead.

This is complexed (and really weird) issue which happens only in non-strict mode, and I may not have understood completely.
And I think this is a problem of implementation, rather than a bug.
First of all, see the test code and result below.

var a = 10
function func(){
    a = 3
    b = 5
    console.log(this.a, this.b) // in function object, this = global object
}
func()
console.log(this.a, this.b) // in module scope, this = {}

$ cargo run test.js
    Finished dev [unoptimized + debuginfo] target(s) in 0.21s
     Running `target/debug/rapidus test.js`
3 5
3 5
$ node test.js
undefined 5
undefined undefined

In the latest ECMA spec, the value of this keyword is resolved in the running execution context, whenever it is referred.
http://www.ecma-international.org/ecma-262/9.0/index.html#sec-this-keyword

And in node.js, every program file read is an independent module, and executed in the scope of each module (even if there is only one file), not the global scope. The global scope exists outer of the module scope. On the other hand, in web browsers, the top-level scope is the global scope.
https://nodejs.org/api/modules.html#modules_the_module_scope

When the func function is invoked in func() manner, this is bound to the Global object inside of the function. (when caller does not exist, this refer to the Global object in non-strict mode and undefined in strict mode)
http://www.ecma-international.org/ecma-262/9.0/index.html#sec-ecmascript-function-objects-call-thisargument-argumentslist

In executing func function, a is a variable declared in the main module scope (not global scope) and b refers to a property of the Global object. Thus, this.a is evaluated as undefined, whereas this.b is 5.
http://www.ecma-international.org/ecma-262/9.0/index.html#sec-global-environment-records

In node.js, this in module scope seems to be bound to an empty object ("{ }") which is not equal to the Global object.
Thus, in the global scope, "this.a" is resolved as "{}.a", which value is undefined as shown in second console.log() output.

To access the Global object directly, node.js provides "global" property of the Global object, which refers to the Global object itself. This means global.global === global.
Therefore, global.b in the module scope, is evaluated as 5.

I had following errors, but I'm a beginnger in llvm.
I search the LLVM_SYS_60_PREFIX in docs and set it as /usr/lib/llvm-6.0/lib. But it still reported the same error. How to solve it. And can you give me some advises to use llvm and llvm-rs?