In some places, we pretended that there can be multiple arguments, though in
practice there was only one. In other places (most importantly, PreParser), we
only handled one argument. (This means that we were not able to produce a
multi-argument error inside a lazy function anyway.)
This CL makes it clear that there is ever only one argument.
R=ulan@chromium.org
BUG=
Review URL: https://codereview.chromium.org/273653002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21324 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Adds new Traits::Type::StatementList definitions both for Parser and
PreParser, and the corresponding NewStatementList() factory function.
This is needed to be able to define in ParserBase parsing functions
that return and manipulate lists of statements.
Moving and renaming PreParser::Statement to PreParserStatement is also
needed so its definition is available earlier for PreParserStatementList
to use it.
R=marja@chromium.org
Review URL: https://codereview.chromium.org/252423007
Patch from Adrian Perez de Castro <aperez@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20965 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
State of the art:
- Chromium doesn't do a separate preparsing phase any more.
- We start parsing with Parser, and when it sees a lazy function, it falls back
to PreParser for that function.
- The symbol data should contain symbols which are *outside* lazy functions.
- So Parser should always produce symbol data, and PreParser should never.
- Because it's this simple now, we don't need to keep track of "should
produce symbol data" (i.e., whether we're inside a lazy func or not).
R=ulan@chromium.org
BUG=
Review URL: https://codereview.chromium.org/222123003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20707 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
