Use %_ToLength for TO_LENGTH, implemented via a ToLengthStub
that supports a fast path for small integers. Everything else is still
handled in the runtime.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
BUG=v8:4494
LOG=n
Review URL: https://codereview.chromium.org/1412963002
Cr-Commit-Position: refs/heads/master@{#31358}
Native context specialization now lowers monomorphic and
polymorphic accesses to data and constant data properties on
object and/or prototype chain. We don't deal with accessors
yet, and we also completely ignore proxies (which is compatible
with what Crankshaft does).
The code is more or less the straightforward implementation. We
will need to refactor that and extract common patterns once the
remaining bits for full load/store support is in.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Committed: https://crrev.com/3a0bf860b7177f7abef01ff308a53603389d958e
Cr-Commit-Position: refs/heads/master@{#31340}
Review URL: https://codereview.chromium.org/1396333010
Cr-Commit-Position: refs/heads/master@{#31352}
Reason for revert:
Waterfall redness.
Original issue's description:
> [turbofan] Initial support for monomorphic/polymorphic property loads.
>
> Native context specialization now lowers monomorphic and
> polymorphic accesses to data and constant data properties on
> object and/or prototype chain. We don't deal with accessors
> yet, and we also completely ignore proxies (which is compatible
> with what Crankshaft does).
>
> The code is more or less the straightforward implementation. We
> will need to refactor that and extract common patterns once the
> remaining bits for full load/store support is in.
>
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
> R=jarin@chromium.org
> BUG=v8:4470
> LOG=n
>
> Committed: https://crrev.com/3a0bf860b7177f7abef01ff308a53603389d958e
> Cr-Commit-Position: refs/heads/master@{#31340}
TBR=bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4470
Review URL: https://codereview.chromium.org/1408123002
Cr-Commit-Position: refs/heads/master@{#31341}
Native context specialization now lowers monomorphic and
polymorphic accesses to data and constant data properties on
object and/or prototype chain. We don't deal with accessors
yet, and we also completely ignore proxies (which is compatible
with what Crankshaft does).
The code is more or less the straightforward implementation. We
will need to refactor that and extract common patterns once the
remaining bits for full load/store support is in.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1396333010
Cr-Commit-Position: refs/heads/master@{#31340}
In the ES2015 spec, RegExp uses ToLength, not ToInteger, on lastIndex
to coerce it to an integer. This patch switches to ToLength when
the --harmony-tolength flag is on, and adds some tests to verify the
new behavior.
BUG=v8:4244
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1394023005
Cr-Commit-Position: refs/heads/master@{#31306}
Previously, name conflicts between var and let declarations were only
made into exceptions if they were visible at parse-time. This patch adds
runtime checks so that sloppy-mode direct eval can't introduce conflicting
var declarations. The change is implemented by traversing the scope chain
when a direct eval introduces a var declaration to look for conflicting
let declarations, up to the function boundary.
BUG=v8:4454
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1382513003
Cr-Commit-Position: refs/heads/master@{#31211}
- Reflect.deleteProperty
- Reflect.get
- Reflect.has
- Reflect.isExtensible
Reflect.get doesn't support the receiver argument yet, and
some of the others don't support proxies yet.
R=rossberg
BUG=v8:3931
LOG=n
Review URL: https://codereview.chromium.org/1379313002
Cr-Commit-Position: refs/heads/master@{#31146}
Previously, cases like
var [foo]
led to a parser crash because the parser tried to do something with
the initializer, which was not syntactically present.
This patch fixes the parser issue (implicitly creating an undefined
initializer) and inserts a check for array destructuring that the
right-hand side is coercible to an object, so it can have iterator
methods called on it safely.
BUG=v8:4462
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1384413002
Cr-Commit-Position: refs/heads/master@{#31128}
Previously, using legacy const in for-of/in loops led to a check-fail
in the parser. This was due to the fact that the destructuring bind
led to an undefined initialization to undefined in the parser, which
caused the for loop code to go down a strange path. This patch
eliminates the undefined initialization in variables declared in
for-in/of loops, so that that path is not used and the error is
fixed.
BUG=v8:4461
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1385913003
Cr-Commit-Position: refs/heads/master@{#31117}
This patch prohibits lexical bindings from being called 'let', even in
sloppy mode, following the ES2015 specification. The change affects
multiple cases of lexical bindings, including simple let/const declarations
and both kinds of for loops. var and legacy const bindings still permit
the name to be let, including in destructuring cases. Tests are added to
verify, though some cases are commented out since they led to (pre-existing)
crashes.
BUG=v8:4403
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1371263003
Cr-Commit-Position: refs/heads/master@{#31115}
Var-bindings may shadow parameters from a non-simple parameter list. When that happens: they create separate bindings, but are initialised with the respective parameter value. Thus:
(function(x, f = () => x) { var x; var y = x; x = 2; return [x, y, f()] })(1) --> [2, 1, 1]
This CL implements that by inserting a suitable assignment for every shadwowing var-variable (e.g., x = outer_x above) at the beginning of the function's body block.
R=adamk@chromium.org
BUG=v8:4440,v8:811
LOG=N
Review URL: https://codereview.chromium.org/1371333004
Cr-Commit-Position: refs/heads/master@{#31042}
The ES2015 spec is missing an extension of sloppy-mode block-scoped function
behavior to the global scope in scripts, as well as to eval. This patch
brings that hoisting to those two areas. The behavior is not perfectly
spec-compliant since properties created on the global scope should be
set as enumerable even if they are non-enumerable previously, but the
attributes will not be modified if the property already exists under
this patch.
BUG=v8:4441
LOG=Y
R=adamk
TEST=reddit comment functionality seems to be fixed
Review URL: https://codereview.chromium.org/1376623002
Cr-Commit-Position: refs/heads/master@{#31037}
Arrow functions have been enabled by default since the 4.5 branch.
Review URL: https://codereview.chromium.org/1373633002
Cr-Commit-Position: refs/heads/master@{#31031}
The actual Function.prototype.toMethod was removed some time already,
but there were some stuff (esp. %ToMethod) left in the tree, including
tests for %ToMethod. This code (and esp. the tests) cause trouble in
the process of moving bound functions away from JSFunction; so since
the code is unused anyway, we can as well remove it.
The original removal of Function.prototype.toMethod was in February
2015 in 68e4897586.
R=jarin@chromium.org
BUG=v8:3330
LOG=n
Review URL: https://codereview.chromium.org/1366063002
Cr-Commit-Position: refs/heads/master@{#30925}
This adds the materialized literal count accumulated while parsing the
parameters (in the parser proper) to that accumulated by the preparser.
This should have been caught in cctest/test-parsing, but it's not covered
because the parsing tests call directly into the preparser rather than
using Parser::ParseFunctionLiteral (which fully-parses the parameters
and then calls into the preparser to skip over the function body).
Note that this further-inflates the materialized literal count for
functions with destructured arguments, since some of the counted
literals are actually binding patterns. But that's not specific to
binding patterns in formal parameters: it happens in function bodies, too.
BUG=v8:4400,v8:4407
LOG=n
Review URL: https://codereview.chromium.org/1350913005
Cr-Commit-Position: refs/heads/master@{#30868}
ES2015 specifies very particular semantics for functions defined in blocks.
In strict mode, it is simply a lexical binding scoped to that block. In sloppy
mode, in addition to that lexical binding, there is a var-style binding in
the outer scope, which is overwritten with the local binding when the function
declaration is evaluated, *as long as* introducing ths var binding would not
create a var/let conflict in the outer scope.
This patch implements the semantics by introducing a DelegateStatement, which
is initially filled in with the EmptyStatement and overwritten with the
assignment when the scope is closed out and it can be checked that there is
no conflict.
This patch is tested with a new mjsunit test, and I tried staging it and running
test262, finding that the tests that we have disabled due to lack of Annex B
support now pass.
R=adamk,rossberg
LOG=Y
BUG=v8:4285
Review URL: https://codereview.chromium.org/1332873003
Cr-Commit-Position: refs/heads/master@{#30842}
It's been enabled since M45, which is now well into its stable period,
with no problems reported.
Review URL: https://codereview.chromium.org/1356793002
Cr-Commit-Position: refs/heads/master@{#30835}
Defines a new --harmony-tolength flag, and a ToLengthFlagged() runtime function,
that is used where ES6 requires ToLength(), but a pre-ES6 conversion existed
before. When the flag is disabled, the function uses TO_UINT32(), which is
the pre-ES6 behaviour. When the flag enabled, the ES6-compliant ToLength()
conversion is used.
Based on a patch initially from Diego Pino <dpino@igalia.com>
BUG=v8:3087
LOG=Y
Review URL: https://codereview.chromium.org/1309243003
Cr-Commit-Position: refs/heads/master@{#30772}
Add support for `get` and `set` as shorthand properties. Also
supports them for CoverInitializedName in BindingPatterns and (once implemented)
AssignmentPatterns.
BUG=v8:4412, v8:3584
LOG=N
R=adamk, aperez, wingo, rossberg
Review URL: https://codereview.chromium.org/1328083002
Cr-Commit-Position: refs/heads/master@{#30769}
Mark ArrayLiterals utilizing the spread operator as non-simple.
This causes them to return false for IsCompileTimeValue, and thus
causes spread to work as expected in nested literals.
BUG=v8:4417
LOG=y
Review URL: https://codereview.chromium.org/1336123002
Cr-Commit-Position: refs/heads/master@{#30754}
The semantics of the %_CallFunction intrinsic seem to be very unclear,
which resulted in a lot of bugs. Especially the combination with
%IsSloppyModeFunction is always a bug, because the receiver would be
wrapped in the wrong context. So the %IsSloppyModeFunction helper is
gone now, and many of the buggy uses of %_CallFunction are also
eliminated.
If you ever need to call something with a different receiver, then
%_Call is your friend now. It does what you want and implements the
call sequence fully (and correct).
BUG=v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1325573004
Cr-Commit-Position: refs/heads/master@{#30634}
This way we don't need to expose JSReceiver::OrdinaryToPrimitive
as runtime function, and we don't need the separate JS trampoline.
This also adds tests for ToPrimitive on date objects, which are
special.
R=mstarzinger@chromium.org
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1324713002
Cr-Commit-Position: refs/heads/master@{#30473}
This patch makes 'let' a contextual keyword in both strict and sloppy mode.
It behaves as a keyword when used at the beginning of a StatementListItem
or lexical declaration at the beginning of a for statement, if it is followed
by an identifier, [ or {. Implementing this change requires an extra token
look-ahead by the parser which is only invoked in certain cases (so as to
avoid parsing RegExps as ECMAScript tokens). This might result in a slowdown
of the scanner, but performance testing of this patch hasn't yet found much
of a regression.
BUG=v8:3305
LOG=Y
R=adamk,vogelheim
Review URL: https://codereview.chromium.org/1315673009
Cr-Commit-Position: refs/heads/master@{#30451}
This adds a new ToString runtime function and a fast-path ToStringStub
(which is just a simple dispatcher for existing functionality), and also
implements %_ToName using the ToStringStub.
R=mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1319973007
Cr-Commit-Position: refs/heads/master@{#30442}
This adds a %ToName runtime entry that uses the previously introduced
Object::ToName, which is based on the new Object::ToPrimitive method.
Also removes the need to expose ToName in various way via the builtins
and/or context.
Drive-by-fix: Let %HasProperty do the ToName conversion implicitly as
required.
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1319133002
Cr-Commit-Position: refs/heads/master@{#30435}
This is the first step towards a spec compliant ToPrimitive
implementation (and therefore spec compliant ToNumber, ToString,
ToName, and friends). It adds support for the @@toPrimitive
symbol that was introduced with ES2015, and also adds the new
Symbol.prototype[@@toPrimitive] and Date.prototype[@@toPrimitive]
initial properties.
There are now runtime functions for %ToPrimitive, %ToNumber and
%ToString, which do the right thing and should be used as fallbacks
instead of the hairy runtime.js implementations. I will do the
same for the other conversion operations mentioned by the spec in
follow up CLs. Once everything is in place we can look into
optimizing things further, so that we don't always call into the
runtime.
Also fixed Date.prototype.toJSON to be spec compliant.
R=mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4307
LOG=y
Review URL: https://codereview.chromium.org/1306303003
Cr-Commit-Position: refs/heads/master@{#30434}
TC39 agreed to disallow "use strict" directives in function body when
non-simple parameter lists are used.
This is a continuation of caitp's CL https://codereview.chromium.org/1281163002/
with some refactorings removed for now.
Still TODO: there is a lot of duplication between the is_simple field of
FormalParametersBase and the NonSimpleParameter property ExpressionClassifier
keeps track of. It should be possible to remove the former with a minor
refactoring of arrow function parsing. This will be attempted in a follow-up CL.
BUG=
LOG=N
Review URL: https://codereview.chromium.org/1300103005
Cr-Commit-Position: refs/heads/master@{#30388}
Adds Uint32x4, Uint16x8, and Uint8x16 types.
Adds all functions in the current spec, except for loads and stores.
LOG=Y
BUG=v8:4124
Review URL: https://codereview.chromium.org/1294513004
Cr-Commit-Position: refs/heads/master@{#30322}
This CL is a nightmare! For the utterly irrelevant edge case of a sloppy function with non-simple parameters and a call to direct eval, like here,
let x = 1;
function f(g = () => x) {
var y
eval("var x = 2")
return g() + x // f() = 3
}
we have to do all of the following, on top of the declaration block ("varblock") contexts we already introduce around the body:
- Introduce the ability for varblock contexts to have both a ScopeInfo and an extension object (e.g., the body varblock in the example will contain both a static var y and a dynamic var x). No other scope needs that. Since there are no context slots left, a special new struct is introduced that pairs up scope info and extension object.
- When declaring lookup slots in the runtime, this new struct is allocated in the case where an extension object has to be added to a block scope (at which point the block's extension slot still contains a plain ScopeInfo).
- While at it, introduce some abstraction to access context extension slots in a more controlled manner, in order to keep special-casing to a minimum.
- Make sure that even empty varblock contexts do not get optimised away when they contain a sloppy eval, so that they can host the potential extension object.
- Extend dynamic search for declaration contexts (used by sloppy direct eval) to recognize varblock contexts.
- In the parser, if a function has a sloppy direct eval, introduce an additional varblock scope around each non-simple (desugared) parameter, as required by the spec to contain possible dynamic var bindings.
- In the pattern rewriter, add the ability to hoist the named variables the pattern declares to an outer scope. That is required because the actual destructuring has to be evaluated inside the protecting varblock scope, but the bindings that the desugaring introduces are in the outer scope.
- ScopeInfos need to save the information whether a block is a varblock, to make sloppy eval calls work correctly that deserialise them as part of the scope chain.
- Add the ability to materialize block scopes with extension objects in the debugger. Likewise, enable setting extension variables in block scopes via the debugger interface.
- While at it, refactor and unify some respective code in the debugger.
Sorry, this CL is large. I could try to split it up, but everything is rather entangled.
@mstarzinger: Please review the changes to contexts.
@yangguo: Please have a look at the debugger stuff.
R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:811,v8:2160
LOG=N
Review URL: https://codereview.chromium.org/1292753007
Cr-Commit-Position: refs/heads/master@{#30295}
Second item in section 13.7.5.1 states that the error should be a
SyntaxError, when previously CheckAndRewriteReferenceExpression
would always emit a ReferenceError.
BUG=v8:4373
R=adamk, rossberg
LOG=N
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1292393002
Cr-Commit-Position: refs/heads/master@{#30184}
