- 26 Nov, 2015 1 commit
-
-
rossberg authored
Moves all files related to AST and scopes into ast/, and all files related to scanner & parser to parsing/. Also eliminates a couple of spurious dependencies. R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1481613002 Cr-Commit-Position: refs/heads/master@{#32351}
-
- 29 Oct, 2015 3 commits
-
-
adamk authored
This requires copying usage flags from the outer scope to the arrow scope upon encountering the arrow token. In order to properly pass-on the calls_eval bit, now record that bit on script scopes just like everywhere else, and add necessary code to scopes.cc to handle that change in behavior. Also factored out scope flag propagation to its own method to make the call site simple (though note that only the eval bit makes any difference for arrows). BUG=v8:4395 LOG=n Review URL: https://codereview.chromium.org/1423613002 Cr-Commit-Position: refs/heads/master@{#31660}
-
adamk authored
The fix is to broaden the set of cases for when NeedsHomeObject() returns true. Note that this is broader than it needs to be (since, e.g., non-arrow function scopes inside a method can't reference super). But we don't track the types of inner scopes at the moment, so this is the best we can do. R=rossberg@chromium.org BUG=v8:4522 LOG=n Review URL: https://codereview.chromium.org/1411093008 Cr-Commit-Position: refs/heads/master@{#31659}
-
adamk authored
R=littledan@chromium.org Review URL: https://codereview.chromium.org/1430643003 Cr-Commit-Position: refs/heads/master@{#31644}
-
- 27 Oct, 2015 1 commit
-
-
adamk authored
- inner_scope_uses_arguments_ was completely unused - The public accessor for contains_with() was not called - inside_with() had helper methods on Parser and PatternRewriter, but was only called in one place. Review URL: https://codereview.chromium.org/1409253007 Cr-Commit-Position: refs/heads/master@{#31587}
-
- 21 Oct, 2015 1 commit
-
-
adamk authored
When eagerly parsing arrow functions, expressions in default parameter initializers are parsed in the enclosing scope, rather than in the function's scope (since that scope does not yet exist). This leads to VariableProxies being added to the wrong scope, and scope chains for FunctionLiterals being incorrect. This patch addresses these problems by adding a subclass of AstExpressionVisitor that moves VariableProxies to the proper scope and fixes up scope chains of FunctionLiterals. This is a revert of the revert https://crrev.com/e41614a058426fb6102e4ab2dd4f98997f00c0fc with a much-improved (though not yet perfect) Scope::ResetOuterScope method which properly fixes not only the outer_scope_ pointer but also fixes the inner_scope_ list in the relevant outer_scopes. More work likely still needs to be done to make this work completely, but it's very close to correct. BUG=v8:4395 LOG=y Review URL: https://codereview.chromium.org/1414283002 Cr-Commit-Position: refs/heads/master@{#31435}
-
- 20 Oct, 2015 2 commits
-
-
bmeurer authored
Revert of [es6] Fix scoping for default parameters in arrow functions (patchset #5 id:80001 of https://codereview.chromium.org/1405313002/ ) Reason for revert: Breaks nosnap: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug%20-%202/builds/2407/steps/Check/logs/regress-4395 Original issue's description: > [es6] Fix scoping for default parameters in arrow functions > > When eagerly parsing arrow functions, expressions in default > parameter initializers are parsed in the enclosing scope, > rather than in the function's scope (since that scope does not > yet exist). This leads to VariableProxies being added to the > wrong scope, and scope chains for FunctionLiterals being incorrect. > > This patch addresses these problems by adding a subclass of > AstExpressionVisitor that moves VariableProxies to the proper > scope and fixes up scope chains of FunctionLiterals. > > More work likely still needs to be done to make this work completely, > but it's very close to correct. > > BUG=v8:4395 > LOG=y > > Committed: https://crrev.com/cf72aad39e51de9b7074ea039377c1812f4a2c6b > Cr-Commit-Position: refs/heads/master@{#31402} TBR=rossberg@chromium.org,caitpotter88@gmail.com,adamk@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4395 Review URL: https://codereview.chromium.org/1417463004 Cr-Commit-Position: refs/heads/master@{#31404}
-
adamk authored
When eagerly parsing arrow functions, expressions in default parameter initializers are parsed in the enclosing scope, rather than in the function's scope (since that scope does not yet exist). This leads to VariableProxies being added to the wrong scope, and scope chains for FunctionLiterals being incorrect. This patch addresses these problems by adding a subclass of AstExpressionVisitor that moves VariableProxies to the proper scope and fixes up scope chains of FunctionLiterals. More work likely still needs to be done to make this work completely, but it's very close to correct. BUG=v8:4395 LOG=y Review URL: https://codereview.chromium.org/1405313002 Cr-Commit-Position: refs/heads/master@{#31402}
-
- 15 Oct, 2015 1 commit
-
-
rmcilroy authored
Adds Scope::MaxNestedContextChainLength() which calculates the maximum length of the context chain for the given scope. This is used by the interpreter to preallocate the approprate number of context registers when compiling the function. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1404793004 Cr-Commit-Position: refs/heads/master@{#31309}
-
- 09 Oct, 2015 1 commit
-
-
adamk authored
Scope has no subclasses, so "protected" should just be "private". And there is no ParserFactory class, so making it a friend doesn't buy us anything. Review URL: https://codereview.chromium.org/1393303005 Cr-Commit-Position: refs/heads/master@{#31201}
-
- 07 Oct, 2015 1 commit
-
-
adamk authored
Previously, arrow function scopes had a separate ScopeType. However, Scope::DeserializeScopeChain() erroneously deserialized ARROW_SCOPE ScopeInfos as FUNCTION_SCOPE. This could lead to bugs such as the attached one, where "super" was disallowed where it should have been allowed. This patch utilizes the Scope's FunctionKind to distinguish arrow functions from others. Besides fixing the above bug, this also simplifies code in various places that had to deal with two different ScopeTypes both of which meant "function". BUG=v8:4466 LOG=n Review URL: https://codereview.chromium.org/1386253002 Cr-Commit-Position: refs/heads/master@{#31154}
-
- 30 Sep, 2015 1 commit
-
-
mstarzinger authored
This enables linter checking for "readability/namespace" violations during presubmit and instead marks the few known exceptions that we allow explicitly. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1371083003 Cr-Commit-Position: refs/heads/master@{#31019}
-
- 24 Sep, 2015 3 commits
-
-
bmeurer authored
There was already a bit on the Map named "function with prototype", which basically meant that the Map was a map for a JSFunction that could be used as a constructor. Now this CL generalizes that bit to IsConstructor, which says that whatever (Heap)Object you are looking at can be used as a constructor (i.e. the bit is also set for bound functions that can be used as constructors and proxies that have a [[Construct]] internal method). This way we have a single chokepoint for IsConstructor checking, which allows us to get rid of the various ways in which we tried to guess whether something could be used as a constructor or not. Drive-by-fix: Renamed IsConstructor on FunctionKind to IsClassConstructor to resolve the weird name clash, and the IsClassConstructor name also matches the spec. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg R=jarin@chromium.org, rossberg@chromium.org BUG=v8:4413, v8:4430 LOG=n Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54 Cr-Commit-Position: refs/heads/master@{#30900} Review URL: https://codereview.chromium.org/1358423002 Cr-Commit-Position: refs/heads/master@{#30902}
-
bmeurer authored
Revert of [es6] Introduce spec compliant IsConstructor. (patchset #2 id:20001 of https://codereview.chromium.org/1358423002/ ) Reason for revert: Failed on Fuzzer and MIPS bot. Original issue's description: > [es6] Introduce spec compliant IsConstructor. > > There was already a bit on the Map named "function with prototype", > which basically meant that the Map was a map for a JSFunction that could > be used as a constructor. Now this CL generalizes that bit to > IsConstructor, which says that whatever (Heap)Object you are looking at > can be used as a constructor (i.e. the bit is also set for bound > functions that can be used as constructors and proxies that have a > [[Construct]] internal method). > > This way we have a single chokepoint for IsConstructor checking, which > allows us to get rid of the various ways in which we tried to guess > whether something could be used as a constructor or not. > > Drive-by-fix: Renamed IsConstructor on FunctionKind to > IsClassConstructor to resolve the weird name clash, and the > IsClassConstructor name also matches the spec. > > R=jarin@chromium.org, rossberg@chromium.org > BUG=v8:4430 > LOG=n > > Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54 > Cr-Commit-Position: refs/heads/master@{#30900} TBR=jarin@chromium.org,rossberg@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4430 Review URL: https://codereview.chromium.org/1360403002 Cr-Commit-Position: refs/heads/master@{#30901}
-
bmeurer authored
There was already a bit on the Map named "function with prototype", which basically meant that the Map was a map for a JSFunction that could be used as a constructor. Now this CL generalizes that bit to IsConstructor, which says that whatever (Heap)Object you are looking at can be used as a constructor (i.e. the bit is also set for bound functions that can be used as constructors and proxies that have a [[Construct]] internal method). This way we have a single chokepoint for IsConstructor checking, which allows us to get rid of the various ways in which we tried to guess whether something could be used as a constructor or not. Drive-by-fix: Renamed IsConstructor on FunctionKind to IsClassConstructor to resolve the weird name clash, and the IsClassConstructor name also matches the spec. R=jarin@chromium.org, rossberg@chromium.org BUG=v8:4430 LOG=n Review URL: https://codereview.chromium.org/1358423002 Cr-Commit-Position: refs/heads/master@{#30900}
-
- 21 Sep, 2015 1 commit
-
-
littledan authored
ES2015 specifies very particular semantics for functions defined in blocks. In strict mode, it is simply a lexical binding scoped to that block. In sloppy mode, in addition to that lexical binding, there is a var-style binding in the outer scope, which is overwritten with the local binding when the function declaration is evaluated, *as long as* introducing ths var binding would not create a var/let conflict in the outer scope. This patch implements the semantics by introducing a DelegateStatement, which is initially filled in with the EmptyStatement and overwritten with the assignment when the scope is closed out and it can be checked that there is no conflict. This patch is tested with a new mjsunit test, and I tried staging it and running test262, finding that the tests that we have disabled due to lack of Annex B support now pass. R=adamk,rossberg LOG=Y BUG=v8:4285 Review URL: https://codereview.chromium.org/1332873003 Cr-Commit-Position: refs/heads/master@{#30842}
-
- 08 Sep, 2015 1 commit
-
-
mstarzinger authored
This switches Isolate::ComputeLocation to use baseline code when computing message locations. This unifies locations between optimized and non-optimized code by always going through the FrameSummary for location computation. R=bmeurer@chromium.org TEST=message/regress/regress-4266 BUG=v8:4266 LOG=n Review URL: https://codereview.chromium.org/1331603002 Cr-Commit-Position: refs/heads/master@{#30635}
-
- 28 Aug, 2015 1 commit
-
-
littledan authored
Switch statements introduce their own scope for cases, but this scope is not necessarily executed in order, as the following function shows: switch (x) { case 1: let y = 1; case 2: y = 2; case 3: print(y); } If x = 2 or x = 3, the code should throw a ReferenceError. However, FullCodeGen's hole check elimination used the simple algorithm of assuming that if the initializer was in the same scope, then it was reached before the use, and therefore the hole check could be eliminated. This patch adds an extra bit to scopes, to track if they may nonlinearly. The parser marks the scope that switch introduces as nonlinear. FullCodeGen does not eliminate the hole check from a scope which is nonlinear. This patch refactors FullCodeGen to put the hole check elimination in one place, rather than in each backend. BUG=v8:3926 LOG=Y R=adamk Review URL: https://codereview.chromium.org/1312613003 Cr-Commit-Position: refs/heads/master@{#30453}
-
- 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 1 commit
-
-
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}
-
- 11 Aug, 2015 1 commit
-
-
littledan authored
In ES6, direct eval() in sloppy mode uses the enclosing function-level ("var") scope for var-style bindings and a new lexical scope for lexical bindings like let and class. This patch implements that feature by making lexical bindings that are directly within an EVAL_SCOPE be on the local scope rather than the enclosing one. BUG=v8:4288 LOG=Y R=adamk Review URL: https://codereview.chromium.org/1274193004 Cr-Commit-Position: refs/heads/master@{#30120}
-
- 07 Aug, 2015 1 commit
-
-
rossberg authored
Plus some renaming for consistency. R=adamk@chromium.org BUG=v8:811 LOG=N Review URL: https://codereview.chromium.org/1278783002 Cr-Commit-Position: refs/heads/master@{#30064}
-
- 24 Jul, 2015 2 commits
-
-
rossberg authored
R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1256793005 Cr-Commit-Position: refs/heads/master@{#29851}
-
rossberg authored
R=mstarzinger@chromium.org BUG=513474,513475,513611,513612 LOG=N Review URL: https://codereview.chromium.org/1250423002 Cr-Commit-Position: refs/heads/master@{#29845}
-
- 23 Jul, 2015 2 commits
-
-
rossberg authored
While at it, remove the notion of INTERNAL variables. @caitp: Took some parts from your CL, since I was blocked on the temp scope bug. R=mstarzinger@chromium.org BUG=512574 LOG=N Review URL: https://codereview.chromium.org/1250513004 Cr-Commit-Position: refs/heads/master@{#29812}
-
rossberg authored
R=adamk@chromium.org BUG=v8:3330 LOG=N Review URL: https://codereview.chromium.org/1244423003 Cr-Commit-Position: refs/heads/master@{#29803}
-
- 20 Jul, 2015 1 commit
-
-
mstarzinger authored
This adds the implicit function variable for a function literal to the declarations list in scope analysis, instead of specially handling it throughout all back-ends. R=rossberg@chromium.org Review URL: https://codereview.chromium.org/1245603003 Cr-Commit-Position: refs/heads/master@{#29754}
-
- 15 Jul, 2015 1 commit
-
-
rossberg authored
R=adamk@chromium.org, littledan@chromium.org BUG=v8:811 LOG=N Review URL: https://codereview.chromium.org/1240463002 Cr-Commit-Position: refs/heads/master@{#29674}
-
- 06 Jul, 2015 1 commit
-
-
ishell authored
Review URL: https://codereview.chromium.org/1218783005 Cr-Commit-Position: refs/heads/master@{#29498}
-
- 01 Jul, 2015 1 commit
-
-
adamk authored
This was added in https://chromium.googlesource.com/v8/v8/+/4a709dd65, but the only check for it that remained in the final patch is inside a DCHECK. It appears that the approach for checking use of class names in methods evolved quite a bit over the review of the original patch. Review URL: https://codereview.chromium.org/1219993002 Cr-Commit-Position: refs/heads/master@{#29428}
-
- 30 Jun, 2015 1 commit
-
-
yangguo authored
R=ulan@chromium.org Review URL: https://codereview.chromium.org/1214303002 Cr-Commit-Position: refs/heads/master@{#29373}
-
- 29 Jun, 2015 1 commit
-
-
yangguo authored
Only this way we can precisely determine how to allocate let variables inside the scope. R=rossberg@chromium.org BUG=v8:4255 LOG=N Review URL: https://codereview.chromium.org/1216013002 Cr-Commit-Position: refs/heads/master@{#29354}
-
- 12 Jun, 2015 4 commits
-
-
wingo authored
This is a reapplication of https://codereview.chromium.org/1173333004. R=rossberg@chromium.org LOG=N BUG=498811 Review URL: https://codereview.chromium.org/1178903003 Cr-Commit-Position: refs/heads/master@{#28998}
-
wingo authored
Revert of Add script context with context-allocated "const this" (patchset #2 id:20001 of https://codereview.chromium.org/1173333004/) Reason for revert: nosnap failure Original issue's description: > Add script context with context-allocated "const this" > > This is a reapplication of https://codereview.chromium.org/1179893002/. > > R=rossberg@chromium.org,mstarzinger@chromium.org > LOG=N > BUG=498811 > > Committed: https://crrev.com/cfc764f4050edc74aef92daa4c39ccc113893968 > Cr-Commit-Position: refs/heads/master@{#28994} TBR=mstarzinger@chromium.org,rossberg@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=498811 Review URL: https://codereview.chromium.org/1177903004 Cr-Commit-Position: refs/heads/master@{#28996}
-
wingo authored
This is a reapplication of https://codereview.chromium.org/1179893002/. R=rossberg@chromium.org,mstarzinger@chromium.org LOG=N BUG=498811 Review URL: https://codereview.chromium.org/1173333004 Cr-Commit-Position: refs/heads/master@{#28994}
-
machenbach authored
Revert of Add script context with context-allocated "const this" (patchset #7 id:120001 of https://codereview.chromium.org/1179893002/) Reason for revert: [Sheriff] Breaks gc mole: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gcmole/builds/2435 Original issue's description: > Add script context with context-allocated "const this" > > R=rossberg@chromium.org > LOG=N > BUG=498811 > > Committed: https://crrev.com/fa32d461c16a053cc6d48d3fb326016bc2765765 > Cr-Commit-Position: refs/heads/master@{#28988} TBR=rossberg@chromium.org,mstarzinger@chromium.org,wingo@igalia.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=498811 Review URL: https://codereview.chromium.org/1180043004 Cr-Commit-Position: refs/heads/master@{#28992}
-