Parser fixes #225 #240 #273 #281

jasonwilliams · 2020-03-23T09:59:29Z

No description provided.

Razican

This looks very nice! Do you want me to add the changes from #263?

boa/src/builtins/function/mod.rs

boa/src/syntax/ast/node.rs

boa/src/syntax/ast/op.rs

Razican · 2020-03-23T14:09:20Z

boa/src/syntax/ast/op.rs

                NumOp::Mod => "%",
            }
        )
    }
 }

 #[derive(Clone, Debug, Trace, Finalize, PartialEq)]
-/// A unary operation on a single value
+/// A unary operation on a single value   


Suggested change

/// A unary operation on a single value

/// A unary operation on a single value

Could this be due to a missing cargo fmt?

This is intentional.
Basically the way that Rust comments work is they utilise Markdown, and a newline in Markdown is 3 (or maybe 2) spaces after the string https://gist.github.com/shaunlebron/746476e6e7a4d698b373

This allows (in VSCode anyway) the next line to appear underneath the first

If there's a better way of doing this im open to it, ive just found adding spaces is the only way to get it to work for me

You can use \ (backslash) at the end with no trailing spaces, to do a newline. Even though it is not a part of the markdown specification. cargo doc markdown parser parses it as a newline, which is what we want.

For Example:

hello\ world

is:
hello
world

Here is the comment I got the idea from:
https://gist.github.com/shaunlebron/746476e6e7a4d698b373#gistcomment-2271765

Or alternatively you can just use <br>, since in markdown you can use HTML.

\ seems to work with rust-analyzer too, Thanks im happy to use this in future.
rust-analzyer prints <br> literally so that's no use

I added a suggestion to improve this. If we use the idiomatic way of Rust to display a summary in one line and the explanation in the second one, we can forget about this limitation :)

I added a suggestion to improve this

I might have missed this, but what was the suggestion?

I added a suggestion to improve this

I might have missed this, but what was the suggestion?

I think the diff is outdated here, feel free to resolve the conversation. I think the new pattern I used when documenting other functions of the parser was to add the small summary in the first line, then an empty line, and the rest in the next lines.

This is similar to how the Rust standard library does it: https://doc.rust-lang.org/stable/src/std/path.rs.html#2446-2470

boa/src/syntax/parser/mod.rs

boa/src/wasm.rs

boa/src/exec/mod.rs

boa/src/builtins/function/mod.rs

boa/src/syntax/ast/node.rs

boa/src/syntax/ast/op.rs

jasonwilliams · 2020-03-24T09:52:19Z

@Razican @HalidOdat thanks for the commit suggestions, ive also rebased against master.
I think all the methods are there now but its far from working.

For example, im trying (in my test.js file) console.log("test"); and i get ParsingError: Unexpected Token . unexpected token.

So i think now its the point of just making adjustments on whats there now.
Feel free to play with it, i think this will be some work 😂

boa/src/syntax/ast/node.rs

Razican

I found some interesting potential improvements. I will port the display hopefully today or tomorrow :)

boa/src/syntax/ast/op.rs

boa/src/syntax/lexer/mod.rs

boa/src/syntax/parser/mod.rs

HalidOdat · 2020-03-24T17:11:03Z

When running cargo build or cargo check:

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:1230:9
     |
1230 |         self.expect(TokenKind::Punctuator(Punctuator::OpenParen), "expected '('");
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: `#[warn(unused_must_use)]` on by default
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:1234:9
     |
1234 | /         self.expect(
1235 | |             TokenKind::Punctuator(Punctuator::OpenBracket),
1236 | |             "expected '{'",
1237 | |         );
     | |__________^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:1425:9
     |
1425 |         self.expect(TokenKind::Punctuator(Punctuator::OpenParen), "expected '('");
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:1429:9
     |
1429 | /         self.expect(
1430 | |             TokenKind::Punctuator(Punctuator::CloseParen),
1431 | |             "expected ')'",
1432 | |         );
     | |__________^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:1442:9
     |
1442 |         self.expect_punc(Punctuator::OpenBlock, "Expected open brace {");
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:1450:13
     |
1450 |             self.expect_punc(Punctuator::OpenParen, "Expected opening parenthesis (");
     |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:1459:13
     |
