Named class declarations and class expression have a const binding for
the name that is in TDZ for the extends expression.
BUG=v8:3330
LOG=Y
R=dslomov@chromium.org, adamk
Review URL: https://codereview.chromium.org/722793005
Cr-Commit-Position: refs/heads/master@{#25360}
Why this is better:
1) Not needing an extra template parameter for Checkpoints ctors. This was
especially confusing since the template parameter was named Parser and Parser is
also used as a type name and is also a concrete type. This CL makes it clear
that ParserTraits::Checkpoint is consturcted with ParserBase<ParserTraits> -
that's the only sensemaking type for the ctor param anyway.
2) This CL makes ParserBase define a Checkpoint base class (which knows how
to create and restore a checkpoint with ParserBase) which
PreParserTraits::Checkpoint and ParserTraits::Checkpoint inherit, and not the
other way around.
This is a more intuitive way to implement the "base functionality + extending
it" concept than the previous solution. The previous solution was to allow
Traits to define a Checkpoint class and make ParserBase<Traits>::ParserCheckpoint
(which defines the base functionality) inherit from it.
3) This CL moves the Checkpoint class definitions out of the SomeTraits::Type
struct; SomeTraits::Type is supposed to be a collection of typedefs and not
contain anything else.
Checkpoints were introduced in r22925 ( https://codereview.chromium.org/443903003 ).
BUG=
R=wingo@igalia.com
Review URL: https://codereview.chromium.org/485473004
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23266 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
Notes:
- The regexp in the ParseObjectLiteralComment was wrong, made it less wrong (
it's still wrong since trailing commas are not required / allowed).
- Change in logic: In case we have "get somekeyword() { }", the "somekeyword"
was not logged as a symbol by PreParser and not expected in the preparser data
by Parser. This is unnecessary complication; in other contexts where keywords
are allowed as identifiers, they are logged as symbols (see
ParseIdentifierName).
BUG=v8:3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/173273006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19750 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The Parser never used the symbol stream produced by the PreParser for anything
useful, due to a bug introduced 3.5 years ago by
https://codereview.chromium.org/3356010/diff/7001/src/parser.cc.
The bug is that calling Initialize on symbol_cache_ doesn't change its
length. So the length remains 0, and the "if" in Parser::LookupSymbol is always
true, and Parser::LookupCachedSymbol is never called and symbol_cache_ never
filled.
This bug also masked a bug that the symbol stream produced by PreParser doesn't
match what Parser wants to consume. The repro case is the following:
var myo = {if: 4}; print(myo.if);
PreParser doesn't log a symbol for the first "if", but in the corresponding
place, Parser consumes one symbol from the symbol stream. Since the consumed
symbols were never really used, this mismatch went unnoticed.
This CL also fixes that bug.
BUG=
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/172753002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19505 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
In addition:
- Fix: PreParser used to report an unexpected token one token too late when
ParsePrimaryExpression failed.
- Unified identifier handling (PreParser::GetIdentifier is now like Parser::GetIdentifier).
- Fix: PreParser used to produce "unexpected_token YIELD" errors when Parser
produced "unexpected_token_identifier"; fixed PreParser to match Parser.
BUG=3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/151103006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19082 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This contains the following fixes:
- We had strict_reserved_word and unexpected_strict_reserved, which one to use
was totally mixed in Parser and PreParser. Removed strict_reserved_word.
- When we saw a strict future reserved word when expecting something completely
different (such as "(" in "function foo interface"), Parser reports unexpected
identifier, whereas PreParser used to report unexpected strict reserved
word. Fixed PreParser to report unexpected identifier too.
- Unified parser and preparser error locations when the name of a function is a
strict reserved word. Now both point to the name.
BUG=3126
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/149253010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
VS2013 contains a number of improvements, most notably the addition of all C99 math functions.
I'm a little bit concerned about the change I had to make in cpu-profiler.cc, but I spent quite a bit of time looking at it and was unable to figure out any rational explanation for the warning. It's possible it's spurious. Since it seems like a useful warning in general though, I chose not to disable globally at the gyp level.
I do think someone with expertise here should probably try to determine if this is a legitimate warning.
BUG=288948
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/23449035
Patch from Zach Turner <zturner@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16775 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
