- 27 Jun, 2019 1 commit
-
-
Mathias Bynens authored
d8 treats files with the .mjs extension as modules instead of classic scripts. Thus, the `// MODULE` pragma and its corresponding logic in test runners can be removed in favor of explicitly adding the extension. Bug: v8:7950, v8:9395, v8:9406 Also-By: tmrts@chromium.org Change-Id: Ic74328dc5c5f176bb4bdf6d74bdd4d3966279ba5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1675958 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by: Tamer Tas <tmrts@chromium.org> Auto-Submit: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#62421}
-
- 12 Dec, 2017 1 commit
-
-
Georg Neis authored
This is a reland of c3bd741e Original change's description: > Fix "this" value in lazily-parsed module functions. > > When preparsing top-level functions in a module, we didn't track > unresolved variables. Consequently, "this" ended up referencing > the global "this", which has the wrong value (in a module "this" > is supposed to be the undefined value). > > This patch fixes that. This also lets us stop forcing context > allocation of all variables in module scopes, which the patch > takes care of as well. > > Bug: chromium:791334 > Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf > Reviewed-on: https://chromium-review.googlesource.com/808938 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#50025} TBR=adamk@chromium.org TBR=kozyatinskiy@chromium.org Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Bug: chromium:791334 Change-Id: I57acc7b84a345565b36cbb55924fa2ff9b449eec Reviewed-on: https://chromium-review.googlesource.com/822341 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#50045}
-
- 26 Oct, 2017 1 commit
-
-
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}
-
- 28 Feb, 2017 1 commit
-
-
Georg Neis authored
The order in which things were done wasn't quite correct and lead to wrong behaviour for certain circular module graphs. BUG=v8:1569,chromium:694566 Change-Id: I291186e261268c853a30ad891ff362904e0b28ef Reviewed-on: https://chromium-review.googlesource.com/447399Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#43497}
-
- 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}
-