1459 |             self.expect_punc(Punctuator::CloseParen, "Expected )");
     |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:1460:13
     |
1460 |             self.expect_punc(Punctuator::OpenBlock, "Expected {");
     |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:1474:13
     |
1474 |             self.expect_punc(Punctuator::OpenBlock, "Expected {");
     |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:1522:13
     |
1522 | /             self.expect(
1523 | |                 TokenKind::Punctuator(Punctuator::CloseParen),
1524 | |                 "expected ')'",
1525 | |             );
     | |______________^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:1707:21
     |
1707 |                     self.expect_punc(Punctuator::Colon, "expect ':'");
     |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:1726:13
     |
1726 |             self.expect_punc(Punctuator::OpenParen, "exect '('");
     |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:1782:13
     |
1782 |             self.expect(TokenKind::Punctuator(Punctuator::Comma), "expect ','");
     |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:2045:13
     |
2045 |             self.expect_punc(Punctuator::OpenParen, "expect '('.");
     |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:2189:17
     |
2189 |                 self.expect_punc(Punctuator::CloseParen, "Expect punc");
     |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:2214:9
     |
2214 |         self.expect_punc(Punctuator::OpenParen, "expect '('");
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

warning: unused `std::result::Result` that must be used
    --> boa/src/syntax/parser/mod.rs:2218:9
     |
2218 |         self.expect_punc(Punctuator::OpenBlock, "expect '{'");
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: this `Result` may be an `Err` variant, which should be handled

why is there not a ? for error propagation?

jasonwilliams · 2020-03-24T17:19:32Z

why is there not a ? for error propagation?

I think there should be, a lot of it was written without running the code against it, so i probably missed loads of areas where i didn't add ?

HalidOdat

Added ? for error propagation.

boa/src/syntax/parser/mod.rs

boa/src/exec/mod.rs

jasonwilliams · 2020-03-24T23:06:02Z

its so great to see the new parser work.
ran some tests, so far it seems the array ones fail.

test builtins::array::tests::concat ... ok
test builtins::array::tests::find ... FAILED
test builtins::array::tests::filter ... FAILED
test builtins::array::tests::index_of ... FAILED
test builtins::array::tests::fill ... FAILED
test builtins::array::tests::last_index_of ... FAILED
test builtins::boolean::tests::check_boolean_constructor_is_function ... ok
test builtins::array::tests::find_index ... FAILED
test builtins::array::tests::every ... FAILED
test builtins::array::tests::pop ... FAILED
test builtins::array::tests::reverse ... FAILED
test builtins::array::tests::inclues_value ... FAILED

looks like a starting point if anyone wanted to look at that

HalidOdat · 2020-03-25T20:23:37Z

I will do some refactoring, documentation, bug fixing and in general some improvement in code quality.

Hopefully I will a create pull request today or tomorrow!

Razican · 2020-03-25T21:49:11Z

To add to this, in #283 I improved the parser error messages to see what error this was giving. I also made sure all errors in the tests display any potential result.

I think that the forward() function should return a Result to be able to better handle errors.

github-actions · 2020-03-31T11:06:39Z

Benchmark for `37a8242`

Click to view benchmark

Test	PR Benchmark	Master Benchmark	%
Create Realm	461.7±11.10µs	468.3±20.54µs	99%
Expression (Parser)	4.2±0.18µs	11.3±0.47µs	-66.00000000000001%
Hello World (Execution)	497.9±21.10µs	492.7±14.72µs	101%
Hello World (Lexer)	1174.0±74.75ns	1165.6±59.10ns	101%
Hello World (Parser)	1502.3±61.40ns	1356.8±58.26ns	111.00000000000001%
Symbol Creation	586.8±12.30µs	594.1±17.23µs	99%
fibonacci (Execution)	5.4±0.13ms	5.5±0.20ms	99%
	undefined	undefined	100%

HalidOdat · 2020-03-31T11:10:12Z

Yes! Performance has increased. 🎉

Razican · 2020-03-31T12:00:42Z

Something I would like to do with the new parser would be to avoid having more than 1,700 lines in one file, and divide it in small parsers.

