Arrow functions are parsed from ParseAssignmentExpression. Handling the
parameter list is done by letting ParseConditionalExpression() parse
a comma-separated list of identifiers, and it returns a tree of
BinaryOperation nodes with VariableProxy leaves, or a single
VariableProxy if there is only one parameter. When the arrow token "=>"
is found, the VariableProxy nodes are passed to ParseFunctionLiteral(),
which will then skip parsing the paramaeter list. This avoids having
to rewind when the arrow is found and restart parsing the parameter
list. Note that ParseExpression() expects parenthesized expressions
to not be empty, so checking for a closing parenthesis is added in
handling the empty parameter list "()" will accept a right-paren and
return an empty expression, which means that the parameter list is
empty.
Additionally, this adds the following machinery:
- A runtime flag "harmony_arrow_functions" (disabled by default).
Enabling "harmony" will enable it as well.
- An IsArrow bit in SharedFunctionInfo, and accessors for it.
- An IsArrow bit in FunctionLiteral, accessorts for it, and
a constructor parameter to set its value.
- In ParserBase: allow_arrow_functions() and set_allow_arrow_functions()
- A V8 native %FunctionIsArrow(), which is used to skip adding the
"function " prefix when getting the source code for an arrow
function.
R=marja@chromium.org
Review URL: https://codereview.chromium.org/160073006
Patch from Adrián Pérez de Castro <aperez@igalia.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22265 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
port r22232
original commit message:
This is a mostly mechanical CL (more than 90% Emacs macros and
query-replace-regexp) moving FILE*/StringStream*-based APIs to
OStream-based APIs. There are a few places where this had to stop,
otherwise the CL would be even bigger, but this can easily and
incrementally cleaned up later.
BUG=
R=weiliang.lin@intel.com
Review URL: https://codereview.chromium.org/379493002
Patch from Chunyang Dai <chunyang.dai@intel.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22259 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r22232 (f837b91)
Original commit message:
This is a mostly mechanical CL (more than 90% Emacs macros and
query-replace-regexp) moving FILE*/StringStream*-based APIs to
OStream-based APIs. There are a few places where this had to stop,
otherwise the CL would be even bigger, but this can easily and
incrementally cleaned up later.
BUG=
R=palfia@homejinni.com
Review URL: https://codereview.chromium.org/373773002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22250 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Improve code generated for immediate data processing operations where the shift
on the operation can be exploited to use fewer instructions for the immediate.
For example, Add(x0, x0, 0x1f7de) used to generate:
movz x16, 0xf7de
movk x16, 0x1, lsl #16
add x0, x0, x16
now generates:
movz x16, 0xfbef
add x0, x0, x16, lsl #1
BUG=
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/368313002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22246 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The callbacks are per isolate, so we shouldn't get the isolate implicitly
from TLS. Also, we shouldn't allow calls to these methods prior to
initializing the respective isolate (and silently ignore them).
Esp. add a per-isolate API to set the stats counter callbacks and
make it possible to set the stats counter callback after the isolate
was touched.
Embedders should use e.g. isolate->SetCounterFunction(callback) instead
of v8::V8::SetCounterFunction(callback).
BUG=none
R=svenpanne@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/365153002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22223 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Adds support to the Arm assembler to use extended constant pools.
- Update (set_)target_address_at to support extended constant pool load
updates.
- Replace Operand::is_single_instruction with Operand::instructions_required
Due to the fact that different constant pool load types require different
numbers of instructions.
- Various cleanups of ConstantPoolBuilder to cleaner integration of the
extended constant pool building.
- Update GetRelocatedValue such that offsets to both map_check and bool_load
are explicitly provided, rather than location of bool_load being inferred
based on map_check, since the code inbetween is no longer of a predictable
size.
- Update MacroAssembler::GetRelocatedValueLocation() to add support for
getting a value from an extended constant pool entry.
- Update Debug::SetAfterBreakTarget() to use target_address_from_return_address
when checking for debug breaks at constant pool load points.
- Change ConstantPoolIterateBody to iterate over both heap and code pointer in
the small section before moving onto the extended section, to work around the
requirement of the serializer that pointers are iterated in-order.
- Increase old_pointer_space SizeOfFirstPage() to offset the fact that constant
pools are now in the old pointer space (rather than code).
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/356393003
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22209 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Deserializing the partial snapshot may prematurely stop using a map page, adding a free-space filler at the end. Scan-on-scavenge of map-space did not expect anything but maps, and would interpret the uninitialized memory as pointers. Using the heap iterator we can skip over free space and only visit maps.
BUG=390732
LOG=y
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/364063007
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22208 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
