- 09 Nov, 2015 1 commit
-
-
adamk authored
R=rossberg@chromium.org BUG=chromium:552302 LOG=n Review URL: https://codereview.chromium.org/1425723004 Cr-Commit-Position: refs/heads/master@{#31890}
-
- 05 Nov, 2015 2 commits
-
-
adamk authored
The previous code had a mix of breaks, early returns, and switch/case/if with fallthrough. Now the pattern is to either return for known errors or break to the bottom of the switch for unhandled tokens. Also cleaned up random other stuff in the function: removed unnecessary local vars, shortened position-fetching calls. Review URL: https://codereview.chromium.org/1412313009 Cr-Commit-Position: refs/heads/master@{#31843}
-
caitpotter88 authored
Fix an earlier regression which forbid non-VariableProxy LHS from being used in for-of loops. Like for-in loops, the spec allows any LHS to be used, with the sole exception that ObjectLiterals and ArrayLiterals must be valid AssignmentPatterns. Also fixes a bug in TurboFan which resulted in incorrectly replacing a variable load with a constant value in some instances, due to the AstLoopAssignmentAnalyzer failing to record the assignment to ForOfStatement's value. BUG=v8:4418, v8:2720 LOG=N R=wingo@igalia.com, littledan@chromium.org, adamk@chromium.org, bmeurer@chromium.org Review URL: https://codereview.chromium.org/1411873004 Cr-Commit-Position: refs/heads/master@{#31816}
-
- 04 Nov, 2015 1 commit
-
-
caitpotter88 authored
Emit an early error when BindingPatterns are used in a VariableDeclaration or LexicalBinding without an Initializer. BUG=v8:4532 LOG=N R=adamk@chromium.org, rossberg@chromium.org, wingo@igalia.com Review URL: https://codereview.chromium.org/1416753009 Cr-Commit-Position: refs/heads/master@{#31802}
-
- 29 Oct, 2015 1 commit
-
-
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}
-
- 28 Oct, 2015 2 commits
-
-
adamk authored
It was shipped in M46 without incident. Review URL: https://codereview.chromium.org/1411723007 Cr-Commit-Position: refs/heads/master@{#31636}
-
adamk authored
These features shipped in M46 without issue. Review URL: https://codereview.chromium.org/1429653006 Cr-Commit-Position: refs/heads/master@{#31635}
-
- 21 Oct, 2015 1 commit
-
-
caitpotter88 authored
Adds an implementation of "do expression" parsing (https://webcache.googleusercontent.com/search?q=cache:MIGALjqPDNgJ:wiki.ecmascript.org/doku.php%3Fid%3Dstrawman:do_expressions+&cd=1&hl=en&ct=clnk&gl=us). This feature provides a way to evaluate a block of statements within an expression context, producing the resulting completion value. This is very helpful for implementing certain language features via desugaring. BUG=v8:4488 LOG=N R=adamk@chromium.org, bmeurer@chromium.org, rossberg@chromium.org, wingo@igalia.com Review URL: https://codereview.chromium.org/1399893002 Cr-Commit-Position: refs/heads/master@{#31428}
-
- 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
-
-
littledan authored
An identifier may be parsed in an object literal like {let}, but this was previously left out of lexical name checking. This patch adds that check to prohibit code like let {let} = {let: 1} BUG=v8:4403 LOG=N R=adamk Review URL: https://codereview.chromium.org/1401253003 Cr-Commit-Position: refs/heads/master@{#31278}
-
- 14 Oct, 2015 1 commit
-
-
caitpotter88 authored
Fixes corner case where arrow function ConciseBody expression does not accept 'in' in productions. BUG=v8:4472 LOG=N R=wingo@igalia.com, adamk@chromium.org, rossberg@chromium.org Review URL: https://codereview.chromium.org/1407633002 Cr-Commit-Position: refs/heads/master@{#31271}
-
- 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}
-
- 05 Oct, 2015 1 commit
-
-
littledan authored
This patch prohibits lexical bindings from being called 'let', even in sloppy mode, following the ES2015 specification. The change affects multiple cases of lexical bindings, including simple let/const declarations and both kinds of for loops. var and legacy const bindings still permit the name to be let, including in destructuring cases. Tests are added to verify, though some cases are commented out since they led to (pre-existing) crashes. BUG=v8:4403 R=adamk LOG=Y Review URL: https://codereview.chromium.org/1371263003 Cr-Commit-Position: refs/heads/master@{#31115}
-
- 30 Sep, 2015 2 commits
-
-
adamk authored
Arrow functions have been enabled by default since the 4.5 branch. Review URL: https://codereview.chromium.org/1373633002 Cr-Commit-Position: refs/heads/master@{#31031}
-
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}
-
- 28 Sep, 2015 1 commit
-
-
neis authored
R=rossberg BUG= Review URL: https://codereview.chromium.org/1371963002 Cr-Commit-Position: refs/heads/master@{#30970}
-
- 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}
-
- 16 Sep, 2015 2 commits
-
-
caitpotter88 authored
Some cleanup of ParsePropertyDefinition --- Replaces certain hacks with more structured, clean code, and adds additional comments to aid in comprehension of this tricky area of the ambiguous recursive descent parser. BUG=v8:3583 LOG=N R=adamk, aperez, wingo, rossberg Review URL: https://codereview.chromium.org/1348773004 Cr-Commit-Position: refs/heads/master@{#30775}
-
caitpotter88 authored
Add support for `get` and `set` as shorthand properties. Also supports them for CoverInitializedName in BindingPatterns and (once implemented) AssignmentPatterns. BUG=v8:4412, v8:3584 LOG=N R=adamk, aperez, wingo, rossberg Review URL: https://codereview.chromium.org/1328083002 Cr-Commit-Position: refs/heads/master@{#30769}
-
- 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}
-
- 28 Aug, 2015 2 commits
-
-
littledan authored
This patch makes 'let' a contextual keyword in both strict and sloppy mode. It behaves as a keyword when used at the beginning of a StatementListItem or lexical declaration at the beginning of a for statement, if it is followed by an identifier, [ or {. Implementing this change requires an extra token look-ahead by the parser which is only invoked in certain cases (so as to avoid parsing RegExps as ECMAScript tokens). This might result in a slowdown of the scanner, but performance testing of this patch hasn't yet found much of a regression. BUG=v8:3305 LOG=Y R=adamk,vogelheim Review URL: https://codereview.chromium.org/1315673009 Cr-Commit-Position: refs/heads/master@{#30451}
-
wingo authored
R=adamk@chromium.org LOG=N BUG=v8:4397 Review URL: https://codereview.chromium.org/1320673007 Cr-Commit-Position: refs/heads/master@{#30431}
-
- 26 Aug, 2015 3 commits
-
-
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}
-
wingo authored
Thanks to André Bargull for the report. BUG=v8:4212 LOG=N R=rossberg@chromium.org Review URL: https://codereview.chromium.org/1309523005 Cr-Commit-Position: refs/heads/master@{#30381}
-
wingo authored
BUG=v8:4211 LOG=Y R=rossberg@chromium.org Review URL: https://codereview.chromium.org/1315823002 Cr-Commit-Position: refs/heads/master@{#30373}
-
- 24 Aug, 2015 1 commit
-
-
yangguo authored
Revert of Parse arrow functions at proper precedence level (patchset #2 id:60001 of https://codereview.chromium.org/1286383005/ ) Reason for revert: Breaks layout test. Please change test expectation on blink first. --- /mnt/data/b/build/slave/V8-Blink_Linux_64/build/layout-test-results/inspector/sources/debugger-pause/debugger-pause-in-internal-expected.txt +++ /mnt/data/b/build/slave/V8-Blink_Linux_64/build/layout-test-results/inspector/sources/debugger-pause/debugger-pause-in-internal-actual.txt @@ -1,4 +1,4 @@ -CONSOLE ERROR: line 9: Uncaught SyntaxError: Expected () to start arrow function, but got '}' instead of '=>' +CONSOLE ERROR: line 9: Uncaught SyntaxError: Unexpected token ) Tests that pause on exception in internal script does not crash. Script source was shown. Original issue's description: > Parse arrow functions at proper precedence level > > BUG=v8:4211 > LOG=Y > R=rossberg@chromium.org > > Committed: https://crrev.com/9271b0ccf9ddb217deb1f0b9ef9b59b64dc40214 > Cr-Commit-Position: refs/heads/master@{#30298} TBR=rossberg@chromium.org,mstarzinger@chromium.org,fennyfanny655@gmail.com,machenbach@chromium.org,wingo@igalia.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4211 Review URL: https://codereview.chromium.org/1315503002 Cr-Commit-Position: refs/heads/master@{#30318}
-
- 21 Aug, 2015 2 commits
-
-
wingo authored
BUG=v8:4211 LOG=Y R=rossberg@chromium.org Review URL: https://codereview.chromium.org/1286383005 Cr-Commit-Position: refs/heads/master@{#30298}
-
wingo authored
Not all parenthesized AssignmentExpressions whose components are valid binding patterns are valid arrow function formal parameters. In particular (a,b,c)() is not valid, and in general the existing code wasn't catching the tail productions of ConditionalExpression, BinaryExpression, PostfixExpression, LeftHandSideExpression, and MemberExpression. Thanks to Adrian Perez for the test case. BUG=v8:4211 LOG=Y R=rossberg@chromium.org Review URL: https://codereview.chromium.org/1306583002 Cr-Commit-Position: refs/heads/master@{#30286}
-
- 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}
-
- 15 Aug, 2015 1 commit
-
-
caitpotter88 authored
Second item in section 13.7.5.1 states that the error should be a SyntaxError, when previously CheckAndRewriteReferenceExpression would always emit a ReferenceError. BUG=v8:4373 R=adamk, rossberg LOG=N CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1292393002 Cr-Commit-Position: refs/heads/master@{#30184}
-
- 13 Aug, 2015 2 commits
-
-
rossberg authored
R=adamk@chromium.org BUG= Review URL: https://codereview.chromium.org/1286133003 Cr-Commit-Position: refs/heads/master@{#30167}
-
adamk authored
In doing so, fix calls CheckAndRewriteReferenceExpression to take proper start and end positions (instead of just pointing at the first token in the LHS expression). BUG=v8:4370 LOG=n Review URL: https://codereview.chromium.org/1290013002 Cr-Commit-Position: refs/heads/master@{#30166}
-
- 12 Aug, 2015 1 commit
-
-
littledan authored
In an initial attempt to implement sloppy mode lexical bindings, functions were made lexically scoped in sloppy mode. However, the ES2015 spec says that they need an additional hoisted var binding, and further, it's not clear when we'll implement that behavior or whether it's web-compatible. This patch splits off function block scoping into a new, separate flag called --harmony_sloppy_function. This change will enable the possibility of testing and shipping this feature separately from other block scoping-related features which don't have the same risks. BUG=v8:4285 R=adamk LOG=N Review URL: https://codereview.chromium.org/1282093002 Cr-Commit-Position: refs/heads/master@{#30122}
-
- 11 Aug, 2015 1 commit
-
-
mstarzinger authored
This is the first step of turning the v8.h file into a normal header instead of an include-the-world header. The new rule is that no other header files are allowed to include v8.h, which is enforced by DEPS. Also the number of includes inside the v8.h file has been drastically reduced. Basically the last missing piece is the inclusion of the big objects-inl.h file. This in turn makes many headers follow the IWYU principle. R=bmeurer@chromium.org,hpayer@chromium.org,titzer@chromium.org Review URL: https://codereview.chromium.org/1282503003 Cr-Commit-Position: refs/heads/master@{#30102}
-
- 07 Aug, 2015 1 commit
-
-
rossberg authored
Fixes the use of eval calls in strict parameter lists in particular. R=adamk@chromium.org BUG=v8:811 LOG=N Review URL: https://codereview.chromium.org/1276273002 Cr-Commit-Position: refs/heads/master@{#30074}
-
- 05 Aug, 2015 2 commits
-
-
adamk authored
It was shipped in V8 4.4. Review URL: https://codereview.chromium.org/1273543002 Cr-Commit-Position: refs/heads/master@{#30038}
-
adamk authored
It was shipped in V8 4.4. Review URL: https://codereview.chromium.org/1271073002 Cr-Commit-Position: refs/heads/master@{#30035}
-