So, we could have empty structures that could implement a Parse trait, that would only receive the cursor and have a parse() method. We could divide each section in the spec into its own module, with better documentation.

What do you think?

Razican · 2020-03-31T12:04:26Z

boa/src/syntax/parser/mod.rs

+        // TODO need to revisit this
+        // if let TokenKind::Identifier(name) = tok.kind {
+        //     if name == "get" || name == "set" {
+        //         let may_identifier = self.peek_skip_lineterminator();
+        //         if may_identifier.is_some()
+        //             && matches!(may_identifier.unwrap().kind, TokenKind::Identifier(_))
+        //         {
+        //             let f = self.read_function_expression()?;
+        //             let func_name = if let NodeBase::FunctionExpr(ref name, _, _) = f.base {
+        //                 name.clone().unwrap()
+        //             } else {
+        //                 panic!()
+        //             };
+        //             return Ok(PropertyDefinition::MethodDefinition(
+        //                 if name == "get" {
+        //                     MethodDefinitionKind::Get
+        //                 } else {
+        //                     MethodDefinitionKind::Set
+        //                 },
+        //                 func_name,
+        //                 f,
+        //             ));
+        //         }
+        //     }
+
+        //     return Ok(PropertyDefinition::IdentifierReference(name));
+        // }


What should we do with this? I'm guessing it's related to CoverInitializedName parsing, right?

Its not CoverInitializedName you're close, its MethodDefinition https://tc39.es/ecma262/#prod-MethodDefinition

We could park it (along with this code) an an issue for now?
Or we tackle it as part of this PR

We can park it, but I would remove the code, and add an explanation on what should be achieved here. Something like:

// TODO: `MethodDefinition` parsing // <https://tc39.es/ecma262/#prod-MethodDefinition>

jasonwilliams#292 there you go

Razican · 2020-03-31T12:09:00Z

boa/src/syntax/parser/mod.rs

+    /// Reads an initializer of variables.
+    ///
+    /// Note: it will expect the `=` token to have been already read.
+    ///
+    /// More information: <https://tc39.es/ecma262/#prod-Initializer>
+    fn read_initializer(&mut self) -> ParseResult {
+        self.read_assignment_expression()
+    }


I added some information in the docs here, but it feels a bit contra-intuitive. The Initializer is always a = character followed by an AssignmentExpression. So I think that if we want to divide the logic, we shouldn't ask for the calling code to already parse part of the initializer (the = token, in this case).

I think we should change it to expect reading the = token, and then the assignment expression.

More info: https://tc39.es/ecma262/#prod-Initializer

jasonwilliams · 2020-03-31T12:22:51Z

Something I would like to do with the new parser would be to avoid having more than 1,700 lines in one file, and divide it in small parsers.

So, we could have empty structures that could implement a Parse trait, that would only receive the cursor and have a parse() method. We could divide each section in the spec into its own module, with better documentation.

What do you think?

Sounds interesting, what do you mean by 'empty structures' though?
How do we know how best to break the parser up?
Should this be done now or as a follow up?

Razican · 2020-03-31T12:43:44Z

Sounds interesting, what do you mean by 'empty structures' though?

We can do something like this:

