- 26 Oct, 2017 2 commits
-
-
Daniel Clifford authored
Bug: chromium:778574 Change-Id: I014b16b9deabab07ca7dfb662ea8cb0dbf9c8987 Reviewed-on: https://chromium-review.googlesource.com/738148 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48975}
-
Clemens Hammacher authored
This way, we can also check the return code of d8. We currently have a bug (6981) which makes failing tests not being detected, even though the failure message is (sometimes) being printed. After this refactoring, we can write tests for our mjsunit test functions. R=machenbach@chromium.org Bug: v8:6981 Change-Id: I0aa0abcb0f9a4f622a1e1d1a4d826da1e6eb4f07 Reviewed-on: https://chromium-review.googlesource.com/737991Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48951}
-
- 25 Jul, 2017 1 commit
-
-
Sathya Gunasekaran authored
Before we try to do ASI and fail with a generic error, we special case for the await token in the failure case. Bug: v8:6572, v8:6513 Change-Id: Ia050c98b5a5b20bc326f429a367635b8553e4112 Reviewed-on: https://chromium-review.googlesource.com/582210Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#46885}
-
- 04 May, 2017 1 commit
-
-
Daniel Ehrenberg authored
New test262 tests bring up a couple cases with async arrow functions that V8 didn't seem to handle properly; this patch makes those cases errors: - async (...x,) => y -- Rest parameter must be last formal parameter - async (...x = z) => y -- No default value for rest parameter - async (...x, y) => z -- Rest parameter must be last formal parameter Bug: v8:4483, v8:5051 Change-Id: I024d9ba0c854e8e5e75283df2ee53127b1be090d Reviewed-on: https://chromium-review.googlesource.com/496057 Commit-Queue: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45116}
-
- 02 May, 2017 1 commit
-
-
Sathya Gunasekaran authored
Bug: v8:6337 Change-Id: I7de330c77e5f4cbb2cd4bf327c8b60783e78880c Reviewed-on: https://chromium-review.googlesource.com/493786 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#45043}
-
- 11 Apr, 2017 1 commit
-
-
gsathya authored
This patch implements the runtime semantics of dynamic import. We create a new ASTNode so that we can pass the JSFunction closure() to the runtime function from which we get the script_url. d8 implements the embedder logic required to load and evaluate the modules. The API is mostly implemented as specified. BUG=8:5785 Review-Url: https://codereview.chromium.org/2703563002 Cr-Commit-Position: refs/heads/master@{#44551}
-
- 17 Feb, 2017 1 commit
-
-
vabr authored
https://codereview.chromium.org/2694003002/ introduced "SyntaxError: Lexical declaration cannot appear in a single-statement context" for the case when let + desctructuring from a list happen. As was pointed out in https://codereview.chromium.org/2694003002/#msg18, the case without destructuring would also benefit from a better message: if a single statement is expected and "let identifier = ..." is seen, the error is indeed again that the lexical declaration is not a statement. However, the current error is "Unexpected identifier", because the parser tries to accept "let" as an identifier in an expression statement, and then gives up seeing the other identifier after "let". This CL ensures that the parser recognises the error properly and reports accordingly. It also renames the existing test, which contains destructuring, and adds the one with a non-destructuring lexical declaration. BUG=v8:5686 Review-Url: https://codereview.chromium.org/2697193007 Cr-Commit-Position: refs/heads/master@{#43275}
-
- 16 Feb, 2017 1 commit
-
-
vabr authored
ES2017 forbids the sequence of tokens "let [" in in expression statements [1]. This CL makes ParserBase report those instances as SyntaxError. It also adds a customised error message for that, because the standard "Unexpected token" is not applicable: "let" itself is not forbidden in those context, only the sequence of "let [". [1] https://tc39.github.io/ecma262/#sec-expression-statement BUG=v8:5686 Review-Url: https://codereview.chromium.org/2694003002 Cr-Commit-Position: refs/heads/master@{#43258}
-
- 16 Jan, 2017 1 commit
-
-
yangguo authored
TBR=tebbi@chromium.org BUG=chromium:679841 Review-Url: https://codereview.chromium.org/2631163002 Cr-Commit-Position: refs/heads/master@{#42375}
-
- 12 Jan, 2017 1 commit
-
-
marja authored
The bug was caused by AstTraversalVisitor refactoring: https://codereview.chromium.org/2169833002/ InitializerRewriter::VisitRewritableExpression in parser.cc didn't recurse; so it fails when a rewritable expression contains another rewritable expression. See the bug for more details. BUG=chromium:679727 Review-Url: https://codereview.chromium.org/2629623002 Cr-Commit-Position: refs/heads/master@{#42274}
-
- 04 Jan, 2017 1 commit
-
-
tebbi authored
R=bmeurer@chromium.org BUG=chromium:677757 Review-Url: https://codereview.chromium.org/2606383005 Cr-Commit-Position: refs/heads/master@{#42066}
-