Gather references to unbound variables where the reference (VariableProxy) is
inside strong mode. Check them against the global object when a script is bound
to a context (during compilation).
This CL only checks unbound variables which are not inside lazy functions - TBD
how do we solve that; alternatives: add developer mode which disables laziness /
do the check whenever lazy functions are really compiled.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1005063002
Cr-Commit-Position: refs/heads/master@{#27422}
Since recursive modules are gone, only the top-level scope can have
module inner scopes. Rename Scope::AllocateModulesRecursively to
Scope::AllocateModules, and add test showing the module Variables
are still allocated appropriately in the top level scope.
BUG=v8:1569,v8:3940
LOG=n
Review URL: https://codereview.chromium.org/999893003
Cr-Commit-Position: refs/heads/master@{#27143}
Rationale: separate the inputs and outputs of parsing + analysis from the business of compiling (i.e. generating machine code).
BUG=
Review URL: https://codereview.chromium.org/974213002
Cr-Commit-Position: refs/heads/master@{#27078}
This required fixing the exports_ hash map to use the appropriate
comparison function instead of pointer comparison.
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/960793003
Cr-Commit-Position: refs/heads/master@{#26920}
This also adds a new VariableMode, IMPORT, which will be
used to do appropriate binding for Import-declared Variables.
Only named imports are handled for now. "import *" and default
import syntaxes have had their TODOs adjusted to match the new
code structure.
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/948303004
Cr-Commit-Position: refs/heads/master@{#26895}
The FunctionLiteral returned from the parser for modules now has a MODULE_SCOPE,
instead of associating the module scope with a Block inside it. This makes
it easy to get at the ModuleDescriptor from the caller of Parse(), so I've added
a basic test that pokes at the scope and the descriptor. Expect more tests
in this vein.
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/953983002
Cr-Commit-Position: refs/heads/master@{#26836}
Add() becomes AddLocalExport, which takes an export_name and a local_name.
New parsing tests exercise this.
Also start generating exports for default exports (though this doesn't yet
handle anonymous default exports).
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/934323004
Cr-Commit-Position: refs/heads/master@{#26758}
This gets Variable and VariableProxy out of the business of worrying about
Interfaces.
At the same time, get rid of the notion of "module variables". In ES6, variables
that refer to modules will be simply be CONST bindings to module namespace
objects.
The only change in logic here is one more early error:
duplicate export names are now rejected.
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/918373002
Cr-Commit-Position: refs/heads/master@{#26708}
The preparser needs to log the usage of super properties and then update
the scope when we create the function later.
BUG=v8:3888
LOG=N
R=dslomov@chromium.org, marja
Review URL: https://codereview.chromium.org/923683002
Cr-Commit-Position: refs/heads/master@{#26642}
Parser must be able to operate independent of Isolate and the V8 heap during
parsing. After the heap-independent phase, there is a heap dependent phase,
during which we internalize strings, handle errors, etc.
This makes Isolate (also via CompilationInfo) unaccessible during parsing, and
thus decreases the probability of accidental code changes which would add
heap-dependent operations into the heap-independent phase.
Since Isolate is also accessible via CompilationInfo, now CompilationInfo is
only passed to the entry points of parsing, and not stored in Parser.
R=rossberg@chromium.org
BUG=
Review URL: https://codereview.chromium.org/908173003
Cr-Commit-Position: refs/heads/master@{#26612}
super() is only allowed in a class constructor.
super.p is allowed in methods, accessors and constructors.
The parser now checks the FunctionState to see what kind of function
we are currently inside.
BUG=v8:3330
LOG=N
R=dslomov@chromium.org, marja@chromium.org
Review URL: https://codereview.chromium.org/915563003
Cr-Commit-Position: refs/heads/master@{#26557}
Scope, like Parser, must be able to operate independent of Isolate and the V8
heap (for background parsing). After the heap-independent phase, there is a heap
dependent phase, during which we do operations such as scope anaylysis.
This CL makes the phases explicit by not telling Scope about the Isolate too
early (during the heap-independent phase, Scope should know nothing about
Isolate). This decreases the probability of accidental code changes which would
add heap-dependent operations into the heap-independent phase.
R=rossberg@chromium.org
BUG=
Review URL: https://codereview.chromium.org/909093003
Cr-Commit-Position: refs/heads/master@{#26546}
We incorrectly disallowed eval and arguments in accessor and method
names. This was because we checked the name inside the
ParseFunctionLiteral. We now flag accessors so that lazy parsing of
these functions are treated correctly.
BUG=v8:1984
R=adamk, dslomov@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/899363002
Cr-Commit-Position: refs/heads/master@{#26497}
Previously it just had hacks to have NULLs instead of them and pretended to know
nothing about Zone. The hacks provide no real benefit (probably historically
based on some weird misconception about the relationship between Zone and
Isolate), and make it harder for the PreParser to start to know more about
variables and scoping.
BUG=
Review URL: https://codereview.chromium.org/909463003
Cr-Commit-Position: refs/heads/master@{#26494}
It doesn't do anything for now, but it implies strict mode. Added tests to
test-parsing.cc to test that.
BUG=
Review URL: https://codereview.chromium.org/898983002
Cr-Commit-Position: refs/heads/master@{#26460}
size_t is the correct data type for this purpose. Our APIs (in particular
ExternalSourceStream::GetMoreData) are already using it, and there were some
static_casts to convert between them.
This CL doesn't intend to fix all of V8, just the minimal sense-making part
around scanner character streams.
BUG=
Review URL: https://codereview.chromium.org/864273005
Cr-Commit-Position: refs/heads/master@{#26449}
This enables adding more language modes in the future.
For maximum flexibility, LanguageMode is a bitmask, so we're not restricted to
use a sequence of language modes which are progressively stricter, but we can
express the language mode as combination of features.
For now, LanguageMode can only be "sloppy" or "strict", and there are
STATIC_ASSERTS in places which need to change when more modes are added.
LanguageMode is a bit like the old LanguageMode when "extended" mode was still
around (see https://codereview.chromium.org/8417035 and
https://codereview.chromium.org/181543002 ) except that it's transmitted through
all the layers (there's no StrictModeFlag).
BUG=
Review URL: https://codereview.chromium.org/894683003
Cr-Commit-Position: refs/heads/master@{#26419}
Also had to split ParseImportsList and ParseExportClause into separate
methods as they have different rules about reserved words and arguments/eval.
Added lots more test cases, including some export cases that were missed before
due to incorrect checking of reserved words.
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/887843002
Cr-Commit-Position: refs/heads/master@{#26338}
For example let and class should only be allowed inside function/block/script.
We have to continue to support const in statements in sloppy mode for backwards compatibility.
BUG=3831
LOG=Y
R=dslomov@chromium.org, adamk
Review URL: https://codereview.chromium.org/869293002
Cr-Commit-Position: refs/heads/master@{#26337}
This removes the duplicate property check from object literals.
Instead we repurpose the ObjectLiteralChecker into two cases, implemented
by two subclasses to ObjectLiteralCheckerBase called ObjectLiteralChecker
and ClassLiteralChecker.
The object literal checker now only checks for duplicate __proto__ fields in
object literals.
The class literal checker checks for duplicate constructors, non constructor
fields named constructor as well as static properties named prototype.
BUG=v8:3819
LOG=Y
R=adamk, dslomov@chromium.org
Review URL: https://codereview.chromium.org/873823003
Cr-Commit-Position: refs/heads/master@{#26336}
The approach taken in this CL is to incrementally move toward the
currently-specced version of modules in ES6. The biggest change in this
patch is separating the parsing of modules from the parsing of scripts,
getting rid of the 'module' keyword and thus disallowing modules-in-scripts
as well as modules-in-modules.
The syntax supported by import/export declarations has not yet been significantly
changed, with the major exception being that import declarations require a string
as the 'from' part.
Most of the existing tests have been disabled, with a first new test added
in cctest/test-parsing.
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/881623002
Cr-Commit-Position: refs/heads/master@{#26299}
Along the way:
- Thread isolate parameter explicitly through code that used to
rely on getting it from the zone.
- Canonicalize the parameter position of isolate and zone for
affected code
- Change Hydrogen New<> instruction templates to automatically
pass isolate
R=mstarzinger@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/868883002
Cr-Commit-Position: refs/heads/master@{#26252}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
This is a revert of the revert, 7d48fd9dc2.
BUG=v8:3754
LOG=Y
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/798243004
Cr-Commit-Position: refs/heads/master@{#26084}
Reason for revert:
[sheriff] Still crashes on win32 (XP):
http://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%201/builds/1380
Original issue's description:
> ES6 computed property names
>
> This adds support for computed property names, under the flag
> --harmony-computed-property-names, for both object literals and
> classes.
>
> This is a revert of the revert, a76419f0f4.
>
> This changes to do an early bailout in
> HOptimizedGraphBuilder::VisitObjectLiteral instead of doing that in the later
> loop.
>
> BUG=v8:3754
> LOG=Y
> TBR=dslomov@chromium.orgTBR=dslomov@chromium.org,arv@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=v8:3754
Review URL: https://codereview.chromium.org/811593004
Cr-Commit-Position: refs/heads/master@{#25872}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
This is a revert of the revert, a76419f0f4.
This changes to do an early bailout in
HOptimizedGraphBuilder::VisitObjectLiteral instead of doing that in the later
loop.
BUG=v8:3754
LOG=Y
TBR=dslomov@chromium.org
Review URL: https://codereview.chromium.org/792233008
Cr-Commit-Position: refs/heads/master@{#25868}
Reason for revert:
Crashes Win32. It was not flake.
Original issue's description:
> ES6 computed property names
>
> This adds support for computed property names, under the flag
> --harmony-computed-property-names, for both object literals and
> classes.
>
> This is a revert of the revert, a76419f0f4 with
> no changes. I cannot reproduce the issue on Win8.1 or WinXP. Letting the bots
> try again.
>
> BUG=v8:3754
> LOG=Y
> TBR=dslomov@chromium.orgTBR=dslomov@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=v8:3754
Review URL: https://codereview.chromium.org/807033003
Cr-Commit-Position: refs/heads/master@{#25853}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
This is a revert of the revert, a76419f0f4 with
no changes. I cannot reproduce the issue on Win8.1 or WinXP. Letting the bots
try again.
BUG=v8:3754
LOG=Y
TBR=dslomov@chromium.org
Review URL: https://codereview.chromium.org/807173002
Cr-Commit-Position: refs/heads/master@{#25851}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
BUG=v8:3754
LOG=Y
Review URL: https://codereview.chromium.org/795573005
Cr-Commit-Position: refs/heads/master@{#25821}
Instead, make it possible for indifidual tests to pass "always true flags" which
are not part of the varying flag set.
The downside is that if an experimental flag changes parsing of some of the
unrelated code snippets, it's noticed later (only after the flag is turned on by
default). But this is a reasonable trade off for faster tests.
Additional fix: Some tests (ErrorsFutureStrictReservedWords) were using
always_flags incorrectly (running two different tests with different
always_flags basically iterates over every flag combination anyway - most of
them twice).
BUG=v8:3707
LOG=N
Review URL: https://codereview.chromium.org/772823002
Cr-Commit-Position: refs/heads/master@{#25628}
Most of the run time came from testing with all possible flag combinations. None
of the flags passed affect the test, and there are specialized tests for testing
the features behind the flags; no need to slow down the generic test.
With these changes, run time for debug build goes from 186 s to 0.5 s.
In addition, fixed some missing commas between the test cases.
R=svenpanne@chromium.org
BUG=v8:3707
LOG=N
Review URL: https://codereview.chromium.org/766673003
Cr-Commit-Position: refs/heads/master@{#25612}
Running this in x64.release mode on a powerful HP620 takes 4 seconds,
this is at least 2 orders of magnitude too slow and leads to tons of
false positives on our build bots due to timeouts. As it is, the
cost-benefit ratio is far too low.
The whole approach needs to be changed: Instead of trying to exhaust
some search space in unit tests, this should be turned into a fuzzing
test where only a small but random number of things are tested. The
exhaustive approach can be done separately, but definitely not in the
unit tests.
BUG=v8:3707
Review URL: https://codereview.chromium.org/762743002
Cr-Commit-Position: refs/heads/master@{#25510}
Since checking all possible combinations is taking so long this
reduces the test to test the odd cases (let, yield and static) as
well as a single ordinary case.
BUG=v8:3707
LOG=n
Review URL: https://codereview.chromium.org/724713004
Cr-Commit-Position: refs/heads/master@{#25428}
The spec explicitly forbids them. V8 never handled them properly either, just
the Scanner accepted them (it had code to add them literally to the
LiteralBuffer) and later on, Regexp constructor disallowed them.
According to the spec, unicode escapes in regexp flags should be an early error
("It is a Syntax Error if IdentifierPart contains a Unicode escape sequence.").
Note that Scanner is still more relaxed about regexp flags than the
spec. Especially, it accepts any identifier parts (not just a small set of
letters) and doesn't check for duplicates.
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/700373003
Cr-Commit-Position: refs/heads/master@{#25215}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25215 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This simplifies escape handling and makes it easier to extend escapes for ES6.
PushBack just before detecting ILLEGAL is unnecessary, since we will abort the
scanning / parsing anyway at that point, and it doesn't matter where the cursor
exactly is. The error messages w/ PushBack are not any better or more correct
than without.
In addition: remove a comment about handling invalid escapes gracefully when we
no longer do. (*)
This CL includes a behavioral change: For input "var r = /foobar/g\urrrr;" we
used to report "unexpected_token: ILLEGAL" for "\u", but now we report
malformed_regexp_flags which is a more correct error message. (Note that the
code for reporting invalid_regexp_flags was dead, and invalid_regexp_flags is
not the right error message.)
Note that the V8 is more relaxed about unicode escapes in regexp flags than ES6
(see
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-regular-expressions )
and this CL doesn't change it. (V8 accepts any \uxxxx, ES6 spec says only a
certain value range is acceptable.)
(*) Code archaeology:
Originally, doing PushBack in ScanHexEscape made sense (see e.g., here
https://codereview.chromium.org/5063003/diff/6001/src/prescanner.h ), since we
wouldn't return ILLEGAL but treat an invalid escape sequence "\uxxxx" as
"uxxxx".
(The repo at that point contains another instance of the same function, from the
initial commit. The logic is the same.)
This behavior was changed in a "renaming" commit
https://codereview.chromium.org/7739020.
BUG=
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/684873002
Cr-Commit-Position: refs/heads/master@{#25031}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25031 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
ES6 no longer makes duplicate properties an error. However, we
continue to treat duplicate properties in strict mode object
literals as errors. With this change we allow duplicate properties
in class bodies. We continue to flag duplicate constructors as an
error as required by ES6.
BUG=v8:3570
LOG=Y
R=marja@chromium.org
Review URL: https://codereview.chromium.org/677953004
Cr-Commit-Position: refs/heads/master@{#24933}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24933 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This adds flags in Scope to track wheter a Scope uses "this" and,
"arguments". The information is exposed via Scope::uses_this(),
and Scope::uses_arguments(), respectively. Flags for tracking
usage on any inner scope uses are available as well via
Scope::inner_uses_this(), and Scope::inner_uses_arguments().
Knowing whether scopes use "this" and "arguments" will be handy
to generate the code needed to capture their values when generating
the code for arrow functions.
BUG=v8:2700
LOG=
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/422923004
Patch from Adrian Perez de Castro <aperez@igalia.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24663 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Background Parsers cannot get the following data from Isolate (pass it to the
ctor instead): stack limit (background Parsers need a different stack limit),
UnicodeCache (background parsers need a separate UnicodeCache), hash seed
(Parser cannot access the Heap to get it). The Parser::Parse API won't change.
- Make the internalization phase (where Parser interacts with the heap) more
explicit. Previously, Parser was interacting with the heap here and there.
- Move HandleSourceURLComments out of DoParseProgram, so that background parsing
can use DoParseProgram too.
BUG=
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/527763002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23600 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
(parser or code) and to be explicit about cache consumption or production
(rather than making presence of cached_data imply one or the other.)
Also add a --cache flag to d8, to allow testing the functionality.
-----------------------------
API change
Reason: Currently, V8 supports a 'parser cache' for repeatedly executing the same script. We'd like to add a 2nd mode that would cache code, and would like to let the embedder decide which mode they chose (if any).
Note: Previously, the 'use cached data' property was implied by the presence of the cached data itself. (That is, kNoCompileOptions and source->cached_data != NULL.) That is no longer sufficient, since the presence of data is no longer sufficient to determine /which kind/ of data is present.
Changes from old behaviour:
- If you previously didn't use caching, nothing changes.
Example:
v8::CompileUnbound(isolate, source, kNoCompileOptions);
- If you previously used caching, it worked like this:
- 1st run:
v8::CompileUnbound(isolate, source, kProduceToCache);
Then, source->cached_data would contain the
data-to-be cached. This remains the same, except you
need to tell V8 which type of data you want.
v8::CompileUnbound(isolate, source, kProduceParserCache);
- 2nd run:
v8::CompileUnbound(isolate, source, kNoCompileOptions);
with source->cached_data set to the data you received in
the first run. This will now ignore the cached data, and
you need to explicitly tell V8 to use it:
v8::CompileUnbound(isolate, source, kConsumeParserCache);
-----------------------------
BUG=
R=marja@chromium.org, yangguo@chromium.org
Review URL: https://codereview.chromium.org/389573006
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22431 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
There are a lot of tests in cctest/test-parsing/ErrorsArrowFunctions,
so it is quite slow. This patch removes some flags to make it faster.
Removing three flags that don't affect the test brings down the run
time one order of magnitude, which is fast enough even for debug/ASAN
bots.
Also, remove the unneeded kArrowFunctions flag from
cctest/test-parsing/NoErrorsYieldSloppyAllModes
BUG=
R=marja@chromium.org
Review URL: https://codereview.chromium.org/387383002
Patch from Adrián Pérez de Castro <aperez@igalia.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22392 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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 ParseArrowFunctionLiteral(), 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 the empty parameter list "()" is handled directly in
ParsePrimaryExpression(): after is has consumed the opening parenthesis,
if a closing parenthesis follows, then the only valid input is an arrow
function. In this case, ParsePrimaryExpression() directly calls
ParseArrowFunctionLiteral(), to avoid needing to return a sentinel value
to signal the empty parameter list. Because it will consume the body of
the arrow function, ParseAssignmentExpression() will not see the arrow
"=>" token as next, and return the already-parser expression.
The implementation is done in ParserBase, so it was needed to do some
additions to ParserBase, ParserTraits and PreParserTraits. Some of the
glue code can be removed later on when more more functionality is moved
to ParserBase.
Additionally, this adds a runtime flag "harmony_arrow_functions"
(disabled by default); enabling "harmony" will enable it as well.
BUG=v8:2700
LOG=N
R=marja@chromium.org
Review URL: https://codereview.chromium.org/383983002
Patch from Adrián Pérez de Castro <aperez@igalia.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22366 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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 ParseArrowFunctionLiteral(), 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 the empty parameter list "()" is handled directly in
ParsePrimaryExpression(): after is has consumed the opening parenthesis,
if a closing parenthesis follows, then the only valid input is an arrow
function. In this case, ParsePrimaryExpression() directly calls
ParseArrowFunctionLiteral(), to avoid needing to return a sentinel value
to signal the empty parameter list. Because it will consume the body of
the arrow function, ParseAssignmentExpression() will not see the arrow
"=>" token as next, and return the already-parser expression.
The implementation is done in ParserBase, so it was needed to do some
additions to ParserBase, ParserTraits and PreParserTraits. Some of the
glue code can be removed later on when more more functionality is moved
to ParserBase.
Additionally, this adds a runtime flag "harmony_arrow_functions"
(disabled by default); enabling "harmony" will enable it as well.
BUG=v8:2700
LOG=N
R=marja@chromium.org
Review URL: https://codereview.chromium.org/385553003
Patch from Adrián Pérez de Castro <aperez@igalia.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22320 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
Removing it seems to be a clear win on mobile: producing symbol data makes cold
parsing 20-30% slower, and having symbol data doesn't make warm parsing any
faster.
Notes:
- V8 used to produce symbol data, but because of a bug, it was never used until
recently. (See fix https://codereview.chromium.org/172753002 which takes the
symbol data into use again.)
- On desktop, warm parsing is faster if we have symbol data, and producing it
during cold parsing doesn't make parsing substantially slower. However, this
doesn't seem to be the case on mobile.
- The preparse data (cached data) will now contain only the positions of the
lazy functions.
BUG=
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/261273003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21146 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
