The fast-prototype test has been outsmarted by constructor inlining
because the instantiation is been correctly optimized away. Internal
state introspection about prototype turning fast was upset by that.
R=bmeurer@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1474763007
Cr-Commit-Position: refs/heads/master@{#32338}
Up until now we sometimes pass Smi 0 around as closure and expect the
runtime to translate that appropriately. But we need to be careful in
some places to not confuse the Smi 0 with a real closure. However, we
could instead just pass the correct closure extracted from the native
context.
This addresses three long-standing TODOs in the JSTypedLowering pass.
Drive-by-fix: Further unify error message reporting for ToObject (we had
a special message in case of ToObject error in with context creation).
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1475383002
Cr-Commit-Position: refs/heads/master@{#32336}
Reason for revert:
This is also unsound for the reasons outlined in
https://codereview.chromium.org/1473073004/
Will reland the mjsunit test separately and help Fedor to implement a solution based on simplified operators.
Original issue's description:
> [machine-operator-reducer] fix float truncation
>
> Don't replace `TruncateFloat64ToInt32(RoundInt64ToFloat64(value))` with
> `value`. Generally, `value` may have a range bigger than the one that
> could fit into Int32. Replace it with `TruncateInt64ToInt32(value)`
> instead, and only if the `value` fits into Float64 without precision
> loss.
>
> Add missing mjsunit test for 52bit multiplication/division optimization
> that has landed in refs/heads/master@{#31899}.
>
> BUG=
> R=titzer@google.com
>
> Committed: https://crrev.com/64efa2a904773816968992628f0bf0f1b7ae82be
> Cr-Commit-Position: refs/heads/master@{#32227}
TBR=titzer@chromium.org,fedor@indutny.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1468313009
Cr-Commit-Position: refs/heads/master@{#32312}
ES6 section 12.2.8.1 states that flags for regular expression literals
must be checked during parsing and invalid flags are early errors. This
change adapts the Scanner and (Pre)Parser to act according to the spec.
This is also a prerequisite to unify the handling of literal creation
(for Objects, Arrays, Regexps, and at some point Classes).
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1472323002
Cr-Commit-Position: refs/heads/master@{#32273}
Don't replace `TruncateFloat64ToInt32(RoundInt64ToFloat64(value))` with
`value`. Generally, `value` may have a range bigger than the one that
could fit into Int32. Replace it with `TruncateInt64ToInt32(value)`
instead, and only if the `value` fits into Float64 without precision
loss.
Add missing mjsunit test for 52bit multiplication/division optimization
that has landed in refs/heads/master@{#31899}.
BUG=
R=titzer@google.com
Review URL: https://codereview.chromium.org/1433353006
Cr-Commit-Position: refs/heads/master@{#32227}
This patch removes Promise functions and methods which are absent
from the ES2015 specification when the --es-staging flag is on.
BUG=v8:3237
R=rossberg
LOG=Y
Review URL: https://codereview.chromium.org/1469543003
Cr-Commit-Position: refs/heads/master@{#32194}
In a function expression, 'yield' is allowed, even if the expression
occurs inside a generator. Similarly, even in a non-generator,
a generator expression's name must not be 'yield'.
BUG=v8:3983
LOG=n
Review URL: https://codereview.chromium.org/1460393003
Cr-Commit-Position: refs/heads/master@{#32188}
We currently assume that all prototype maps are stable, which is
not guaranteed for certain keyed access patterns. So we explicitly
disallow optimizing the element access there for now.
BUG=chromium:557807, v8:4470
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1456973004
Cr-Commit-Position: refs/heads/master@{#32101}
This is in preparation for the addition of --harmony-destructuring-assignment.
BUG=v8:811
LOG=n
Review URL: https://codereview.chromium.org/1450193002
Cr-Commit-Position: refs/heads/master@{#32098}
When adding properties to the result object, that object's prototype chain should be ignored.
Review URL: https://codereview.chromium.org/1458873002
Cr-Commit-Position: refs/heads/master@{#32085}
This fixes the array literal expression stack tracking in the presence
of spread expressions. Deoptimization within a spread expression was
borked.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-deopt-in-array-literal-spread
Review URL: https://codereview.chromium.org/1455953002
Cr-Commit-Position: refs/heads/master@{#32079}
If the input type does not help us, we are conservative and truncate (rather than guessing signed).
Review URL: https://codereview.chromium.org/1455103002
Cr-Commit-Position: refs/heads/master@{#32075}
With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal
Review URL: https://codereview.chromium.org/1453733002
Cr-Commit-Position: refs/heads/master@{#32050}
With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal
Review URL: https://codereview.chromium.org/1452193003
Cr-Commit-Position: refs/heads/master@{#32048}
With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal
Review URL: https://codereview.chromium.org/1451423002
Cr-Commit-Position: refs/heads/master@{#32047}
Several changes are included here:
1. Each resolution callback references shared data indicating whether
it has already been resolved or not, as described in 25.4.1.3
http://tc39.github.io/ecma262/#sec-createresolvingfunctions.
Previously this was handled exclusively by the Promise's status,
which does not work correctly with the current chaining behaviour.
2. During fulfillment, When a Promise is resolved with a thenable, the
spec chains the promises together by invoking the thenable's `then`
function with the original Promise's resolve and reject methods (per
section 25.4.2.2, or
http://tc39.github.io/ecma262/#sec-promiseresolvethenablejob, on the
next tick, regardless of whether or not there are pending tasks.
3. Adds a spec compliance fix to ensure that the Promise constructor
is only loaded once when `then()` is called, solving v8:4539 as well.
This involves refactoring PromiseChain to accept a constructor
argument. PromiseChain/PromiseDeferred will hopefully be removed soon,
simplifying the process.
BUG=v8:4162, v8:4539, v8:3237
LOG=N
R=rossberg@chromium.org, littledan@chromium.org, adamk@chromium.org
Review URL: https://codereview.chromium.org/1394463003
Cr-Commit-Position: refs/heads/master@{#32046}