/// This trait contains the `parse()` method.
///
/// TODO: some extra docs here.
/// This enables using `ParserName::parse()` to parse parts of the spec.
trait Parse {
	fn parse(cursor: &Cursor<'_>) -> ParseResult;
}

/// Statement list item.
/// 
/// TODO: some extra docs here.
/// More information: <https://tc39.es/ecma262/#prod-StatementListItem>
#[derive(Debug, Clone, Copy)]
struct StatementListItem;

impl Parse for StatementListItem {
	fn parse(cursor: &Cursor<'_>) -> ParseResult {
		unimplemented!("State List Item parsing");
	}
}

And then call it like this:

let item = StatementListItem::parse(&self.cursor)?;

How do we know how best to break the parser up?

This is a tricky question. I think we should have a structure per each item in the spec, but many of them could share modules. Maybe it makes sense having a sub-module for expressions, another one for statements and declarations, another one for functions and classes and another one for scripts and modules. Maybe others for error handling and language extensions too, just keeping the sections in the spec.

Then, we could sub-divide these modules in the sub-sections in the specification itself. I think it would make it easier to navigate once you have the spec. This, along with some careful documentation would help also newcomers to the project.

Should this be done now or as a follow up?

Good question. I'm happy either way. This might not take so much time, though, since the parser is already written. On the other hand, we might need to do some extra work, though, to separate everything in smaller pieces.

There is also the fact of learning what to parse if an spec can be of multiple types. Should we just try parsing, check the error and try another parser? I'm talking about cases like this one. Should we try to parse an expression? or a binding identifier? should the parent parser peek next tokens to see what options we have?

jasonwilliams · 2020-03-31T12:54:51Z

I would open up an issue for discussion as i think we've already hit quite a big milestone here. Might be an idea to ship it in its current form and then start talking about how to break it up.

I also think @IovoslavIovchev may want to weigh in on this considering he talked about breaking up the parser too here: jasonwilliams#225

It would also be good to eventually close this PR and move conversation back into issues so its easier for others to contribute and PR of master again.

github-actions · 2020-03-31T13:00:34Z

Benchmark for `fa1ce00`

Click to view benchmark

Test	PR Benchmark	Master Benchmark	%
Create Realm	463.3±9.39µs	479.4±92.28µs	97%
Expression (Parser)	4.2±0.12µs	11.1±0.38µs	-68.00000000000001%
Hello World (Execution)	492.1±20.52µs	494.7±20.98µs	99%
Hello World (Lexer)	1136.9±36.62ns	1120.8±28.77ns	101%
Hello World (Parser)	1495.7±36.90ns	1340.1±44.96ns	112.00000000000001%
Symbol Creation	580.2±14.02µs	593.9±11.71µs	98%
fibonacci (Execution)	5.2±0.11ms	5.4±0.08ms	97%
	undefined	undefined	100%

github-actions · 2020-03-31T13:00:38Z

Benchmark for `fa1ce00`

Click to view benchmark

Test	PR Benchmark	Master Benchmark	%
Create Realm	458.2±14.26µs	469.5±16.20µs	98%
Expression (Parser)	4.1±0.15µs	10.9±0.31µs	-69%
Hello World (Execution)	486.1±19.65µs	489.4±14.96µs	99%
Hello World (Lexer)	1141.9±52.59ns	1161.4±64.46ns	98%
Hello World (Parser)	1514.9±75.61ns	1245.1±73.80ns	122%
Symbol Creation	578.2±22.98µs	584.6±28.98µs	99%
fibonacci (Execution)	5.4±0.14ms	5.5±0.13ms	98%
	undefined	undefined	100%

Razican · 2020-03-31T13:08:27Z

I would open up an issue for discussion as i think we've already hit quite a big milestone here. Might be an idea to ship it in its current form and then start talking about how to break it up.

Sure, let's do this. I would wait for #291 to land, though, since includes an extra improvement.

I also think @IovoslavIovchev may want to weigh in on this considering he talked about breaking up the parser too here: #225

I'm not sure if this is the same thing. The parser would still be recursive in this case. I actually wouldn't know how to make a parser iterative. In an easy way at least.

* Changed Cursor to take in a &[Token]. * Updated benchmark code.

github-actions · 2020-03-31T13:41:39Z

Benchmark for `9189706`

Click to view benchmark

Test	PR Benchmark	Master Benchmark	%
Create Realm	471.4±16.05µs	471.2±34.98µs	100%
Expression (Parser)	3.7±0.63µs	11.4±0.33µs	-106%
Hello World (Execution)	497.7±27.96µs	491.4±18.92µs	101%
Hello World (Lexer)	1120.2±74.19ns	1152.5±78.66ns	97%
Hello World (Parser)	1239.7±54.46ns	1324.6±41.41ns	93%
Symbol Creation	588.0±17.83µs	582.2±25.53µs	101%
fibonacci (Execution)	5.5±0.15ms	5.6±0.16ms	99%
	undefined	undefined	100%

HalidOdat · 2020-03-31T13:45:27Z

🎉 The performance improves yet again 🎉

Razican · 2020-03-31T16:02:49Z

This looks really impressive! Great work everyone, I think it's ready for merging. I'm a bit curious about the expression parsing benchmark that shows the new bench being -106% the previous one. The real number is 34%, which is very promising!

Even for the Hello World parsing,the reduction is significant, and the rest of the benchmarks don't change (except maybe for the lexer benchmark a bit in the Hello World).

And the internal code looks much cleaner. I will start working in the parser segmentation for Boa 0.8 :)

