- 16 May, 2016 1 commit
-
-
caitpotter88 authored
BUG=v8:4483 LOG=Y R=littledan@chromium.org, adamk@chromium.org Review-Url: https://codereview.chromium.org/1841543003 Cr-Commit-Position: refs/heads/master@{#36261}
-
- 29 Apr, 2016 1 commit
-
-
mike authored
Restrict the use of the `await` token as an identifier when parsing source text as module code. From http://www.ecma-international.org/ecma-262/6.0/#sec-future-reserved-words: > 11.6.2.2 Future Reserved Words > > The following tokens are reserved for used as keywords in future > language extensions. > > Syntax > > FutureReservedWord :: > enum > await > > await is only treated as a FutureReservedWord when Module is the goal > symbol of the syntactic grammar. BUG=v8:4767 LOG=N R=adamk@chromium.org Review-Url: https://codereview.chromium.org/1723313002 Cr-Commit-Position: refs/heads/master@{#35914}
-
- 18 Mar, 2016 1 commit
-
-
caitpotter88 authored
Implements Stage 4 proposal from http://rwaldron.github.io/exponentiation-operator/, without adding any knowledge of the feature to compiler backends. BUG=v8:3915 LOG=Y R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org Review URL: https://codereview.chromium.org/1678303002 Cr-Commit-Position: refs/heads/master@{#34890}
-
- 15 Jan, 2016 1 commit
-
-
mstarzinger authored
This refactoring removes the dependency on the Token class from the assembler.h header file, the utility function in question has nothing to do with assembling in the first place. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1594443003 Cr-Commit-Position: refs/heads/master@{#33330}
-
- 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}
-
- 17 Nov, 2015 1 commit
-
-
caitpotter88 authored
Per http://tc39.github.io/ecma262/#sec-identifiers-static-semantics-early-errors (13.2.2), make it a SyntaxError if an Identifier has the same StringValue as a ReservedWord. BUG=v8:2222, v8:1972 LOG=N R=adamk@chromium.org, rossberg@chromium.org, wingo@chromium.org Review URL: https://codereview.chromium.org/1429983002 Cr-Commit-Position: refs/heads/master@{#32052}
-
- 16 Nov, 2015 1 commit
-
-
adamk authored
All uses of Token::INIT also have access to the relevant VariableMode, so there's no reason to have more than one token representing an initializing assignment. Review URL: https://codereview.chromium.org/1431873006 Cr-Commit-Position: refs/heads/master@{#32016}
-
- 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}
-
- 28 Aug, 2015 1 commit
-
-
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}
-
- 03 Mar, 2015 1 commit
-
-
verwaest authored
BUG= Review URL: https://codereview.chromium.org/974783003 Cr-Commit-Position: refs/heads/master@{#26956}
-
- 04 Feb, 2015 1 commit
-
-
marja authored
This enables adding more language modes in the future. For maximum flexibility, LanguageMode is a bitmask, so we're not restricted to use a sequence of language modes which are progressively stricter, but we can express the language mode as combination of features. For now, LanguageMode can only be "sloppy" or "strict", and there are STATIC_ASSERTS in places which need to change when more modes are added. LanguageMode is a bit like the old LanguageMode when "extended" mode was still around (see https://codereview.chromium.org/8417035 and https://codereview.chromium.org/181543002 ) except that it's transmitted through all the layers (there's no StrictModeFlag). BUG= Review URL: https://codereview.chromium.org/894683003 Cr-Commit-Position: refs/heads/master@{#26419}
-
- 30 Jan, 2015 1 commit
-
-
caitpotter88 authored
BUG=v8:2159 LOG=N R=marja@chromium.org, arv@chromium.org Review URL: https://codereview.chromium.org/885243002 Cr-Commit-Position: refs/heads/master@{#26362}
-
- 14 Nov, 2014 1 commit
-
-
caitpotter88 authored
BUG=v8:3230 Review URL: https://codereview.chromium.org/663683006 Cr-Commit-Position: refs/heads/master@{#25362}
-
- 29 Sep, 2014 1 commit
-
-
arv@chromium.org authored
This allows the following: var x = 1; var o = {x}; This is under the --harmony-object-literals flag. BUG=v8:3584 LOG=y R=marja@chromium.org, rossberg@chromium.org Review URL: https://codereview.chromium.org/584993002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24291 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 16 Sep, 2014 1 commit
-
-
arv@chromium.org authored
This implements parsing for ClassExpression and ClassDeclaration. The runtime is not yet implemented and the value is currently hard coded to undefined. BUG=v8:3330 LOG=Y R=dslomov@chromium.org, marja@chromium.org, rossberg@chromium.org Review URL: https://codereview.chromium.org/561913002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23988 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Aug, 2014 1 commit
-
-
dslomov@chromium.org authored
BUG=v8:3330 LOG=N R=arv@chromium.org, marja@chromium.org Review URL: https://codereview.chromium.org/480543002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23157 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Aug, 2014 1 commit
-
-
bmeurer@chromium.org authored
This way we don't clash with the ASSERT* macros defined by GoogleTest, and we are one step closer to being able to replace our homegrown base/ with base/ from Chrome. R=jochen@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/430503007 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22812 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 14 Jul, 2014 1 commit
-
-
marja@chromium.org authored
Arrow functions are parsed from ParseAssignmentExpression(). Handling the parameter list is done by letting ParseConditionalExpression() parse a comma separated list of identifiers, and it returns a tree of BinaryOperation nodes with VariableProxy leaves, or a single VariableProxy if there is only one parameter. When the arrow token "=>" is found, the VariableProxy nodes are passed to ParseArrowFunctionLiteral(), which will then skip parsing the paramaeter list. This avoids having to rewind when the arrow is found and restart parsing the parameter list. Note that the empty parameter list "()" is handled directly in ParsePrimaryExpression(): after is has consumed the opening parenthesis, if a closing parenthesis follows, then the only valid input is an arrow function. In this case, ParsePrimaryExpression() directly calls ParseArrowFunctionLiteral(), to avoid needing to return a sentinel value to signal the empty parameter list. Because it will consume the body of the arrow function, ParseAssignmentExpression() will not see the arrow "=>" token as next, and return the already-parser expression. The implementation is done in ParserBase, so it was needed to do some additions to ParserBase, ParserTraits and PreParserTraits. Some of the glue code can be removed later on when more more functionality is moved to ParserBase. Additionally, this adds a runtime flag "harmony_arrow_functions" (disabled by default); enabling "harmony" will enable it as well. BUG=v8:2700 LOG=N R=marja@chromium.org Review URL: https://codereview.chromium.org/383983002 Patch from Adrián Pérez de Castro <aperez@igalia.com>. git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22366 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Jul, 2014 1 commit
-
-
marja@chromium.org authored
This reverts revision 22320. Reason: ASAN still detects leaks! Conflicts: src/preparser.h TBR=aperez@igalia.com,marja@chromium.org BUG= Review URL: https://codereview.chromium.org/389503002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22337 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 Jul, 2014 1 commit
-
-
marja@chromium.org authored
Arrow functions are parsed from ParseAssignmentExpression(). Handling the parameter list is done by letting ParseConditionalExpression() parse a comma separated list of identifiers, and it returns a tree of BinaryOperation nodes with VariableProxy leaves, or a single VariableProxy if there is only one parameter. When the arrow token "=>" is found, the VariableProxy nodes are passed to ParseArrowFunctionLiteral(), which will then skip parsing the paramaeter list. This avoids having to rewind when the arrow is found and restart parsing the parameter list. Note that the empty parameter list "()" is handled directly in ParsePrimaryExpression(): after is has consumed the opening parenthesis, if a closing parenthesis follows, then the only valid input is an arrow function. In this case, ParsePrimaryExpression() directly calls ParseArrowFunctionLiteral(), to avoid needing to return a sentinel value to signal the empty parameter list. Because it will consume the body of the arrow function, ParseAssignmentExpression() will not see the arrow "=>" token as next, and return the already-parser expression. The implementation is done in ParserBase, so it was needed to do some additions to ParserBase, ParserTraits and PreParserTraits. Some of the glue code can be removed later on when more more functionality is moved to ParserBase. Additionally, this adds a runtime flag "harmony_arrow_functions" (disabled by default); enabling "harmony" will enable it as well. BUG=v8:2700 LOG=N R=marja@chromium.org Review URL: https://codereview.chromium.org/385553003 Patch from Adrián Pérez de Castro <aperez@igalia.com>. git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22320 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Jul, 2014 2 commits
-
-
marja@chromium.org authored
This reverts r22265. Reason: ASAN tests fail. BUG= TBR=marja@chromium.org,aperez@igalia.com Review URL: https://codereview.chromium.org/372983003 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22266 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
Arrow functions are parsed from ParseAssignmentExpression. Handling the parameter list is done by letting ParseConditionalExpression() parse a comma-separated list of identifiers, and it returns a tree of BinaryOperation nodes with VariableProxy leaves, or a single VariableProxy if there is only one parameter. When the arrow token "=>" is found, the VariableProxy nodes are passed to ParseFunctionLiteral(), which will then skip parsing the paramaeter list. This avoids having to rewind when the arrow is found and restart parsing the parameter list. Note that ParseExpression() expects parenthesized expressions to not be empty, so checking for a closing parenthesis is added in handling the empty parameter list "()" will accept a right-paren and return an empty expression, which means that the parameter list is empty. Additionally, this adds the following machinery: - A runtime flag "harmony_arrow_functions" (disabled by default). Enabling "harmony" will enable it as well. - An IsArrow bit in SharedFunctionInfo, and accessors for it. - An IsArrow bit in FunctionLiteral, accessorts for it, and a constructor parameter to set its value. - In ParserBase: allow_arrow_functions() and set_allow_arrow_functions() - A V8 native %FunctionIsArrow(), which is used to skip adding the "function " prefix when getting the source code for an arrow function. R=marja@chromium.org Review URL: https://codereview.chromium.org/160073006 Patch from Adrián Pérez de Castro <aperez@igalia.com>. git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22265 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Jun, 2014 1 commit
-
-
jochen@chromium.org authored
Also split v8-core independent methods from checks.h to base/logging.h and merge v8checks with the rest of checks. The CPU::FlushICache method is moved to CpuFeatures::FlushICache RoundUp and related methods are moved to base/macros.h Remove all layering violations from src/libplatform BUG=none R=jkummerow@chromium.org LOG=n Review URL: https://codereview.chromium.org/358363002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22092 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jun, 2014 1 commit
-
-
jochen@chromium.org authored
- this avoids using relative include paths which are forbidden by the style guide - makes the code more readable since it's clear which header is meant - allows for starting to use checkdeps BUG=none R=jkummerow@chromium.org, danno@chromium.org LOG=n Review URL: https://codereview.chromium.org/304153016 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Apr, 2014 1 commit
-
-
bmeurer@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/259183002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Mar, 2014 1 commit
-
-
rossberg@chromium.org authored
- Merge LanguageMode and StrictModeFlag enums - Make harmony-scoping depend only on strict mode - Free some bits on the way - Plus additional clean-up and renaming R=ulan@chromium.org BUG= Review URL: https://codereview.chromium.org/181543002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19800 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 Dec, 2013 1 commit
-
-
bmeurer@chromium.org authored
Previously BinaryOpIC and BinaryOpStub were pretty much interdependent. However, in order to use allocation sites for string adds on-demand, we need to be able to use different stubs (with a different number of register parameters, via trampolines) depending on the BinaryOpIC state. R=hpayer@chromium.org, mvstanton@chromium.org Review URL: https://codereview.chromium.org/97543002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18191 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Jul, 2013 1 commit
-
-
mmassi@chromium.org authored
R=titzer@chromium.org Review URL: https://codereview.chromium.org/17568015 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15866 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 Apr, 2013 1 commit
-
-
mstarzinger@chromium.org authored
This patchset begins by adding support for "yield", which is unlike other tokens in JS. In a generator, whether strict or classic, it is a syntactic keyword. In classic mode it is an identifier. In strict mode it is reserved. This patch adds YIELD as a token to the scanner, and adapts the preparser and parser appropriately. It also parses "function*", indicating that a function is actually a generator, for both eagerly and lazily parsed functions. Currently "yield" just compiles as "return". BUG=v8:2355 TEST=mjsunit/harmony/generators-parsing Review URL: https://codereview.chromium.org/12646003 Patch from Andy Wingo <wingo@igalia.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14116 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 13 Feb, 2013 1 commit
-
-
jkummerow@chromium.org authored
BUG=v8:2537 Review URL: https://codereview.chromium.org/12217136 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13658 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Nov, 2012 1 commit
-
-
ulan@chromium.org authored
of the form ((x >>> i) | (x << (32 - i))). This CL is based on https://chromiumcodereview.appspot.com/10984057/ by Jay Conrod <dconrod@codeaurora.org>. R=danno@chromium.org,mstarzinger@chromium.org,dconrod@codeaurora.org Review URL: https://chromiumcodereview.appspot.com/11033005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12855 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 Mar, 2012 1 commit
-
-
danno@chromium.org authored
Allow Crankshaft to inline ordered relational comparisons (<, >, <=, >=) that have undefined arguments in addition to double value arguments (rather than calling the generic Compare stub). R=fschneider@chromium.org TEST=test/mjsunit/comparison-ops-and-undefined.js Review URL: https://chromiumcodereview.appspot.com/9584006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10905 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Feb, 2012 1 commit
-
-
rossberg@chromium.org authored
Baseline: http://codereview.chromium.org/9401008/ R=lrn@chromium.org,mstarzinger@chromium.org BUG=v8:1957 TEST=mjsunit/harmony/module-parsing Review URL: https://chromiumcodereview.appspot.com/9422001 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10832 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Feb, 2012 1 commit
-
-
rossberg@chromium.org authored
R=mstarzinger@chromium.org BUG= TEST= Review URL: https://chromiumcodereview.appspot.com/9352013 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10638 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Oct, 2011 1 commit
-
-
keuchel@chromium.org authored
This implements block scoped 'const' declared variables in harmony mode. They have a temporal dead zone semantics similar to 'let' bindings, i.e. accessing uninitialized 'const' bindings in throws a ReferenceError. As for 'let' bindings, the semantics of 'const' bindings in global scope is not correctly implemented yet. Furthermore assignments to 'const's are silently ignored. Another CL will introduce treatment of those assignments as early errors. Review URL: http://codereview.chromium.org/7992005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9764 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 19 Sep, 2011 1 commit
-
-
svenpanne@chromium.org authored
Although this patch is not small, most parts of it are rather mechanical: * First of all, the concept of a 'nil-like' value is introduced, which can be null or undefined. They are treated symmetrically regarding comparisons, so it makes sense to handle them in a uniform manner. It is a mystery why JavaScript defines two of those beasts, when even *one* is a design wart... * Extended and renamed a few things which now handle undefined in addition to null. * Made the parts of the full code generator and the hydrogen generation which deal with comparisons a bit more similar regarding their handling of special cases. * Refactored the syntactical detection of special cases for comparisons, hopefully making them a bit more readable and less copy-n-paste-oriented. Things like this should really be a one-liner in any sane programming language... :-P * Cut down the length of the argument lists of a few functions to something less insane, making them more easily understandable locally. This involves minor code duplication, but this was a good tradeoff and can be remedied later if necessary. * Replaced some boolean arguments with more readable enums. * Fixed a TODO: Values which are definitely a Smi or unboxed can never be equal to null or undefined. Review URL: http://codereview.chromium.org/7918012 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9323 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Aug, 2011 1 commit
-
-
keuchel@chromium.org authored
BUG= TEST=mjsunit/harmony/block-let-semantics.js Review URL: http://codereview.chromium.org/7671042 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9070 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 16 Aug, 2011 1 commit
-
-
keuchel@chromium.org authored
Implementation of the harmony block scoped let bindings as proposed here: http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings Changes to the syntax are explained there. They are active under the harmony_block_scoping_ flag in the parser. Review URL: http://codereview.chromium.org/7616009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8944 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Aug, 2011 1 commit
-
-
vitalyr@chromium.org authored
Replaced the keyword matching state machine with a switch on the first char followed up by inlined char comparisons. R=lrn@chromium.org TEST=cctest/test-parsing/ScanKeywords Review URL: http://codereview.chromium.org/7558017 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8866 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Jun, 2011 1 commit
-
-
keuchel@chromium.org authored
BUG=86442 TEST=mjsunit/keywords-and-reserved_words.js Review URL: http://codereview.chromium.org/7207007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8421 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-