ReportUnexpectedToken already calls Traits::ReportMessageAt. If we're in Parser,
that already suppresses the syntax error. If we're in PreParser, we don't need
to suppress the syntax error (preparser errors don't go through Isolate, and
having both stack overflow and a syntax error present is handled correctly by
PreParserApi::PreParse).
R=mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/197293003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19851 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Notes:
- We use simple recursion to keep track of how many "new" operators we have seen
and where.
- This makes the self-baked stack class PositionStack in parser.cc unnecessary.
- Now the logic is also unified between Parser and PreParser.
- This is a fixed version of r19386.
R=ulan@chromium.org
BUG=v8:3126
LOG=N
Review URL: https://codereview.chromium.org/168583008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19417 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Notes:
- We use simple recursion to keep track of how many "new" operators we have seen
and where.
- This makes the self-baked stack class PositionStack in parser.cc unnecessary.
- Now the logic is also unified between Parser and PreParser.
- It might have been a copy-paste artifact (ParseLeftHandSideExpression ->
ParseMemberWithNewPrefixesExpression) that the logic was so complicated
before.
R=ulan@chromium.org
BUG=v8:3126
LOG=N
Review URL: https://codereview.chromium.org/166943002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19386 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Notes:
- To be able to move the recursive descent functions to ParserBase one at a
time, we temporarily need routing functions from traits to Parser/PreParser,
since the recursive descent functions form a cyclic structure.
- PreParser used to always allow intrinsic syntax. After this CL, it depends on
allow_natives_syntax() which was already in ParserBase.
- This CL also decouples (Pre)ParserTraits better from (Pre)Parser, passing more
information as parameters, so that the Traits don't need to get it from
(Pre)Parser.
R=ulan@chromium.org
BUG=v8:3126
LOG=N
Review URL: https://codereview.chromium.org/163333003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19374 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Notes:
- This removes Parser::FunctionState and PreParser::FunctionState and adds
ParserBase::FunctionState etc.
- Also the scope stacks and function state stacks are moved to ParserBase.
- PreParser::FunctionState didn't add and subtract
JSFunction::kLiteralsPrefixSize (unlike Parser::FunctionState). Since the
actual value of NextMaterializedLiteralIndex is not used in the Preparser,
this change is valid.
- Traits no longer need functions like is_classic_mode(), since now there is a
unified way of getting the information from the FunctionState / Scope.
R=ulan@chromium.org
BUG=v8:3126
LOG=N
Review URL: https://codereview.chromium.org/135213007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19361 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Notes:
- PreParser::Scope was a weird combination of Parser::FunctionState and
Scope. Split it into two (PreParser::FunctionState and PreParser::Scope). This
is necessary for unifying the Parser and the PreParser.
- Scopes take care of language mode and tracking "with".
- FunctionStates take care of counting material literal indexes, properties
etc. and tracking generators.
- PreParser::Scope::InsideWith was a hack to make a FunctionState-like object
take care of tracking "with". It's now the responsibility fo PreParser::Scope
and Scope.
- PreParser::ScopeType is unnecessarly, there is already a ScopeType enum in
v8globals.h.
- Renamed scope stack variables so that they're consistent in Parser and PreParser.
- Parser::FunctionState and Parser::BlockState had an unnecessary dependency to
the Parser; they only need a couple of things from Parser. Broke the
dependency.
R=ulan@chromium.org
BUG=v8:3126
LOG=N
Review URL: https://codereview.chromium.org/148293011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19319 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
(Second try, with fixes. First try: https://codereview.chromium.org/149913006/ )
The long-term goal is to move all recursive descent functions from Parser and
PreParser into ParserBase, but first they need to be unified.
Notes:
- The functions moved in this CL: ParseIdentifier, ParseIdentifierName,
ParseIdentifierNameOrGetOrSet, ParseIdentifierOrStrictReservedWord.
- IOW, this CL removes Parser::ParseIdentifier and PreParser::ParseIdentifier
and adds ParserBase::ParseIdentifier, etc.
- Error reporting used to require virtual funcs; now error reporting is moved to
the Traits too, and ParserBase no longer needs to be virtual.
- I had to move PreParser::Identifier out of the PreParser class, because
otherwise PreParserTraits cannot use it in a typedef.
BUG=v8:3126
LOG=N
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/158913003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19265 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The long-term goal is to move all recursive descent functions from Parser and
PreParser into ParserBase, but first they need to be unified.
Notes:
- The functions moved in this CL: ParseIdentifier, ParseIdentifierName,
ParseIdentifierNameOrGetOrSet, ParseIdentifierOrStrictReservedWord.
- IOW, this CL removes Parser::ParseIdentifier and PreParser::ParseIdentifier
and adds ParserBase::ParseIdentifier, etc.
- Error reporting used to require virtual funcs; now error reporting is moved to
the Traits too, and ParserBase no longer needs to be virtual.
- I had to move PreParser::Identifier out of the PreParser class, because
otherwise PreParserTraits cannot use it in a typedef.
BUG=v8:3126
LOG=N
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/149913006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19230 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Still relevant parts of the original commit message:
Unify paren handling in Parser and PreParser.
It is only needed in (Pre)Parser::ParseExpressionOrLabelledStatement for not
recognizing parenthesized identifiers as labels and in
(Pre)Parser::ParseSourceElements for not recognizing a parenthesized string as
directive prologue.
Parser Expressions don't keep track of whether they're parenthesized, so
PreParser Expressions shouldn't either.
BUG=3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/148323011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19153 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
It is only needed in (Pre)Parser::ParseExpressionOrLabelledStatement for not
recognizing parenthesized identifiers as labels and in
(Pre)Parser::ParseSourceElements for not recognizing a parenthesized string as
directive prologue.
Parser Expressions don't keep track of whether they're parenthesized, so
PreParser Expressions shouldn't either.
In addition, add helper funcs for checking if an Expression is identifier or a
given identifier. (PreParser Expressions can do this.)
BUG=3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/150103004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19140 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We used to have error messages which provide context, like "Variable name may
not be eval or arguments in strict mode", but for other illegal words we only
have non-context specific error messages like "Unexpected reserved word".
Providing the context makes the code unnecessarily complex, since every
individual place must remember to check for eval or arguments. This CL produces
a unified error message ("Unexpected eval or arguments in strict mode"), and puts
the error reporting to (Pre)Parser::ParseIdentifier.
Notes:
- The module feature is so experimental, that I decided to not allow "eval" or
"arguments" as module-related identifiers in the strict mode (even though this
check wasn't there before).
- Unfortunately, there were some inconsistencies, since it was the
responsibility of the caller of ParseIdentifier to check "eval" and "arguments"
and some places didn't have the check for no good reason. This CL is supposed to
keep backward compatibility and *not* introduce any new errors.
- ECMA allows "eval" and "arguments" as labels even in strict mode. (Syntax:
"LabelledStatement: Identifier : Statement", and no strict mode restrictions on
Identifier are listed.)
- Tests which compare error message strings will fail, and need to be updated.
BUG=3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/152813005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19112 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch refactors the parser and preparser interface to be more
readable and type-safe. It has no behavior changes.
Previously, parsers and preparsers were configured via bitfield called
parser_flags in the Parser constructor, and flags in
PreParser::PreParseProgram, ParserApi::Parse, and ParserApi::PreParse.
This was error-prone in practice: six call sites passed incorrectly
typed values to this interface (a boolean FLAG value, a boolean false
and a boolean true value). None of these errors were caught by the
compiler because it's just an "int".
The parser flags interface was also awkward because it encoded a
language mode, but the language mode was only used to turn on harmony
scoping or not -- it wasn't used to actually set the parser's language
mode.
Fundamentally these errors came in because of the desire for a
procedural parser interface, in ParserApi. Because we need to be able
to configure the parser in various ways, the flags argument got added;
but no one understood how to use the flags properly. Also they were
only used by constructors: callers packed bits, and the constructors
unpacked them into booleans on the parser or preparser.
The solution is to allow parser construction, configuration, and
invocation to be separated. This patch does that.
It passes the existing tests.
BUG=
Review URL: https://codereview.chromium.org/13450007
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14151 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
The old HashMap class had an explicit member to determine the allocation
policy. The template version matches the approach used already for
lists.
Cleanup some include dependencies and unnecessary forward declarations.
Cleanup some dead code from isolate.h and replace some HEAP macros
with GetHeap().
Review URL: https://chromiumcodereview.appspot.com/9372106
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10806 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL introduces a third mode next to the non-strict
(henceforth called 'classic mode') and 'strict mode'
which is called 'extended mode' as in the current
ES.next specification drafts. The extended mode is based on
the 'strict mode' and adds new functionality to it. This
means that most of the semantics of these two modes
coincide.
The 'extended mode' is entered instead of the 'strict mode'
during parsing when using the 'strict mode' directive
"use strict" and when the the harmony-scoping flag is
active. This should be changed once it is fully specified how the 'extended mode' is entered.
This change introduces a new 3 valued enum LanguageMode
(see globals.h) corresponding to the modes which is mostly
used by the frontend code. This includes the following
components:
* (Pre)Parser
* Compiler
* SharedFunctionInfo, Scope and ScopeInfo
* runtime functions: StoreContextSlot,
ResolvePossiblyDirectEval, InitializeVarGlobal,
DeclareGlobals
The old enum StrictModeFlag is still used in the backend
when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes:
* SetProperty runtime function, Delete builtin
* StoreIC and KeyedStoreIC
* StubCache
Review URL: http://codereview.chromium.org/8417035
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previously the preparser always accepted natives syntax and let the
real parser throw the syntax error. In ES5, it should be an early error,
so the preparser must catch the error.
The perparser library does not expose parsing for natives syntax, it's
only used internally.
Review URL: http://codereview.chromium.org/8306024
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9660 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Duplicate identifier detection must be an early syntax error in strict code,
so errors in otherwise lazily compiled functions must be caught in the
preparser.
Originally introduced in r8541 and reverted in r8542.
Now really compiles on Windows.
Review URL: http://codereview.chromium.org/7782023
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9172 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a fix and reapply of r8516 with some comments addressed and more
tests added.
The difference from r8516 is that canonicalization of number literals is
no performed using the same methods as in v8, to avoid false positives/negatives
when detecting duplicates.
Review URL: http://codereview.chromium.org/7193045
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8541 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We now only recognize "native function" when it occurs in extension scripts
(parsing with a non-NULL extension), and only if there is no line-terminator
between "native" and "function" (so that it would otherwise be a Syntax Error).
Preparsing never recognizes native functions, which is acceptable since we
never preparse extension scripts (because we don't allow lazy functions
anyway).
BUG=v8:1097
Review URL: http://codereview.chromium.org/7206020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8326 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Mainly, there were errors concerning blank lines before and after class access
control sections [whitespace/blank_line].
BEFORE an access control section (e.g. public:, private:) there should be a
blank line (except for the section right after the class declaration).
AFTER an access control section there should be no blank line.
TBR=ager@chromium.org
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8193 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
