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
Esp. get rid of PreCompile in tests, as it's going to be removed.
Notes:
- The new compilation API doesn't have a separate precompilation phase, so there
is no separate way to check for errors except checking the compilation
errors. Removed some tests which don't make sense any more.
- test-api/Regress31661 didn't make sense as a regression test even before the
compilation API changes, because Blink doesn't precompile this short scripts. So
detecting this kind of errors (see crbug.com/31661 for more information) cannot rely
on precompilation errors.
- test-parsing/PreParserStrictOctal has nothing to do with PreParser, and the comment
about "forcing preparsing" was just wrong.
- test-api/PreCompile was supposed to test that "pre-compilation (aka
preparsing) can be called without initializing the whole VM"; that's no longer
true, since there's no separate precompilation step in the new compile
API. There are other tests (test-parsing/DontRegressPreParserDataSizes) which
ensure that we produce cached data.
- Updated tests which test preparsing to use PreParser directly (not via the
preparsing API).
- In the new compilation API, the user doesn't need to deal with ScriptData
ever. It's only used internally, and needed in tests that test internal aspects
(e.g., modify the cached data before passing it back).
- Some tests which used to test preparse + parse now test first time parse +
second time parse, and had to be modified to ensure we don't hit the
compilation cache.
BUG=
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/225743002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20511 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
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