jasonwilliams · 2020-03-31T16:15:42Z

This looks really impressive! Great work everyone, I think it's ready for merging. I'm a bit curious about the expression parsing benchmark that shows the new bench being -106% the previous one. The real number is 34%, which is very promising!

Yeah im not sure why its doing that either, very odd!
The code is here:
https://github.com/jasonwilliams/criterion-compare-action/blob/master/main.js#L104-L115

the rest of the benchmarks don't change (except maybe for the lexer benchmark a bit in the Hello World).

The other benchmarks don't include lexing or parsing (they only start from execution) so i wouldn't expect them to change.

The real number is 34%,

How did you come to this number?

github-actions · 2020-03-31T16:21:47Z

Benchmark for `d11d0f5`

Click to view benchmark

Test	PR Benchmark	Master Benchmark	%
Create Realm	446.7±26.15µs	443.8±12.50µs	101%
Expression (Parser)	3.4±0.18µs	10.9±0.47µs	-120.00000000000001%
Hello World (Execution)	467.0±17.34µs	465.8±17.11µs	100%
Hello World (Lexer)	1069.2±57.16ns	1141.3±99.06ns	93%
Hello World (Parser)	1173.7±49.54ns	1287.4±68.53ns	89.99999999999999%
Symbol Creation	566.4±46.34µs	552.9±20.73µs	102%
fibonacci (Execution)	5.0±0.33ms	5.2±0.17ms	96%
	undefined	undefined	100%

HalidOdat · 2020-03-31T17:40:31Z

How did you come to this number?

You calculate the percentage manually by using the two completion times from benchmark for master and parser branches.

(100% * parser_time) / master_time - to calculate the percentage.

Hope that helps 👍

jasonwilliams · 2020-03-31T17:53:50Z

The reason i asked was because i thought that was more just getting the percentage of parser_time from master_time rather than getting the percentage decrease from master's time down to parser, which i think would be bigger than 32% right? (the difference between the two).

Would a starting point of 11.4μs (master) down to 3.7μs (parser) not be a 67% decrease?

HalidOdat · 2020-03-31T18:00:53Z

Would a starting point of 11.4us down to 3.7us be a 67% decrease?

Yes it is a 67% decrease (truncated from 67.54%).

Sorry for the misunderstanding.

jasonwilliams · 2020-03-31T18:23:06Z

Alright, lets do this

jasonwilliams added this to the v0.7.0 - New Parser milestone Mar 23, 2020

Razican reviewed Mar 23, 2020

View reviewed changes

HalidOdat reviewed Mar 23, 2020

View reviewed changes

boa/src/exec/mod.rs Outdated Show resolved Hide resolved

HalidOdat reviewed Mar 23, 2020

View reviewed changes

boa/src/builtins/function/mod.rs Outdated Show resolved Hide resolved

HalidOdat reviewed Mar 23, 2020

View reviewed changes

boa/src/syntax/ast/node.rs Show resolved Hide resolved

HalidOdat reviewed Mar 23, 2020

View reviewed changes

boa/src/syntax/ast/op.rs Outdated Show resolved Hide resolved

jasonwilliams force-pushed the parser branch from a92e81f to a93e004 Compare March 24, 2020 09:45

Razican reviewed Mar 24, 2020

View reviewed changes

boa/src/syntax/ast/node.rs Outdated Show resolved Hide resolved

Razican reviewed Mar 24, 2020

View reviewed changes

boa/src/syntax/ast/op.rs Outdated Show resolved Hide resolved

boa/src/syntax/lexer/mod.rs Outdated Show resolved Hide resolved

boa/src/syntax/lexer/mod.rs Outdated Show resolved Hide resolved

Razican reviewed Mar 24, 2020

View reviewed changes

boa/src/syntax/parser/mod.rs Outdated Show resolved Hide resolved

Razican reviewed Mar 24, 2020

View reviewed changes

