- 31 Jul, 2017 1 commit
-
-
Adam Klein authored
Change-Id: Idb6dfed1d0314c38c25b230faa7e28728cff2637 Reviewed-on: https://chromium-review.googlesource.com/587250 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#47019}
-
- 25 Jul, 2017 1 commit
-
-
Adam Klein authored
Bug: chromium:740591 Change-Id: I869be41d8630b23704b9470c4d3db8a21bbde873 Reviewed-on: https://chromium-review.googlesource.com/583531Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46881}
-
- 14 Jul, 2017 2 commits
-
-
Caitlin Potter authored
SuspendFlags was originally used by the suspend operation to determine which field to record the bytecode offset of a suspended generator, and the value the generator was resumed with. For async generators, await operations would use a separate field, in order to preserve the previous yield input value. This was important to ensure `function.sent` continued to function correctly. As function.sent is being retired, this allows the removal of support for that. Given that this was the only real need for SuspendFlags in the first place (with other uses tacked on as a hack), this involves several other changes as well: - Modification of MacroAssembler AssertGeneratorObject. No longer accepts a SuspendFlags parameter to determine which type of check to perform. - Removal of `flags` operand from SuspendGenerator bytecode, and the GeneratorStore js-operator. - Removal of `flags` parameter from ResumeGeneratorTrampoline builtins. - Removal of Runtime functions, interpreter intrinsics and AccessBuilders associated with the [[await_input_or_debug_pos]] field in JSAsyncGeneratorObject, as this field no longer exists. - Addition of a new `Yield` AST node (subclass of Suspend) in order to prevent the need for the other SuspendFlag values. BUG=v8:5855 TBR=bmeurer@chromium.org Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487 Reviewed-on: https://chromium-review.googlesource.com/570485 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46683}
-
Caitlin Potter authored
This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
-
- 06 Jul, 2017 1 commit
-
-
Sathya Gunasekaran authored
Print the object that is being destructured and update the error message. Previously, d8> var [a] = {} (d8):1: TypeError: [Symbol.iterator] is not a function Now, d8> var [a] = {} (d8):1: TypeError: {} is not iterable Bug: v8:6513, v8:5532 Change-Id: I5cbfe7c7e20632bce1a48bd38a1b0c98d0ff0660 Reviewed-on: https://chromium-review.googlesource.com/557370 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46457}
-
- 30 Jun, 2017 1 commit
-
-
Leszek Swirski authored
Change-Id: I2ee0ff9db1bbc8c17a1ad3dea1de1ad996895852 Reviewed-on: https://chromium-review.googlesource.com/474807Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46338}
-
- 23 Jun, 2017 1 commit
-
-
Tobias Tebbi authored
Async generator yield* is still desugared in the parser, to be moved to the BytecodeGenerator in a future CL. Bug: v8:6472 Change-Id: I8b33e2f9e931949f7375540099cd8ec3a6b27cf1 Reviewed-on: https://chromium-review.googlesource.com/539335 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46165}
-
- 19 Jun, 2017 1 commit
-
-
Sathya Gunasekaran authored
This patch updates the error positition and the error msg. Previously, → ./out.gn/x64.release/d8 test.js test.js:1: TypeError: undefined is not a function var [a] = {}; ^ TypeError: undefined is not a function at test.js:1:1 With this patch, → ./out.gn/x64.release/d8 test.js test.js:1: TypeError: [Symbol.iterator] is not a function var [a] = {}; ^ TypeError: [Symbol.iterator] is not a function at test.js:1:11 Bug: v8:5532 Change-Id: Ib066e8ec8a53fdf06cce491bde4b1d0c6d564cbc Reviewed-on: https://chromium-review.googlesource.com/539024Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#46015}
-
- 15 Jun, 2017 1 commit
-
-
Sathya Gunasekaran authored
Previously, when destructuring against null or undefined we would print: d8> var { x } = null (d8):1: TypeError: Cannot match against 'undefined' or 'null'. var { x } = null ^ TypeError: Cannot match against 'undefined' or 'null'. at (d8):1:1 The above message uses the term "match" which isn't a common term in JavaScript to describe destructuring. This message also doesn't provide the name of the property that fails destructuring. This patch changes the error message to be: d8> var { x } = null; (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'. var { x } = null; ^ TypeError: Cannot destructure property `x` of 'undefined' or 'null'. at (d8):1:1 This patch changes the message to say "destructure" instead of "match". This patch adds support for printing property names that are string literals. We iterate through every property and pick the first string literal property name if it exists. This provides at least some feedback to the developer. This patch also makes the pointer point to the position of the property name that fails destructuring. For computed and numeric property names, we print a generic error: d8> var { 1: x } = null (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'. var { 1: x } = null ^ TypeError: Cannot destructure against 'undefined' or 'null'. at (d8):1:1 Bug: v8:6499 Change-Id: I35b1ac749489828686f042975294b9926e2dfc53 Reviewed-on: https://chromium-review.googlesource.com/537341Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#45965}
-
- 30 May, 2017 1 commit
-
-
Aleksey Kozyatinskiy authored
This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position. Benefits (see test for details): - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2), - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}. TBR=dgozman@chromium.org,rmcilroy@chromium.org,machenbach@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org,devtools-reviews@chromium.org,v8-reviews@googlegroups.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:5909 Change-Id: Ie84fa79afeed09e28cf8478ba610a0cfbfdfc294 Reviewed-on: https://chromium-review.googlesource.com/518116 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45598}
-
- 29 May, 2017 1 commit
-
-
Michael Achenbach authored
This reverts commit 7a9cc704. Reason for revert: Changes layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/15882 This is about: inspector/sources/debugger/source-frame-inline-breakpoint-decorations.html Original change's description: > [inspector] moved var initialization break location before init expression > > This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position. > Benefits (see test for details): > - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2), > - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}. > > Bug: v8:5909 > Change-Id: I039d911903a2826c9859710a63ab0462c992e11b > Reviewed-on: https://chromium-review.googlesource.com/513926 > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Dmitry Gozman <dgozman@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45530} TBR=dgozman@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:5909 Change-Id: Ibf84401e8050d3c84db219d983de2c6bba0f697f Reviewed-on: https://chromium-review.googlesource.com/518102Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#45547}
-
- 25 May, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position. Benefits (see test for details): - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2), - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}. Bug: v8:5909 Change-Id: I039d911903a2826c9859710a63ab0462c992e11b Reviewed-on: https://chromium-review.googlesource.com/513926 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#45530}
-
- 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}
-
- 22 Mar, 2017 1 commit
-
-
Caitlin Potter authored
While the primary use-case for Suspend nodes is the Yield expression, there are other uses as well: Await expressions, and the initial suspend of Generators, which returns an object matching the Iterator protocol. "Suspend" is a better representation of the spec text (closer to the spec text for the values of [[GeneratorState]] and [[AsyncGeneratorState]]), and can make it easier to understand the meaning of what I had previously called Yield::is_normal() (now Suspend::is_yield()). Changes requested as part of https://chromium-review.googlesource.com/c/447117/ BUG= R=neis@chromium.org, adamk@chromium.org TBR=bmeurer@chromium.org, paul.lind@imgtec.com, joransiu@ca.ibm.com, weiliang.lin@intel.com Change-Id: Ic6f15b04fff091c20f26526391b967287c06f6bf Reviewed-on: https://chromium-review.googlesource.com/455583Reviewed-by:
Caitlin Potter <caitp@igalia.com> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#44038}
-
- 15 Feb, 2017 1 commit
-
-
caitp authored
When --harmony-async-iteration is enabled, it is now possible to use the for-await-of loop, which uses the Async Iteration protocol rather than the ordinary ES6 Iteration protocol. the Async-from-Sync Iterator object is not implemented in this CL, and so for-await-of loops will abort execution if the iterated object does not have a Symbol.asyncIterator() method. Async-from-Sync Iterators are implemented seperately in https://codereview.chromium.org/2645313003/ BUG=v8:5855, v8:4483 R=neis@chromium.org, littledan@chromium.org, adamk@chromium.org Review-Url: https://codereview.chromium.org/2637403008 Cr-Commit-Position: refs/heads/master@{#43224}
-
- 10 Feb, 2017 1 commit
-
-
neis authored
Move the logic into Scope::DeclareVariable to be more robust. BUG=v8:5636 Review-Url: https://codereview.chromium.org/2685293003 Cr-Commit-Position: refs/heads/master@{#43098}
-
- 07 Feb, 2017 3 commits
-
-
hablich authored
Reland of [parsing] Fix maybe-assigned for loop variables. (patchset #1 id:1 of https://codereview.chromium.org/2679263002/ ) Reason for revert: False alarm, bot hiccup Original issue's description: > Revert of [parsing] Fix maybe-assigned for loop variables. (patchset #3 id:40001 of https://codereview.chromium.org/2673403003/ ) > > Reason for revert: > Speculative revert because of https://codereview.chromium.org/2679163002/. > > Original issue's description: > > [parsing] Fix maybe-assigned for loop variables. > > > > Due to hoisting, the value of a 'var'-declared variable may actually change even > > if the code contains only the "initial" assignment, namely when that assignment > > occurs inside a loop. For example: > > > > let i = 10; > > do { var x = i } while (i--): > > > > As a simple and very conservative approximation of this, we explicitly mark > > as maybe-assigned any non-lexical variable whose "declaration" does not > > syntactically occur in the function scope. (In the example above, it > > occurs in a block scope.) > > > > BUG=v8:5636 > > > > Review-Url: https://codereview.chromium.org/2673403003 > > Cr-Commit-Position: refs/heads/master@{#42989} > > Committed: https://chromium.googlesource.com/v8/v8/+/a33fcd663b28b8846e12b97c30d6e7d837767f86 > > TBR=marja@chromium.org,adamk@chromium.org,neis@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5636 > > Review-Url: https://codereview.chromium.org/2679263002 > Cr-Commit-Position: refs/heads/master@{#43010} > Committed: https://chromium.googlesource.com/v8/v8/+/f3ae5ccf57690d8c2d87c4fe1d10b103ad6a4ab3 TBR=marja@chromium.org,adamk@chromium.org,neis@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5636 Review-Url: https://codereview.chromium.org/2686663002 Cr-Commit-Position: refs/heads/master@{#43013}
-
hablich authored
Revert of [parsing] Fix maybe-assigned for loop variables. (patchset #3 id:40001 of https://codereview.chromium.org/2673403003/ ) Reason for revert: Speculative revert because of https://codereview.chromium.org/2679163002/. Original issue's description: > [parsing] Fix maybe-assigned for loop variables. > > Due to hoisting, the value of a 'var'-declared variable may actually change even > if the code contains only the "initial" assignment, namely when that assignment > occurs inside a loop. For example: > > let i = 10; > do { var x = i } while (i--): > > As a simple and very conservative approximation of this, we explicitly mark > as maybe-assigned any non-lexical variable whose "declaration" does not > syntactically occur in the function scope. (In the example above, it > occurs in a block scope.) > > BUG=v8:5636 > > Review-Url: https://codereview.chromium.org/2673403003 > Cr-Commit-Position: refs/heads/master@{#42989} > Committed: https://chromium.googlesource.com/v8/v8/+/a33fcd663b28b8846e12b97c30d6e7d837767f86 TBR=marja@chromium.org,adamk@chromium.org,neis@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5636 Review-Url: https://codereview.chromium.org/2679263002 Cr-Commit-Position: refs/heads/master@{#43010}
-
neis authored
Due to hoisting, the value of a 'var'-declared variable may actually change even if the code contains only the "initial" assignment, namely when that assignment occurs inside a loop. For example: let i = 10; do { var x = i } while (i--): As a simple and very conservative approximation of this, we explicitly mark as maybe-assigned any non-lexical variable whose "declaration" does not syntactically occur in the function scope. (In the example above, it occurs in a block scope.) BUG=v8:5636 Review-Url: https://codereview.chromium.org/2673403003 Cr-Commit-Position: refs/heads/master@{#42989}
-
- 01 Feb, 2017 1 commit
-
-
adamk authored
The hoist_scope member of DeclarationDescriptor was only used to pass the function scope for declaration of parameters containing sloppy evals, for example: function f(x = eval("var y")) { } In cases like this, "x" is declared in the function scope but "y" is declared in an inner scope. Rather than passing the function scope as "hoist_scope", we simply ask for the outer_scope() of the inner scope as needed in PatternRewriter. This reduces the cognitive overhead of understanding what a DeclarationDescriptor has; for example, it removes some dead code from the PreParser which never has to deal with a situation like the example above. Review-Url: https://codereview.chromium.org/2662183002 Cr-Commit-Position: refs/heads/master@{#42861}
-
- 31 Jan, 2017 1 commit
-
-
neis authored
A previous CL (https://codereview.chromium.org/2634123002) did that for let-declared variables. This CL also does it for var- and function-declared variables. BUG=v8:5636 Review-Url: https://codereview.chromium.org/2656753003 Cr-Commit-Position: refs/heads/master@{#42813}
-
- 30 Jan, 2017 1 commit
-
-
mvstanton authored
They have the same lifetime. It's a match! Both structures are native context dependent and dealt with (creation, clearing, gathering feedback) at the same time. By treating the spaces used for literal boilerplates as feedback vector slots, we no longer have to keep track of the materialized literal count elsewhere. A follow-on CL removes even more parser infrastructure related to this count. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2655853010 Cr-Commit-Position: refs/heads/master@{#42771}
-
- 21 Jan, 2017 1 commit
-
-
gsathya authored
Convert strings to numbers if possible in the runtime call and store in excluded property list. BUG=v8:5549 Review-Url: https://codereview.chromium.org/2639333004 Cr-Commit-Position: refs/heads/master@{#42581}
-
- 18 Jan, 2017 2 commits
-
-
neis authored
R=adamk@chromium.org BUG= Review-Url: https://codereview.chromium.org/2645503002 Cr-Commit-Position: refs/heads/master@{#42472}
-
gsathya authored
This rewrites the rest property into a runtime call which sets up the correct properties in the newly created object. - Changes flag to --harmony-object-rest-spread - Changes pattern rewriter to desugar rest property - Adds new runtime function CopyDataPropertiesWithExcludedProperties BUG=v8:5549 Review-Url: https://codereview.chromium.org/2620943002 Cr-Commit-Position: refs/heads/master@{#42430}
-
- 17 Jan, 2017 1 commit
-
-
neis authored
We have to pessimistically assume that top-level variables will be assigned. This is because there may be lazily parsed top-level functions, which, for efficiency, we preparse without variable tracking. R=adamk@chromium.org, marja@chromium.org CC=jarin@chromium.org BUG=v8:5636 Review-Url: https://codereview.chromium.org/2634123002 Cr-Commit-Position: refs/heads/master@{#42398}
-
- 10 Jan, 2017 1 commit
-
-
gsathya authored
R=adamk@chromium.org Review-Url: https://codereview.chromium.org/2626493002 Cr-Commit-Position: refs/heads/master@{#42156}
-
- 09 Jan, 2017 1 commit
-
-
marja authored
Downside: this adds all kinds of weird includes in the .cc files. (See design doc linked in the bug.) BUG=v8:5402 Review-Url: https://codereview.chromium.org/2622503002 Cr-Commit-Position: refs/heads/master@{#42140}
-
- 08 Dec, 2016 1 commit
-
-
neis authored
This CL attempts to set the maybe-assigned flag for variables that are written to as part of a destructuring or loop header. For instance, in the following two cases we now mark x as maybe-assigned. a) [x] = [1]; b) for (x of [1,2,3]) {}; There's more work to do here, this is just a first step. R=adamk@chromium.org, mstarzinger@chromium.org BUG=v8:5636 Review-Url: https://codereview.chromium.org/2562443003 Cr-Commit-Position: refs/heads/master@{#41582}
-
- 07 Dec, 2016 1 commit
-
-
caitp authored
Introduces: - a new AST node representing the GetIterator() algorithm in the specification, to be used by ForOfStatement, YieldExpression (in the case of delegating yield*), and the future `for-await-of` loop proposed in http://tc39.github.io/proposal-async-iteration/#sec-async-iterator-value-unwrap-functions. - a new opcode (JumpIfJSReceiver), which is useful for `if Type(object) is not Object` checks which are common throughout the specification. This node is easily eliminated by TurboFan. The AST node is desugared specially in bytecode, rather than manually when building the AST. The benefit of this is that desugaring in the BytecodeGenerator is much simpler and easier to understand than desugaring the AST. This also reduces parse time very slightly, and allows us to use LoadIC rather than KeyedLoadIC, which seems to have better baseline performance. This results in a ~20% improvement in test/js-perf-test/Iterators micro-benchmarks, which I believe owes to the use of the slightly faster LoadIC as opposed to the KeyedLoadIC in the baseline case. Both produce identical optimized code via TurboFan when the type check can be eliminated, and the load can be replaced with a constant value. BUG=v8:4280 R=bmeurer@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, neis@chromium.org, jarin@chromium.org TBR=rossberg@chromium.org Review-Url: https://codereview.chromium.org/2557593004 Cr-Commit-Position: refs/heads/master@{#41555}
-
- 24 Nov, 2016 1 commit
-
-
neis authored
The catch scopes were created with the wrong parent scope. R=littledan@chromium.org BUG=v8:5648 Committed: https://crrev.com/f385268d11d6da9508e481202b39f75f4b56afdd Review-Url: https://codereview.chromium.org/2520883002 Cr-Original-Commit-Position: refs/heads/master@{#41222} Cr-Commit-Position: refs/heads/master@{#41253}
-
- 23 Nov, 2016 2 commits
-
-
machenbach authored
Revert of [parser] Fix scopes in rewriting of for-of and destructuring assignments. (patchset #6 id:100001 of https://codereview.chromium.org/2520883002/ ) Reason for revert: Speculative revert: Seems to break jsfunfuzz: https://build.chromium.org/p/client.v8/builders/V8%20Fuzzer/builds/14385 Original issue's description: > [parser] Fix scopes in rewriting of for-of and destructuring assignments. > > The catch scopes were created with the wrong parent scope. > > R=littledan@chromium.org > BUG=v8:5648 > > Committed: https://crrev.com/f385268d11d6da9508e481202b39f75f4b56afdd > Cr-Commit-Position: refs/heads/master@{#41222} TBR=littledan@chromium.org,verwaest@chromium.org,neis@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5648 Review-Url: https://codereview.chromium.org/2519333005 Cr-Commit-Position: refs/heads/master@{#41228}
-
neis authored
The catch scopes were created with the wrong parent scope. R=littledan@chromium.org BUG=v8:5648 Review-Url: https://codereview.chromium.org/2520883002 Cr-Commit-Position: refs/heads/master@{#41222}
-
- 27 Oct, 2016 1 commit
-
-
neis authored
We used to point elsewhere, for instance the right-hand-side of an assignment. Small limitation: Since variable proxies only have a start position, not an end position, the best we can do is point at the first character. (We cannot rely on the scanner's last token position because Declare may be called long after the variable has been scanned.) R=adamk@chromium.org BUG=v8:5572 Review-Url: https://codereview.chromium.org/2447143005 Cr-Commit-Position: refs/heads/master@{#40613}
-
- 25 Oct, 2016 1 commit
-
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2445993002 Cr-Commit-Position: refs/heads/master@{#40548}
-
- 07 Oct, 2016 1 commit
-
-
adamk authored
Both bits of code were pointed out by our test coverage tools. R=gsathya@chromium.org Review-Url: https://codereview.chromium.org/2394403002 Cr-Commit-Position: refs/heads/master@{#40095}
-
- 19 Sep, 2016 1 commit
-
-
verwaest authored
BUG=v8:5209 Review-Url: https://codereview.chromium.org/2349193002 Cr-Commit-Position: refs/heads/master@{#39514}
-
- 07 Sep, 2016 1 commit
-
-
marja authored
This moves scope-related logic (such as looking up variables) to Scope where it belongs, and enables PreParser to do more Scope-related operations in the future. BUG= Review-Url: https://codereview.chromium.org/2301183003 Cr-Commit-Position: refs/heads/master@{#39233}
-
- 02 Sep, 2016 1 commit
-
-
nikolaos authored
R=adamk@chromium.org, littledan@chromium.org BUG=v8:5337 LOG=N Review-Url: https://codereview.chromium.org/2297303003 Cr-Commit-Position: refs/heads/master@{#39118}
-
- 31 Aug, 2016 1 commit
-
-
adamk authored
The only remaining use of this VariableMode is for the names of sloppy named function expressions. This patch instead uses CONST for such bindings (just as we do in strict mode) and instead marks those Variables specially. During code generation a new helper method, Variable::throw_on_const_assignment(), is called to decide whether to throw or silently ignore the assignment. Review-Url: https://codereview.chromium.org/2233673003 Cr-Commit-Position: refs/heads/master@{#39052}
-