- 24 May, 2017 1 commit
-
-
Caitlin Potter authored
A few tests that would be good to have to verify that the known manifestations of this bug are resolved. Previously, the async generator and async function tests would crash. The other ones never did, but still resulted in the register overwite bug. BUG=v8:6322 R=adamk@chromium.org Change-Id: Ic2238227629077de5671d67d18b3bfe018dd23f4 Reviewed-on: https://chromium-review.googlesource.com/514230Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#45524}
-
- 04 May, 2017 1 commit
-
-
Caitlin Potter authored
Removes the do-expression wrapping, modifies BytecodeGenerator change to enter a class literal's block scope if needed. This does not solve the actual bug in v8:6322, but helps mitigate it in simple cases. The bug is caused by BytecodeGenerator not allocating a large enough array of context registers to hold its entire stack, allowing non-context registers to be overwritten during PushContext and PopContext bytecodes. Nevertheless, I like the idea of not depending on do-expressions when possible, so I think it's worth doing anyways. BUG=v8:6322 R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a Reviewed-on: https://chromium-review.googlesource.com/491074 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45110}
-
- 24 Apr, 2017 1 commit
-
-
neis authored
R=adamk@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2833773002 Cr-Commit-Position: refs/heads/master@{#44811}
-
- 11 Apr, 2017 1 commit
-
-
Caitlin Potter authored
Fix error message printed by Runtime_ThrowCalledNonCallable. As noted on the bug, this has a slight problem in that it will always print that "asyncIterator" was not callable for GetIterator with an async IteratorType, though it may be referring to a different call. This issue is present regardless of the change I introduced to perform this desugaring in the BytecodeGenerator. BUG=v8:6187 R=adamk@chromium.org, verwaest@chromium.org Change-Id: I2077b7cd5976d9d9ba044f0dff44ee8c312d1263 Reviewed-on: https://chromium-review.googlesource.com/470806Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#44543}
-
- 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}
-