boa/src/syntax/parser/mod.rs Outdated Show resolved Hide resolved

HalidOdat reviewed Mar 24, 2020

View reviewed changes

boa/src/syntax/parser/mod.rs Outdated Show resolved Hide resolved

HalidOdat requested changes Mar 24, 2020

View reviewed changes

HalidOdat reviewed Mar 24, 2020

View reviewed changes

boa/src/exec/mod.rs Show resolved Hide resolved

Razican mentioned this pull request Mar 24, 2020

Added indentation and better Display implementation for AST nodes #282

Merged

Razican mentioned this pull request Mar 25, 2020

New parser fixes tests failing against #281 #283

Merged

Jason Williams and others added 8 commits March 26, 2020 10:43

starting on parser

41b8d5b

Expr is now Node

e43b3b5

adding next_if

6ba5a60

updates

6e2d932

parser updates

affa783

updates

dbb156b

adding formal parameters

85ba6d0

enough for now

96ce050

HalidOdat mentioned this pull request Mar 31, 2020

Changed Cursor to take in a &[Token]. #291

Merged

Razican reviewed Mar 31, 2020

View reviewed changes

jasonwilliams mentioned this pull request Mar 31, 2020

MethodDefinition parsing #292

Closed

jasonwilliams mentioned this pull request Mar 31, 2020

Reimplement the parser #225

Closed

16 tasks

No need to cast 0 as f64

86df1fc

Changed Cursor to take in a &[Token]. (#291)

8390909

* Changed Cursor to take in a &[Token]. * Updated benchmark code.

consistent TC39 url

221babd

jasonwilliams merged commit 48c6e88 into master Mar 31, 2020

This was referenced Apr 1, 2020

feat: import parsing #259

Closed

Panic assigning named function to variable #266

Closed

Razican deleted the parser branch April 17, 2020 12:33

	/// A unary operation on a single value
	/// A unary operation on a single value

Parser fixes #225 #240 #273 #281

Parser fixes #225 #240 #273 #281

Conversation

jasonwilliams commented Mar 23, 2020

Razican left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jasonwilliams Mar 23, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jasonwilliams Mar 23, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jasonwilliams commented Mar 24, 2020

Razican left a comment

Choose a reason for hiding this comment

HalidOdat commented Mar 24, 2020

jasonwilliams commented Mar 24, 2020

HalidOdat left a comment

Choose a reason for hiding this comment

jasonwilliams commented Mar 24, 2020

HalidOdat commented Mar 25, 2020

Razican commented Mar 25, 2020

github-actions bot commented Mar 31, 2020

Benchmark for 37a8242

HalidOdat commented Mar 31, 2020

Razican commented Mar 31, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jasonwilliams commented Mar 31, 2020

Razican commented Mar 31, 2020 • edited Loading

jasonwilliams commented Mar 31, 2020 • edited Loading

github-actions bot commented Mar 31, 2020

Benchmark for fa1ce00

github-actions bot commented Mar 31, 2020

Benchmark for fa1ce00

Razican commented Mar 31, 2020

github-actions bot commented Mar 31, 2020

Benchmark for 9189706

HalidOdat commented Mar 31, 2020

Razican commented Mar 31, 2020

jasonwilliams commented Mar 31, 2020 • edited Loading

github-actions bot commented Mar 31, 2020

Benchmark for d11d0f5

HalidOdat commented Mar 31, 2020

jasonwilliams commented Mar 31, 2020 • edited Loading

HalidOdat commented Mar 31, 2020 • edited Loading

jasonwilliams commented Mar 31, 2020

jasonwilliams Mar 23, 2020 •

edited

Loading

jasonwilliams Mar 23, 2020 •

edited

Loading

Benchmark for `37a8242`

Razican commented Mar 31, 2020 •

edited

Loading

jasonwilliams commented Mar 31, 2020 •

edited

Loading

Benchmark for `fa1ce00`

Benchmark for `fa1ce00`

Benchmark for `9189706`

jasonwilliams commented Mar 31, 2020 •

edited

Loading

Benchmark for `d11d0f5`

jasonwilliams commented Mar 31, 2020 •

edited

Loading

HalidOdat commented Mar 31, 2020 •

edited

Loading