Preparsing is always maximally lazy (every function that can be lazy is preparsed
lazily), but Parser has more complicated laziness logic.
If we're going to parse eagerly, and we have preparse data from lazy preparsing,
we're gonna have a bad time. The symbol stream won't contain symbols inside lazy
functions, and when the Parser parses them eagerly, it will consume symbols from
the symbol stream, and everything will go wrong.
This bug was hidden because the symbol cache was not used for real (see
https://codereview.chromium.org/172753002/ ).
R=ulan@chromium.org
BUG=346207
LOG=Y
Review URL: https://codereview.chromium.org/177973002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19532 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
Refresh the implementation of Symbols to catch up with what the
specification now mandates:
* The global Symbol() function manufactures new Symbol values,
optionally with a string description attached.
* Invoking Symbol() as a constructor will now throw.
* ToString() over Symbol values still throws, and
Object.prototype.toString() stringifies like before.
* A Symbol value is wrapped in a Symbol object either implicitly if
it is the receiver, or explicitly done via Object(symbolValue) or
(new Object(symbolValue).)
* The Symbol.prototype.toString() method no longer throws on Symbol
wrapper objects (nor Symbol values.) Ditto for Symbol.prototype.valueOf().
* Symbol.prototype.toString() stringifies as "Symbol("<description>"),
valueOf() returns the wrapper's Symbol value.
* ToPrimitive() over Symbol wrapper objects now throws.
Overall, this provides a stricter separation between Symbol values and
wrapper objects than before, and the explicit fetching out of the
description (nee name) via the "name" property is no longer supported
(by the spec nor the implementation.)
Adjusted existing Symbol test files to fit current, adding some extra
tests for new/changed behavior.
LOG=N
R=arv@chromium.org, rossberg@chromium.org, arv, rossberg
BUG=v8:3053
Review URL: https://codereview.chromium.org/118553003
Patch from Sigbjorn Finne <sigbjornf@opera.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19490 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This addresses several TODOs:
- Push and Pop requests can be queued up so that arrays of Registers
can be pushed efficiently, with just one PrepareForPush/Pop.
- PushMultipleTimes now takes an Operand. This allows variable-length
arguments arrays to be initialized, for example.
- A NoUseRealAbortsScope has been added to Abort so that
AssertStackConsistency can be called from PrepareForPush without
introducing infinite recursion.
BUG=
R=rmcilroy@chromium.org, ulan@chromium.org
Review URL: https://codereview.chromium.org/170623002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19474 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Code generation would fail when assembling a branch to a label that is bound
outside the immediate range of the instruction. A64 is sensitive to this, as the
various branching instructions have different ranges, going down to +-32KB for
TBZ/TBNZ. The MacroAssembler is augmented to handle branches to targets that
may exceed the immediate range of instructions.
When branching backward to a label exceeding the instruction range, the
MacroAssembler can simply tweak the generated code to use an unconditional
branch with a longer range. For example instead of
B(cond, &label);
the MacroAssembler can generate:
b(InvertCondition(cond), &done);
b(&label);
bind(&done);
Since the target is not known when the branch is emitted, forward branches uses
a different mechanism. The MacroAssembler keeps track of forward branches to
unbound labels. When the code generation approaches the end of the range of a
branch, a veneer is generated for the branch.
BUG=v8:3148
LOG=Y
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/169893002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19444 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Arithmetic right shifting is *not* division in two's complement
representation, only in one's complement. So we convert to one's
complement, shift, and go back to two's complement. By permutating the
last steps, one can get efficient branch-free code. This insight comes
from the paleozoic era of computer science, see the paper from 1976:
Guy Lewis Steele Jr.: "Arithmetic Shifting Considered Harmful"
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-378.pdf
This results in better and more correct code than our previous
"neg/shift/neg" dance.
LOG=y
BUG=v8:3151
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/166793002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19434 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
This addresses several TODOs:
- Push and Pop requests can be queued up so that arrays of Registers
can be pushed efficiently, with just one PrepareForPush/Pop.
- PushMultipleTimes now takes an Operand. This allows variable-length
arguments arrays to be initialized, for example.
- A NoUseRealAbortsScope has been added to Abort so that
AssertStackConsistency can be called from PrepareForPush without
introducing infinite recursion.
BUG=
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/169533002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19403 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
The fix removes wrong simulates from the number branch of polymorphic
call/field access handling.
The change also fixes the same thing for polymorphic named field
access even thourgh the field access is probably safe in practice
(because it cannot deoptimize). It is better to keep all our simulates
in sync with full codegen.
R=jkummerow@chromium.org
BUG=
Review URL: https://codereview.chromium.org/166503002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19375 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
This patch generalizes Object.observe callbacks and promise resolution into a FIFO queue called a "microtask queue".
It also exposes new V8 API which exposes the microtask queue to the embedder. In particular, it allows the embedder to
-schedule a microtask (EnqueueExternalMicrotask)
-run the microtask queue (RunMicrotasks)
-control whether the microtask queue is run automatically within V8 when the last script exits (SetAutorunMicrotasks).
R=dcarney@chromium.org, rossberg@chromium.org, dcarney, rossberg, svenpanne
BUG=
Review URL: https://codereview.chromium.org/154283002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19344 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
ES6 makes the Function object properties "length" and "name"
configurable; switch the implementation over to follow that.
Doing so exposed a problem in the handling of non-writable, but
configurable properties backed by foreign callback accessors
internally. As an optimization, if such an accessor property is
re-defined with a new value, its setter was passed the new value
directly, keeping the property as an accessor property. However, this
is not correct should the property be non-writable, as its setter will
then simply ignore the updated value. Adjust the enabling logic for
this optimization accordingly, along with adding a test.
LOG=N
R=rossberg@chromium.org, rossberg
BUG=v8:3045
Review URL: https://codereview.chromium.org/116083006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19200 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
