- 02 Sep, 2015 1 commit
-
-
caitpotter88 authored
Kills the kRestParameter bailout/disabled optimization, and fixes lazily parsed arrow functions with rest parameters. Supercedes https://crrev.com/1235153006/ BUG=chromium:508074, v8:2160, v8:2700 LOG=N R=rossberg@chromium.org, adamk@chromium.org, wingo@igalia.com Review URL: https://codereview.chromium.org/1272673003 Cr-Commit-Position: refs/heads/master@{#30550}
-
- 26 Aug, 2015 1 commit
-
-
conradw authored
TC39 agreed to disallow "use strict" directives in function body when non-simple parameter lists are used. This is a continuation of caitp's CL https://codereview.chromium.org/1281163002/ with some refactorings removed for now. Still TODO: there is a lot of duplication between the is_simple field of FormalParametersBase and the NonSimpleParameter property ExpressionClassifier keeps track of. It should be possible to remove the former with a minor refactoring of arrow function parsing. This will be attempted in a follow-up CL. BUG= LOG=N Review URL: https://codereview.chromium.org/1300103005 Cr-Commit-Position: refs/heads/master@{#30388}
-
- 25 Aug, 2015 2 commits
-
-
rossberg authored
R=littledan@chromium.org BUG= Review URL: https://codereview.chromium.org/1303013007 Cr-Commit-Position: refs/heads/master@{#30363}
-
rossberg authored
R=adamk@chromium.org BUG=v8:2160 LOG=N Review URL: https://codereview.chromium.org/1311163002 Cr-Commit-Position: refs/heads/master@{#30361}
-
- 24 Aug, 2015 1 commit
-
-
littledan authored
The ES2015 specification for switch statements 13.12.11 specifies that they get their own lexical scope. This patch introduces such a scope through a complex desugaring in terms of blocks, done so that Crankshaft does not have to be updated to support multiple constructs providing scopes. Recommitting this patch after a bug fix in Crankshaft to allow a desugaring with certain elements missing a source location: https://codereview.chromium.org/1313443002 BUG=v8:4377 LOG=Y R=adamk Review URL: https://codereview.chromium.org/1309163003 Cr-Commit-Position: refs/heads/master@{#30340}
-
- 22 Aug, 2015 1 commit
-
-
littledan authored
Revert of Add a separate scope for switch (patchset #7 id:120001 of https://codereview.chromium.org/1293283002/ ) Reason for revert: Breaks cctest/test-cpu-profiler/SourceLocation on nosnap Original issue's description: > Add a separate scope for switch > > The ES2015 specification for switch statements 13.12.11 specifies that > they get their own lexical scope. This patch introduces such a scope > through a complex desugaring in terms of blocks, done so that Crankshaft > does not have to be updated to support multiple constructs providing > scopes. > > BUG=v8:4377 > LOG=Y > R=adamk > > Committed: https://crrev.com/9edbc1f21eb1050cabbe3b8bc9aebf89ada7ebd7 > Cr-Commit-Position: refs/heads/master@{#30314} TBR=adamk@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4377 Review URL: https://codereview.chromium.org/1309043004 Cr-Commit-Position: refs/heads/master@{#30316}
-
- 21 Aug, 2015 2 commits
-
-
littledan authored
The ES2015 specification for switch statements 13.12.11 specifies that they get their own lexical scope. This patch introduces such a scope through a complex desugaring in terms of blocks, done so that Crankshaft does not have to be updated to support multiple constructs providing scopes. BUG=v8:4377 LOG=Y R=adamk Review URL: https://codereview.chromium.org/1293283002 Cr-Commit-Position: refs/heads/master@{#30314}
-
rossberg authored
This CL is a nightmare! For the utterly irrelevant edge case of a sloppy function with non-simple parameters and a call to direct eval, like here, let x = 1; function f(g = () => x) { var y eval("var x = 2") return g() + x // f() = 3 } we have to do all of the following, on top of the declaration block ("varblock") contexts we already introduce around the body: - Introduce the ability for varblock contexts to have both a ScopeInfo and an extension object (e.g., the body varblock in the example will contain both a static var y and a dynamic var x). No other scope needs that. Since there are no context slots left, a special new struct is introduced that pairs up scope info and extension object. - When declaring lookup slots in the runtime, this new struct is allocated in the case where an extension object has to be added to a block scope (at which point the block's extension slot still contains a plain ScopeInfo). - While at it, introduce some abstraction to access context extension slots in a more controlled manner, in order to keep special-casing to a minimum. - Make sure that even empty varblock contexts do not get optimised away when they contain a sloppy eval, so that they can host the potential extension object. - Extend dynamic search for declaration contexts (used by sloppy direct eval) to recognize varblock contexts. - In the parser, if a function has a sloppy direct eval, introduce an additional varblock scope around each non-simple (desugared) parameter, as required by the spec to contain possible dynamic var bindings. - In the pattern rewriter, add the ability to hoist the named variables the pattern declares to an outer scope. That is required because the actual destructuring has to be evaluated inside the protecting varblock scope, but the bindings that the desugaring introduces are in the outer scope. - ScopeInfos need to save the information whether a block is a varblock, to make sloppy eval calls work correctly that deserialise them as part of the scope chain. - Add the ability to materialize block scopes with extension objects in the debugger. Likewise, enable setting extension variables in block scopes via the debugger interface. - While at it, refactor and unify some respective code in the debugger. Sorry, this CL is large. I could try to split it up, but everything is rather entangled. @mstarzinger: Please review the changes to contexts. @yangguo: Please have a look at the debugger stuff. R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:811,v8:2160 LOG=N Review URL: https://codereview.chromium.org/1292753007 Cr-Commit-Position: refs/heads/master@{#30295}
-
- 19 Aug, 2015 1 commit
-
-
titzer authored
R=rossberg@chromium.org BUG= Review URL: https://codereview.chromium.org/1301583005 Cr-Commit-Position: refs/heads/master@{#30254}
-
- 17 Aug, 2015 1 commit
-
-
rossberg authored
Based on caitp's https://codereview.chromium.org/1127063003/ R=adamk@chromium.org, littledan@chromium.org BUG=v8:2160 LOG=N Review URL: https://codereview.chromium.org/1287063004 Cr-Commit-Position: refs/heads/master@{#30192}
-
- 05 Aug, 2015 1 commit
-
-
rossberg authored
Previously, examples like (({a = x}, x) => {})({}, 0) did not throw a ReferenceError like they should. This CL - Splits up DeclareFormalParameters such that the formals can be recorded first and declared later. - Declaration then takes the complete parameter list into account. If it is not simple, temporaries are introduced for all parameters. - BuildParameterInitializationBlock desugars all parameters from non-simple lists into let-bindings. - Refactored Pre/ParserFormalParameters, so that the arity information is no longer duplicated in Parser. - Rest is currently handled specially, until rest-via-destructuring has landed. R=adamk@chromium.org, littledan@chromium.org BUG=v8:811 LOG=N Review URL: https://codereview.chromium.org/1259283002 Cr-Commit-Position: refs/heads/master@{#30025}
-
- 04 Aug, 2015 2 commits
-
-
rossberg authored
Store arity in FormalParameters; store name (instead of var) and is_rest flag in individual parameters. Ensure that the arity is always maintained consistently. This is preparation for more parameter destructuring adjustments. In particular, a follow-up CL will separate parameter recording from declaring the variables. R=adamk@chromium.org, littledan@chromium.org BUG=v8:811 LOG=N Review URL: https://codereview.chromium.org/1259013003 Cr-Commit-Position: refs/heads/master@{#30002}
-
rossberg authored
They need to be properly recorded in the scope's temps set, otherwise allocation doesn't know about them and can break. (Not observable right now, but necessary for follow-up changes to parameter destructuring.) Also, print temporary variables in a useful manner. R=adamk@chromium.org BUG= Review URL: https://codereview.chromium.org/1263563002 Cr-Commit-Position: refs/heads/master@{#29998}
-
- 03 Aug, 2015 1 commit
-
-
yangguo authored
Otherwise we may choose sloppy const or strict const depending on whether the function is parsed the first time. R=mvstanton@chromium.org BUG=v8:4336 LOG=N Review URL: https://codereview.chromium.org/1260053004 Cr-Commit-Position: refs/heads/master@{#29966}
-
- 23 Jul, 2015 2 commits
-
-
rossberg authored
Gets rid of IsSimpleParameterList predicate. R=mstarzinger@chromium.org, caitpotter88@gmail.com BUG= Review URL: https://codereview.chromium.org/1251603004 Cr-Commit-Position: refs/heads/master@{#29815}
-
rossberg authored
In particular, rename FormalParameterParsingState and friends to FormalParameters etc. This should not change any logic, but is a preparatory CL for a bunch of follow-up fixes and clean-ups. R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1247443004 Cr-Commit-Position: refs/heads/master@{#29807}
-
- 16 Jul, 2015 1 commit
-
-
caitpotter88 authored
BUG= LOG=N R=rossberg@chromium.org Review URL: https://codereview.chromium.org/1234213004 Cr-Commit-Position: refs/heads/master@{#29710}
-
- 15 Jul, 2015 1 commit
-
-
mvstanton authored
A sloppy mode eval call that establishes strict mode will leak that strictness into the sloppy surrounding scope on recompile. This changes the structure of the type feedback vector for the function and crashes follow. The fix is straightforward. BUG=491536, 503565 LOG=N Review URL: https://codereview.chromium.org/1231343003 Cr-Commit-Position: refs/heads/master@{#29671}
-
- 09 Jul, 2015 1 commit
-
-
adamk authored
When running without a snapshot, the GlobalEval function gets lazy compiled. By the time we compile it, its name is "eval", which causes the parser to choke (functions named "eval" aren't allowed in strict mode!). Instead, we now always skip checking the function name when lazy-parsing, as the name has already been checked appropriately by the preparser. Also cleaned up other cases that don't require name checking by introducing FunctionNameValidity enum and passing appropriate values throughout the parser and preparser. This lets us pass an additional 18 test262 tests. BUG=v8:4198 LOG=n Review URL: https://codereview.chromium.org/1227093005 Cr-Commit-Position: refs/heads/master@{#29559}
-
- 26 Jun, 2015 1 commit
-
-
dslomov authored
R=wingo@igalia.com BUG=v8:811 LOG=N Review URL: https://codereview.chromium.org/1212473002 Cr-Commit-Position: refs/heads/master@{#29337}
-
- 24 Jun, 2015 1 commit
-
-
dslomov authored
JS runtime function calls cause Hydrogen to bail out. R=adamk@chromiunm.org,arv@chromium.org Review URL: https://codereview.chromium.org/1210533003 Cr-Commit-Position: refs/heads/master@{#29260}
-
- 22 Jun, 2015 3 commits
-
-
dslomov authored
Scoping for initializers is yet incorrect. Defaults are not supported. R=arv@chromium.org,rossberg@chromium.org BUG=v8:811 LOG=N Committed: https://crrev.com/42f30f4ded2b1ca0c4caa7639e6206e93c78ee70 Cr-Commit-Position: refs/heads/master@{#29184} Review URL: https://codereview.chromium.org/1189743003 Cr-Commit-Position: refs/heads/master@{#29192}
-
machenbach authored
Revert of [destructuring] Implement parameter pattern matching. (patchset #7 id:120001 of https://codereview.chromium.org/1189743003/) Reason for revert: [Sheriff] Breaks tsan: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/4392 Original issue's description: > [destructuring] Implement parameter pattern matching. > > Scoping for initializers is yet incorrect. Defaults are not supported. > > R=arv@chromium.org,rossberg@chromium.org > BUG=v8:811 > LOG=N > > Committed: https://crrev.com/42f30f4ded2b1ca0c4caa7639e6206e93c78ee70 > Cr-Commit-Position: refs/heads/master@{#29184} TBR=arv@chromium.org,rossberg@chromium.org,caitpotter88@gmail.com,wingo@igalia.com,dslomov@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:811 Review URL: https://codereview.chromium.org/1195163007 Cr-Commit-Position: refs/heads/master@{#29188}
-
dslomov authored
Scoping for initializers is yet incorrect. Defaults are not supported. R=arv@chromium.org,rossberg@chromium.org BUG=v8:811 LOG=N Review URL: https://codereview.chromium.org/1189743003 Cr-Commit-Position: refs/heads/master@{#29184}
-
- 15 Jun, 2015 1 commit
-
-
dslomov authored
R=arv@chromium.org,wingo@igalia.com,caitpotter88@gmail.com LOG=N BUG=v8:811 Review URL: https://codereview.chromium.org/1167393005 Cr-Commit-Position: refs/heads/master@{#29029}
-
- 10 Jun, 2015 1 commit
-
-
wingo authored
R=dslomov@chromium.org, rossberg@chromium.org LOG=Y BUG=v8:2700 Review URL: https://codereview.chromium.org/1178523002 Cr-Commit-Position: refs/heads/master@{#28908}
-
- 09 Jun, 2015 4 commits
-
-
dslomov authored
Pushed the detection logic down to ParseAndClassifyIdentifier in preparation to having patterns in parameter positions. R=arv@chromium.org,rossberg@chromium.org,wingo@igalia.com BUG=v8:811 LOG=N Review URL: https://codereview.chromium.org/1170153003 Cr-Commit-Position: refs/heads/master@{#28876}
-
arv authored
Revert of Revert of [es6] Parsing of new.target (patchset #1 id:1 of https://codereview.chromium.org/1170263002/) Reason for revert: The bot needs to be clobbered. Original issue's description: > Revert of [es6] Parsing of new.target (patchset #2 id:20001 of https://codereview.chromium.org/1169853002/) > > Reason for revert: > [Sheriff] fails messages: > http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20custom%20snapshot%20-%20debug/builds/1703 > > Original issue's description: > > [es6] Parsing of new.target > > > > BUG=v8:3887 > > LOG=N > > R=adamk@chromium.org, dslomov@chromium.org > > > > Committed: https://crrev.com/ae06bdde7763d673b39948b710df414217265cce > > Cr-Commit-Position: refs/heads/master@{#28865} > > TBR=adamk@chromium.org,dslomov@chromium.org,arv@chromium.org > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:3887 > > Committed: https://crrev.com/fe97cfccf3faabbeff87b9b5fbacd7ceb8219304 > Cr-Commit-Position: refs/heads/master@{#28868} TBR=adamk@chromium.org,dslomov@chromium.org,machenbach@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:3887 Review URL: https://codereview.chromium.org/1168393008 Cr-Commit-Position: refs/heads/master@{#28870}
-
machenbach authored
Revert of [es6] Parsing of new.target (patchset #2 id:20001 of https://codereview.chromium.org/1169853002/) Reason for revert: [Sheriff] fails messages: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20custom%20snapshot%20-%20debug/builds/1703 Original issue's description: > [es6] Parsing of new.target > > BUG=v8:3887 > LOG=N > R=adamk@chromium.org, dslomov@chromium.org > > Committed: https://crrev.com/ae06bdde7763d673b39948b710df414217265cce > Cr-Commit-Position: refs/heads/master@{#28865} TBR=adamk@chromium.org,dslomov@chromium.org,arv@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:3887 Review URL: https://codereview.chromium.org/1170263002 Cr-Commit-Position: refs/heads/master@{#28868}
-
arv authored
BUG=v8:3887 LOG=N R=adamk@chromium.org, dslomov@chromium.org Review URL: https://codereview.chromium.org/1169853002 Cr-Commit-Position: refs/heads/master@{#28865}
-
- 04 Jun, 2015 1 commit
-
-
arv authored
We used to only store the uses_super_property in the preparse data logger. Let the logger use NeedsHomeObject instead. BUG=v8:3768 LOG=N R=wingo, adamk Review URL: https://codereview.chromium.org/1164073003 Cr-Commit-Position: refs/heads/master@{#28806}
-
- 02 Jun, 2015 1 commit
-
-
arv authored
This splits the SuperReference AST node into SuperPropertyReference and SuperCallReference. The super call reference node consists of three unresolved vars to this, new.target and this_function. These gets declared when the right function is entered and if it is in use. The variables gets assigned in FullCodeGenerator::Generate. This is a revert of the revert 88b1c917 BUG=v8:3768 LOG=N R=wingo@igalia.com, adamk@chromium.org Review URL: https://codereview.chromium.org/1168513004 Cr-Commit-Position: refs/heads/master@{#28769}
-
- 01 Jun, 2015 4 commits
-
-
caitpotter88 authored
Revert of [es6] implement default parameters via desugaring (patchset #19 id:380001 of https://codereview.chromium.org/1127063003/) Reason for revert: Broken on arm64 Original issue's description: > [es6] implement default parameters via desugaring > > Stage 1 implementation: > > - Parameters can't be referenced before initialized (from left-to-right) > - SingleNameBindings only, no support for BindingPatterns > > Known issues: > > - Incorrect scoping (parameter expressions may reference variables declared in function body) > - Function arity is untouched > - Hole-checking needs work > - Rest parameters are broken when mixed with optional arguments > > BUG=v8:2160 > LOG=N > R=arv@chromium.org, rossberg@chromium.org > > Committed: https://crrev.com/892c85485881f8be2f17bd83238980f858126576 > Cr-Commit-Position: refs/heads/master@{#28739} TBR=rossberg@chromium.org,wingo@igalia.com,arv@chromium.org,dslomov@chromium.org,adamk@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:2160 Review URL: https://codereview.chromium.org/1163853002 Cr-Commit-Position: refs/heads/master@{#28740}
-
caitpotter88 authored
Stage 1 implementation: - Parameters can't be referenced before initialized (from left-to-right) - SingleNameBindings only, no support for BindingPatterns Known issues: - Incorrect scoping (parameter expressions may reference variables declared in function body) - Function arity is untouched - Hole-checking needs work - Rest parameters are broken when mixed with optional arguments BUG=v8:2160 LOG=N R=arv@chromium.org, rossberg@chromium.org Review URL: https://codereview.chromium.org/1127063003 Cr-Commit-Position: refs/heads/master@{#28739}
-
arv authored
Revert of [es6] Super call in arrows and eval (patchset #5 id:100001 of https://codereview.chromium.org/1146863007/) Reason for revert: Fails http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug%20-%201/builds/579/steps/Check/logs/super Original issue's description: > [es6] Super call in arrows and eval > > This splits the SuperReference AST node into SuperPropertyReference and > SuperCallReference. The super call reference node consists of three > unresolved vars to this, new.target and this_function. These gets > declared when the right function is entered and if it is in use. The > variables gets assigned in FullCodeGenerator::Generate. > > BUG=v8:3768 > LOG=N > R=wingo@igalia.com, adamk@chromium.org > > Committed: https://crrev.com/673c0516ab96f24343bbb26e0afc2846b5a679df > Cr-Commit-Position: refs/heads/master@{#28731} TBR=wingo@igalia.com,adamk@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:3768 Review URL: https://codereview.chromium.org/1161243005 Cr-Commit-Position: refs/heads/master@{#28735}
-
arv authored
This splits the SuperReference AST node into SuperPropertyReference and SuperCallReference. The super call reference node consists of three unresolved vars to this, new.target and this_function. These gets declared when the right function is entered and if it is in use. The variables gets assigned in FullCodeGenerator::Generate. BUG=v8:3768 LOG=N R=wingo@igalia.com, adamk@chromium.org Review URL: https://codereview.chromium.org/1146863007 Cr-Commit-Position: refs/heads/master@{#28731}
-
- 26 May, 2015 1 commit
-
-
arv authored
When we enter a method that needs access to the [[HomeObject]] we allocate a local variable `.home_object` and assign it the value from the [[HomeObject]] private symbol. Something along the lines of: method() { var .home_object = %ThisFunction()[home_object_symbol]; ... } BUG=v8:3867, v8:4031 LOG=N Review URL: https://codereview.chromium.org/1135243004 Cr-Commit-Position: refs/heads/master@{#28644}
-
- 21 May, 2015 1 commit
-
-
dslomov authored
Also support patterns in ``for (var p in/of ...)`` This CL extends the rewriting we used to do for ``for (let p in/of...)`` to ``for (var p in/of ...)``. For all for..in/of loop declaring variable, we rewrite for (var/let/const pattern in/of e) b into for (x' in/of e) { var/let/const pattern = e; b } This adds a small complication for debugger: for a statement for (var v in/of e) ... we used to have var v; for (v in/of e) ... and there was a separate breakpoint on ``var v`` line. This breakpoint is actually useless since it is immediately followed by a breakpoint on evaluation of ``e``, so this CL removes that breakpoint location. Similiraly, for let, it used to be that for (let v in/of e) ... became for (x' in/of e) { let v; v = x'; ... } ``let v``generetaed a useless breakpoint (with the location at the loop's head. This CL removes that breakpoint as well. R=arv@chromium.org,rossberg@chromium.org BUG=v8:811 LOG=N Review URL: https://codereview.chromium.org/1149043005 Cr-Commit-Position: refs/heads/master@{#28565}
-
- 20 May, 2015 1 commit
-
-
dslomov authored
(everything except Spread is implemeneted) R=arv@chromium.org,rossberg@chromium.org,wingo@igalia.com BUG=v8:811 LOG=N Review URL: https://codereview.chromium.org/1139603005 Cr-Commit-Position: refs/heads/master@{#28500}
-
- 19 May, 2015 1 commit
-
-
dslomov authored
R=arv@chromium.org,rossberg@chromium.org,wingo@igalia.com BUG=v8:811 LOG=N Review URL: https://codereview.chromium.org/1146683002 Cr-Commit-Position: refs/heads/master@{#28482}
-