We use a signaling NaN to represent the hole in
FAST_HOLEY_DOUBLE_ELEMENTS backing stores, but on Intel processors, the
C++ compiler may decide to (or be forced to due to calling conventions)
use X87 registers for double values. However transfering to X87
registers automatically quietens the NaNs and there's no way to disable
this. Therefore we should just always load the hole NaN from the canonical
place identified by the address_of_hole_nan external reference instead,
which might even be more efficient in some cases.
R=jarin@chromium.org, jkummerow@chromium.org
BUG=v8:5332
Review-Url: https://codereview.chromium.org/2303643002
Cr-Commit-Position: refs/heads/master@{#39062}
When we try to further fold previously folded allocations in Crankshaft
GVN we don't properly transform the allocations involved, which causes
the mechanism to leave holes in the new/old space (and thereby violate
the iterability property of the new/old space).
BUG=chromium:621868
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2297983003
Cr-Commit-Position: refs/heads/master@{#39040}
Tail calls don't make sense from async functions and generators, as
each activation of these functions needs to make a new, distnict,
non-reused generator object. These tail calls are not required per
spec. This patch disables both syntactic and implicit tail calls
in async functions and generators.
R=neis
BUG=v8:5301,chromium:639270
Review-Url: https://codereview.chromium.org/2278413003
Cr-Commit-Position: refs/heads/master@{#38986}
This preserves the original shared code of the underlying function when
bytecode is provided. The method in question should only ensure bytecode
is present, but should avoid switching compilation tiers of the given
function. It might be that the function was fast-tracked to baseline by
inlining without going through the interpreted tier first.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-635923
BUG=chromium:635923
Review-Url: https://codereview.chromium.org/2278543002
Cr-Commit-Position: refs/heads/master@{#38866}
Don't bother using %_IsJSReceiver, which immediately gets lowered to
ObjectIsReceiver anyways (by the JSIntrinsicLowering), but requires
some complicated rewiring of effect/control chains.
R=mstarzinger@chromium.org
BUG=chromium:640369
Review-Url: https://codereview.chromium.org/2271973003
Cr-Commit-Position: refs/heads/master@{#38864}
Make use of %IsAsmWasmCode in place of Wasm.instantiateModuleFromAsm,
in order to reduce the surface area of the Wasm object,
and to focus on testing asm.js coming in via the parser.
Ignore extra CONST_LEGACY assignment introduced by the parser
when modules have the form:
(function Foo(a, b, c) {..});
This requires both a validator and AsmWasmBuilder change.
Move stdlib use collection to import time,
to reject modules that import a function, even if not used.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
LOG=N
R=jpp@chromium.org,titzer@chromium.org
Review-Url: https://codereview.chromium.org/2264913002
Cr-Commit-Position: refs/heads/master@{#38806}
Record which asm.js stdlib members are used and add a check that NaN is actually correctly set. Other stdlib members to be added in a later change.
Also add a stdlib argument to Wasm.instantiateModuleFromAsm, in preparation for that function to be replaced by normal asm.js instantiation.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
LOG=N
R=jpp@chromium.org,titzer@chromium.org
Review-Url: https://codereview.chromium.org/2251433002
Cr-Commit-Position: refs/heads/master@{#38760}
This fixes canonicalization of {SharedFunctionInfo} objects in the
{Compiler::GetSharedFunctionInfo} method when bytecode is preserved.
Eager compilation is only triggered when no code is present.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-638551
BUG=chromium:638551
Review-Url: https://codereview.chromium.org/2245263006
Cr-Commit-Position: refs/heads/master@{#38709}
Ensures SMI values have SMI type even if they have a dot (e.g., 1.0).
Adds SMI_WITH_DOT type to maintain this.
BUG=chromium:638134
Review-Url: https://codereview.chromium.org/2248693005
Cr-Commit-Position: refs/heads/master@{#38698}
Properly deoptimize if the left hand side of a CheckedInt32Mod is
negative and the result of the operation is zero.
R=jarin@chromium.org
BUG=v8:5286
Review-Url: https://codereview.chromium.org/2243803002
Cr-Commit-Position: refs/heads/master@{#38615}
This bug was triggered by a very specific combination:
* A context-allocated variable at script scope.
* OSR optimization.
* A scheduled breakpoint, which triggers at stack checks.
Stack checks differ from other possible breakpoint locations in that
the context (among other things) may be in a register and not on the
stack, making it impossible to recover during deoptimization. The
frame_inspector then returns undefined when asked for the context.
In GetFrameDetails, handle this case by omitting all context-allocated
variables.
BUG=v8:5279
Review-Url: https://codereview.chromium.org/2245603002
Cr-Commit-Position: refs/heads/master@{#38611}
For holey/growing keyed stores, we need to check that there are no
setters in the prototype chain and protect against changes to that
via code dependencies.
R=verwaest@chromium.org
BUG=v8:5275,v8:5276
Review-Url: https://codereview.chromium.org/2231683002
Cr-Commit-Position: refs/heads/master@{#38514}
When we compile a growing store in TurboFan, we don't pass a (native)
context to the %GrowArrayElements fallback function, as the whole logic
is actually context independent. However, that means that we need to
bailout early in case the object is a prototype, which requires context
dependent checks in the array protector code.
R=cbruni@chromium.org
BUG=chromium:635798
Review-Url: https://codereview.chromium.org/2224253003
Cr-Commit-Position: refs/heads/master@{#38491}
This fixes the runtime profiler to no longer assume that seeing an
optimized frame on the stack implies the underlying function is not
being interpreted when entered normally. This no longer holds with code
generated for OSR directly from bytecode (not installed on function).
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-632800
BUG=chromium:632800
Review-Url: https://codereview.chromium.org/2208603005
Cr-Commit-Position: refs/heads/master@{#38360}
This makes sure we prevent a tier-up for function which also have an
optimized activation of OSR code on the stack. In case the OSR code
deoptimizes, it needs the bytecode to still be around.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-5262
BUG=v8:5262
Review-Url: https://codereview.chromium.org/2206363004
Cr-Commit-Position: refs/heads/master@{#38359}
We don't need to add stability dependencies on JSObject prototypes when
storing to an element, because we do the map check (and thereby guard
the elements kind) and we also properly deoptimize on holes if the array
protector is not usable.
R=verwaest@chromium.org
BUG=chromium:616709
Review-Url: https://codereview.chromium.org/2198833002
Cr-Commit-Position: refs/heads/master@{#38355}
This adds the missing lazy bailout point when defining accessor pairs
within object literals via Runtime::kDefineAccessorPropertyUnchecked.
The runtime function in question can indeed trigger a lazy deopt due
to a DependentCode::kPrototypeCheckGroup dependency.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-633585
BUG=chromium:633585
Review-Url: https://codereview.chromium.org/2207413002
Cr-Commit-Position: refs/heads/master@{#38336}
An infinite recursion can be triggered when NoSideEffectToString is
called on an error object with its name property set to itself.
BUG=633998
Review-Url: https://codereview.chromium.org/2206313002
Cr-Commit-Position: refs/heads/master@{#38325}
Avoids compiling baseline code when the function isn't able to be
optimized by crankshaft.
BUG=chromium:632289
Review-Url: https://codereview.chromium.org/2194453002
Cr-Commit-Position: refs/heads/master@{#38304}
We cannot just blindly make a representation selection for Phi or Select
based on the truncations, but we also need to consider the type of the
inputs (or actually of the Phi/Select node itself). We can only use
Word32 representation based on Word32 truncation if the inputs are
Number or Oddball, same for Float64.
R=epertoso@chromium.org
BUG=v8:5255
Review-Url: https://codereview.chromium.org/2206553002
Cr-Commit-Position: refs/heads/master@{#38241}
This makes sure we are not inserting {OsrPoll} instructions for any
statements that are not actually loops and have no back edges. Without
back edges the {BytecodeGraphBuilder} is unable to deduce loop ranges
and hence cannot construct a graph for OSR entry.
R=neis@chromium.org
TEST=mjsunit/regress/regress-5252
BUG=v8:5252
Review-Url: https://codereview.chromium.org/2200733002
Cr-Commit-Position: refs/heads/master@{#38233}
When we narrow a signed32 comparison to uint8 or uint16 representation,
we also need to change the condition to unsigned comparisons otherwise
the comparison will be done on int16/int8 which interprets the narrowed
bits wrong.
R=epertoso@chromium.org
BUG=v8:5254
Review-Url: https://codereview.chromium.org/2202803003
Cr-Commit-Position: refs/heads/master@{#38231}
Previously, the stack property was set up in JS as read-only; but since
it had a JS setter, writability was ignored and writing to stack was
possible.
This is no longer the case now that stack is either an actual data
property, or is associated with C++ accessors. Explicitly set the
property as writable to preserve old behavior.
BUG=5245
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2190313002
Cr-Commit-Position: refs/heads/master@{#38158}
In the process also inline the stub into the appropriate interpreter bytecode
handler and make sure that the context register is preserved in hand-written
assembly code that calls the stub and expects the context register to be
preserved.
BUG=608675
Review-Url: https://codereview.chromium.org/2188993003
Cr-Commit-Position: refs/heads/master@{#38132}
Objects that reside below the age mark could be on pages that have been moved
within new space. In this case mementos survived which can actually point to
already-collected allocation sites.
BUG=chromium:631050,chromium:581412
R=hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2179033005
Cr-Commit-Position: refs/heads/master@{#38094}
When we eliminate nodes during truncation analysis that have no value
uses, we must make sure that we do not eliminate speculative number
operations that would have side effects depending on the inputs, i.e.
for example a SpeculativeNumberMultiply(x,y) does ToNumber(x) and
ToNumber(y) first, so if either x or y could throw an exception during
ToNumber conversion, we must not eliminate the multiplication, even if
it has no value uses (some later pass may kill the actual machine
multiplication, but the checks on the inputs have to remain still).
So we check whether both x and y are PlainPrimitive, i.e. neither
Receiver nor Symbol, which could raise exceptions for ToNumber, and
only in that case we propagate the "unusedness" of the node to its
inputs.
This also uncovered a bug with the type of Dead, which must be None,
as this represents an impossible value, so we had to fix that too.
Also the dead code removal will not work correctly for constants (i.e.
pure nodes with no value inputs), as those might be cached and hence
we might resurrect them for an unrelated node lowering during
SimplifiedLowering and only later kill the actual node (replacing its
uses with Dead), which would then also replace the new use with Dead.
So that was fixed as well. This shouldn't change anything for the
result, as unused constants automagically disappear from the graph later
on anyways.
R=yangguo@chromium.org
BUG=chromium:631318
Review-Url: https://codereview.chromium.org/2182003002
Cr-Commit-Position: refs/heads/master@{#38038}
Introducing machine operators early causes trouble for the typing,
truncation analysis and representation selection, so we should rather
stick to simplified operators instead. Now there's only the for-in case
left, which is not clear how we can handle this in a better way.
Drive-by-fix: Also don't introduce Int32Constant and Word32Shl in
JSTypedLowering, but use NumberConstant and proper NumberShiftLeft
operators instead.
R=jarin@chromium.org
BUG=chromium:630951
Review-Url: https://codereview.chromium.org/2182453002
Cr-Commit-Position: refs/heads/master@{#38008}
The dead code elimination in SimplifiedLowering can eliminate pure nodes
if they don't have value uses. But some of those can indeed have control
inputs, i.e. Phi nodes do of course have a control input.
R=jarin@chromium.org
BUG=chromium:630923
Review-Url: https://codereview.chromium.org/2177133002
Cr-Commit-Position: refs/heads/master@{#37995}
In PrependElementIndicesImpl we sort a FixedArray of indices potentially
containing HeapNumbers. During the string conversion we might trigger a GC.
This in turn might try to read a slot where we previously had a HeapNumber
but the sort sneaked a SMI in there which is not a valid pointer.
BUG=chromium:630561
Review-Url: https://codereview.chromium.org/2173653003
Cr-Commit-Position: refs/heads/master@{#37993}
This is in preparation to implementing exception prediction for async
functions. Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.
To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.
The previous implementation of using the function to tell the relevant
try-catch apart from inner try-catch blocks will not work for async functions
since these can have inner try-catch blocks inside the same function.
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2161263003
Cr-Commit-Position: refs/heads/master@{#37966}
The optimizing compilers actually invoke %TransitionElementsKind for
any kind of JSObject, the only relevant thing is the elements kind.
The runtime function was however checking for JSArray unnecessarily.
This only worked by coincindence in Crankshaft because the stub would
normally not call into the runtime fallback.
R=jarin@chromium.org
BUG=chromium:629823
Review-Url: https://codereview.chromium.org/2166963004
Cr-Commit-Position: refs/heads/master@{#37919}
This ports a large portion of Error methods to C++,
including the constructor, stack setter and getter,
and Error.prototype.toString.
BUG=
Review-Url: https://codereview.chromium.org/2142933003
Cr-Commit-Position: refs/heads/master@{#37870}
We need to pay attention to potential side effects from parameter
evaluation when inlining the fast case Array.prototype.shift.
R=yangguo@chromium.org
BUG=chromium:614644
Review-Url: https://codereview.chromium.org/2161943002
Cr-Commit-Position: refs/heads/master@{#37850}
The bug occurs because we do not canonicalize character class ranges
before adding case equivalents. While adding case equivalents, we abort
early for one-byte subject strings, assuming that the ranges are sorted.
Which they are not.
R=marja@chromium.org
BUG=v8:5199
Review-Url: https://codereview.chromium.org/2159683002
Cr-Commit-Position: refs/heads/master@{#37833}
This fixes the deoptimization information for the lazy bailout point
after a [[ToObject]] operation inserted for with statements. The result
value was pushed on the operand stack but erroneously ignored and left
on the operand stack by the FullCodeGenerator.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-5205
BUG=v8:5205
Review-Url: https://codereview.chromium.org/2158443002
Cr-Commit-Position: refs/heads/master@{#37818}
Using the Hydrogen code stub bailout mechanism is not correct for the
string length overflow check in the StringAddStub. Instead make sure we
just throw the proper exception.
R=mstarzinger@chromium.org
BUG=chromium:627934
Review-Url: https://codereview.chromium.org/2146353002
Cr-Commit-Position: refs/heads/master@{#37758}
This adds a missing conversion of time zone names to string primitives
before case conversion and regular expression matching are applied.
This is in sync with ECMA-402, section 12.1.1.1, step 16(a).
R=jochen@chromium.org
TEST=mjsunit/regress/regress-crbug-627935
BUG=chromium:627935
Review-Url: https://codereview.chromium.org/2143003005
Cr-Commit-Position: refs/heads/master@{#37757}
This fixes the deoptimization information for the lazy bailout point
after a [[ToName]] operation inserted for object literals and class
literals. The result value was erroneously ignored.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-627828
BUG=chromium:627828
Review-Url: https://codereview.chromium.org/2149493003
Cr-Commit-Position: refs/heads/master@{#37719}
Collect type feedback in the call bytecode handler. The current
implementation only collects feedback for JS function objects. The other
objects and Array functions do not collect any feedback. They will be
marked Megamorphic.
BUG=v8:4280, v8:4780
LOG=N
Review-Url: https://codereview.chromium.org/2122183002
Cr-Commit-Position: refs/heads/master@{#37700}
- check that packed elements do not contain the_hole (with fix)
- verify argument objects with elements kind
- use JSObjectVerifiy in all JSObject "subclasses"
- change initialization order for ArrayLiteralBoilerplate to simplify verification
BUG=v8:5188
Review-Url: https://codereview.chromium.org/2126613002
Cr-Commit-Position: refs/heads/master@{#37680}
CallSite::IsConstructor() was unable to recognize builtin construct stubs
(NumberConstructor_ConstructStub and StringConstructor_ConstructStub) as
constructors, and thus these frames were not formatted correctly in stack
traces.
Fix this by explicitly marking their Code objects as construct stubs and
passing along a special receiver value when we encounter such cases in
CaptureSimpleStackTrace.
R=mstarzinger@chromium.org, yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2125163004
Cr-Commit-Position: refs/heads/master@{#37631}
For variables introduced as part of a catch pattern, we used to set their
"initializer position" to the beginning of the pattern. This lead to
full-codegen eliminating crucial hole checks when reading such variables
inside the pattern itself.
R=adamk@chromium.org, littledan@chromium.org
BUG=v8:5178
Review-Url: https://codereview.chromium.org/2123953002
Cr-Commit-Position: refs/heads/master@{#37569}
While the test was useful to reproduce the issue locally it creates a lot of
heap pressure and causes all sorts of troubles (OOM, slowness) on the bots, so
let's drop it.
R=hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2127803002
Cr-Commit-Position: refs/heads/master@{#37551}
This removes explicit uses of the RUNTIME_ASSERT macro from some runtime
methods. The implicit ones in CONVERT_FOO_ARG_CHECKED will be addressed
in a separate CL for all runtime modules at once.
R=yangguo@chromium.org
BUG=v8:5066
Review-Url: https://codereview.chromium.org/2053573004
Cr-Commit-Position: refs/heads/master@{#37545}
This is a quick fix for the hole leaking from generators via the debugger's frame
inspection feature: when collecting the arguments, convert each hole to undefined.
In the long term, we probably want to remember and restore the actual arguments
rather than pushing these dummy arguments on each resume.
BUG=v8:5164
Review-Url: https://codereview.chromium.org/2122923003
Cr-Commit-Position: refs/heads/master@{#37544}
The dependency would only happen if we have a smi overflow for the length and
have create a heap number. In this case the heap number would've to survive
until the array buffer is collected.
To avoid this dependency we track the length (as we previously used to).
BUG=chromium:625752
LOG=N
TEST=test/mjsunit/regress/regress-625752.js
R=hpayer@chromium.org
This reverts commit 1791d7bb9a.
Review-Url: https://codereview.chromium.org/2127643002
Cr-Commit-Position: refs/heads/master@{#37537}
Reason for revert:
[Sheriff] This makes mjsunit/regress/regress-625752 extremely slow on all gc stress bots and leads to timeouts with custom snapshot:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/6602
Original issue's description:
> [heap] Track length for array buffers to avoid free-ing dependency
>
> The dependency would only happen if we have a smi overflow for the length and
> have create a heap number. In this case the heap number would've to survive
> until the array buffer is collected.
>
> To avoid this dependency we track the length (as we previously used to).
>
> BUG=chromium:625748,chromium:625752
> LOG=N
> TEST=test/mjsunit/regress/regress-625752.js
> R=hpayer@chromium.org
>
> Committed: https://crrev.com/ddc75cc1356a58b6cfd63f9da0586e1150496b3d
> Cr-Commit-Position: refs/heads/master@{#37530}
TBR=hpayer@chromium.org,mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:625748,chromium:625752
Review-Url: https://codereview.chromium.org/2127483003
Cr-Commit-Position: refs/heads/master@{#37533}
The dependency would only happen if we have a smi overflow for the length and
have create a heap number. In this case the heap number would've to survive
until the array buffer is collected.
To avoid this dependency we track the length (as we previously used to).
BUG=chromium:625748,chromium:625752
LOG=N
TEST=test/mjsunit/regress/regress-625752.js
R=hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2122603004
Cr-Commit-Position: refs/heads/master@{#37530}
This concerns formatting of calls to, e.g., Math.acos in stack traces,
in which the receiver is an object with an attached toString tag. If
such a tag exists, use it to format the receiver typename to ensure that
the stack trace includes 'Math.acos' instead of 'Object.acos'.
R=yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2110683007
Cr-Commit-Position: refs/heads/master@{#37513}
Stack trace generation requires access to the receiver; and while the
receiver is already on the stack, we cannot determine its position
during stack trace generation (it's stored in argv[0], and argc is only
stored in a callee-saved register).
This patch grants access to the receiver by pushing argc onto builtin
exit frames as an extra argument. Compared to simply pushing the
receiver, this requires an additional dereference during stack trace
generation, but one fewer during builtin calls.
BUG=v8:4815
Review-Url: https://codereview.chromium.org/2106883003
Cr-Commit-Position: refs/heads/master@{#37500}
This patch implements "immutable prototype exotic objects" from the ECMAScript
spec, which are objects whose __proto__ cannot be changed, but are not otherwise
frozen. They are introduced in order to prevent a Proxy from being introduced
to the prototype chain of the global object.
The API is extended by a SetImmutablePrototype() call in ObjectTemplate, which
can be used to vend new immutable prototype objects. Additionally, Object.prototype
is an immutable prototype object.
In the implementation, a new bit is added to Maps to say whether the prototype is
immutable, which is read by SetPrototype. Map transitions to the immutable prototype
state are not saved in the transition tree because the main use case is just for
the prototype chain of the global object, which there will be only one of per
Context, so no need to take up the extra word for a pointer in each full transition
tree.
BUG=v8:5149
Review-Url: https://codereview.chromium.org/2108203002
Cr-Commit-Position: refs/heads/master@{#37482}
This makes the elimination of checkpoints flowing effect-wise into nodes
having the {Return} operator more permissive. We can cut out checkpoints
even when they are not wholly owned by the return. This also alleviates
a problem where TCO no longer applies.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-624747
BUG=chromium:624747
Review-Url: https://codereview.chromium.org/2118793002
Cr-Commit-Position: refs/heads/master@{#37480}
This ensures no eager bailout point is emitted after a comma expression
in test context where the right-hand side omitted an eager bailout point
as well. This is to stay in sync with full-codegen.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-624919
BUG=chromium:624919
Review-Url: https://codereview.chromium.org/2113893004
Cr-Commit-Position: refs/heads/master@{#37475}
This turns the blacklist back into a white-list adding all binary operations as allowed operations. The one known fix is that it forces canonicalization of the double-hole as double constant.
BUG=chromium:621147
Review-Url: https://codereview.chromium.org/2106393002
Cr-Commit-Position: refs/heads/master@{#37452}
Prior to this commit, calls to C++ builtins created standard exit
frames, which are skipped when constructing JS stack traces. In order to
show these calls on traces, we introduce a new builtin exit frame type.
Builtin exit frames contain target and new.target on the stack and are
not skipped during stack trace construction.
BUG=v8:4815
R=bmeurer@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel;tryserver.v8:v8_linux_nosnap_dbg
Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
Review-Url: https://codereview.chromium.org/2090723005
Cr-Original-Commit-Position: refs/heads/master@{#37384}
Cr-Commit-Position: refs/heads/master@{#37416}
Previously, any expressions inside destructuring patterns in a catch
would be parsed in the surrounding scope, instead of in the catch's
scope. This change fixes that by entering not only the catch scope,
but also the block scope inside it.
R=neis@chromium.org
BUG=v8:5106, v8:5112
Review-Url: https://codereview.chromium.org/2110193002
Cr-Commit-Position: refs/heads/master@{#37415}
Reason for revert:
Looks like this breaks on nosnap: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/7626
Original issue's description:
> [builtins] New frame type for exits to C++ builtins
>
> Prior to this commit, calls to C++ builtins created standard exit
> frames, which are skipped when constructing JS stack traces. In order to
> show these calls on traces, we introduce a new builtin exit frame type.
>
> Builtin exit frames contain target and new.target on the stack and are
> not skipped during stack trace construction.
>
> BUG=v8:4815
> R=bmeurer@chromium.org, yangguo@chromium.org
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
>
> Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
> Cr-Commit-Position: refs/heads/master@{#37384}
TBR=yangguo@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4815
Review-Url: https://codereview.chromium.org/2106113002
Cr-Commit-Position: refs/heads/master@{#37394}
Prior to this commit, calls to C++ builtins created standard exit
frames, which are skipped when constructing JS stack traces. In order to
show these calls on traces, we introduce a new builtin exit frame type.
Builtin exit frames contain target and new.target on the stack and are
not skipped during stack trace construction.
BUG=v8:4815
R=bmeurer@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review-Url: https://codereview.chromium.org/2090723005
Cr-Commit-Position: refs/heads/master@{#37384}
The lastIndex property must be written with the semantics of a strict [[Set]],
so an exception must be thrown when the attributes don't allow writing. We used
to ignore the attributes.
R=littledan@chromium.org, yangguo@chromium.org
BUG=v8:5138
Review-Url: https://codereview.chromium.org/2109593002
Cr-Commit-Position: refs/heads/master@{#37369}
Comparisons were allowing asm 'int' values in places
that require strict 'signed' or 'unsigned' but not both.
Fixes crash when these make it to asm-wasm.
BUG=599413
BUG=v8:4203
R=aseemgarg@chromium.org
Review-Url: https://codereview.chromium.org/2106683003
Cr-Commit-Position: refs/heads/master@{#37353}
We were not checking that the string passed to instantiateFromAsm
contains a function declaration (any declaration was allowed).
Fixes crash.
BUG=620649
BUG=v8:4203
R=aseemgarg@chromium.org
Review-Url: https://codereview.chromium.org/2109533002
Cr-Commit-Position: refs/heads/master@{#37349}
When re-scoping arrow function parameter initializers, temporaries
should be moved from the closure of the old scope to the closure of
the new scope, if necessary.
R=adamk@chromium.org, rossberg@chromium.org
BUG=chromium:622663
LOG=N
Review-Url: https://codereview.chromium.org/2083083007
Cr-Commit-Position: refs/heads/master@{#37335}
This adds a missing lazy bailout point when defining data properties
with computed property names in object literals. The runtime call to
Runtime::kDefineDataPropertyInLiteral can trigger deopts. The necessary
bailout ID already exists and is now properly used.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-621816
BUG=chromium:621816
Review-Url: https://codereview.chromium.org/2099133003
Cr-Commit-Position: refs/heads/master@{#37294}
While we properly handled scopes of initializers in destructured parameters,
we never did the right thing for computed properties. This patch fixes that
by factoring out PatternRewriter's scope rewriting logic and calls it
for the computed property case.
BUG=chromium:620119
Review-Url: https://codereview.chromium.org/2084103002
Cr-Commit-Position: refs/heads/master@{#37228}
Reason for revert:
Infra issue appears to be over
TBR=adamk@chromium.org
Original issue's description:
> Revert of Rewrite scopes of non-simple default arguments (patchset #5 id:80001 of https://codereview.chromium.org/2077283004/ )
>
> Reason for revert:
> Seems to close tree (but it could be an infra issue)
>
> Original issue's description:
> > Rewrite scopes of non-simple default arguments
> >
> > Default parameters have additional declaration block scopes inserted
> > around them when something in the function scope calls eval. This
> > patch sets the parent scope of the expressions introduced due to
> > those defaults to the new block scope.
> >
> > R=adamk
> > BUG=chromium:616386
> >
> > Committed: https://crrev.com/0e14baf712955a1993f742647bb2adc293702b80
> > Cr-Commit-Position: refs/heads/master@{#37198}
>
> TBR=adamk@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:616386
>
> Committed: https://crrev.com/dd50262933d2ac087da32be887a7c18385fd998e
> Cr-Commit-Position: refs/heads/master@{#37201}
TBR=adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:616386
Review-Url: https://codereview.chromium.org/2086353003
Cr-Commit-Position: refs/heads/master@{#37202}
Reason for revert:
Seems to close tree (but it could be an infra issue)
Original issue's description:
> Rewrite scopes of non-simple default arguments
>
> Default parameters have additional declaration block scopes inserted
> around them when something in the function scope calls eval. This
> patch sets the parent scope of the expressions introduced due to
> those defaults to the new block scope.
>
> R=adamk
> BUG=chromium:616386
>
> Committed: https://crrev.com/0e14baf712955a1993f742647bb2adc293702b80
> Cr-Commit-Position: refs/heads/master@{#37198}
TBR=adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:616386
Review-Url: https://codereview.chromium.org/2081323006
Cr-Commit-Position: refs/heads/master@{#37201}
Default parameters have additional declaration block scopes inserted
around them when something in the function scope calls eval. This
patch sets the parent scope of the expressions introduced due to
those defaults to the new block scope.
R=adamk
BUG=chromium:616386
Review-Url: https://codereview.chromium.org/2077283004
Cr-Commit-Position: refs/heads/master@{#37198}
Failing to do the right check in AdvancePage results in a crash in a CHECK later
in EnsureCurrentCapacity.
BUG=chromium:620750,chromium:622115
LOG=N
R=jochen@chromium.org
Review-Url: https://codereview.chromium.org/2090013002
Cr-Commit-Position: refs/heads/master@{#37171}
Reland of https://codereview.chromium.org/2048703002/
Code like `let a; eval("var a;");` should throw a SyntaxError, not a TypeError
(this caused a test262 failure.). However, the code `eval("function NaN() {}");`
should actually throw a TypeError. This patch changes most cases of
redeclaration errors from TypeError to SyntaxError. See the test
mjsunit/regress/redeclaration-error-types for a thorough analysis with spec
references.
The relevant sections of the spec are ES#sec-globaldeclarationinstantiation and
ES#sec-evaldeclarationinstantiation
BUG=v8:4955
LOG=y
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
R=adamk
Review-Url: https://codereview.chromium.org/2086063002
Cr-Commit-Position: refs/heads/master@{#37156}
We need to trim the graph before we execute the MemoryOptimizer, because
that just walks the effect chain from Start to End and cannot deal with
dead nodes in the use lists.
R=jarin@chromium.org
BUG=chromium:614292
Review-Url: https://codereview.chromium.org/2080703003
Cr-Commit-Position: refs/heads/master@{#37133}
While the EcmaScript specification doesn't define precise values for the
Math constants or the Math functions, we should at least ensure that the
values of the constants and the functions agree, i.e. Math.E should be
exactly the same value as Math.exp(1).
Also make sure that Math.exp(1) returns the expected value; we should
revisit the fdlibm algorithm and figure out why it's wrong in the last
bit.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:626111,v8:3266,v8:3468,v8:3493,v8:5086,v8:5108
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2079233005
Cr-Commit-Position: refs/heads/master@{#37128}
This adds a new BUILTIN frame type, which supports variable number of
arguments for builtins implemented in hand-written native code (we will
extend this mechanism to TurboFan builtins at some point). Convert the
Math.max and Math.min builtins to construct a BUILTIN frame if required.
This does not yet work for C++ builtins, but that'll be the next step.
R=bmeurer@chromium.org, jarin@chromium.org
BUG=v8:4815
LOG=n
Review-Url: https://codereview.chromium.org/2069423002
Cr-Commit-Position: refs/heads/master@{#37051}
This makes sure exception reporting done by the debug shell behaves
gracefully even near the stack limit. When line number determination
fails we just fallback to not printing source information.
R=yangguo@chromium.org
TEST=mjsunit/regress/regress-crbug-620253
BUG=chromium:620253
Review-Url: https://codereview.chromium.org/2069543007
Cr-Commit-Position: refs/heads/master@{#37031}
Reason for revert:
As discussed offline with Toon, this is not the correct fix here.
Original issue's description:
> [turbofan] Properly handle dictionary maps in the prototype chain.
>
> Dictionary prototypes don't have stable maps, but still don't matter for
> element access. Generalized the JSNativeContextSpecialization a bit to
> handle everything that Crankshaft can handle in this regard.
>
> R=jarin@chromium.org
> BUG=chromium:616709
>
> Committed: https://crrev.com/1c7bdc7f6f4d9512f4982590bd949f265ee9c8c3
> Cr-Commit-Position: refs/heads/master@{#37019}
TBR=jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:616709
Review-Url: https://codereview.chromium.org/2076493002
Cr-Commit-Position: refs/heads/master@{#37029}
Dictionary prototypes don't have stable maps, but still don't matter for
element access. Generalized the JSNativeContextSpecialization a bit to
handle everything that Crankshaft can handle in this regard.
R=jarin@chromium.org
BUG=chromium:616709
Review-Url: https://codereview.chromium.org/2067423003
Cr-Commit-Position: refs/heads/master@{#37019}
This is to make sure the test in question does not run out of stack
space during bootstrapping on any configuration. Our fuzzers take the
test an run it against a broad spectrum of configuration. The new size
of 100 is used throughout our test suite as "the smallest" stack size.
R=jkummerow@chromium.org
TEST=mjsunit/regress/regress-1132
BUG=chromium:619744
Review-Url: https://codereview.chromium.org/2068993002
Cr-Commit-Position: refs/heads/master@{#36995}
Reason for revert:
This is going to break the LayoutTest inspector-protocol/console/console-let-const-with-api.html as seen in https://build.chromium.org/p/tryserver.v8/builders/v8_linux_blink_rel/builds/2247 . Please run this test manually, using instructions at https://www.chromium.org/developers/testing/webkit-layout-tests , and fix on the Chrome side if needed before resubmitting this patch.
Original issue's description:
> change most cases of variable redeclaration from TypeError to SyntaxError.
>
> Code like `let a; eval("var a;");` should throw a SyntaxError, not a TypeError
> (this caused a test262 failure.). However, the code `eval("function NaN() {}");`
> should actually throw a TypeError. This patch changes most cases of
> redeclaration errors from TypeError to SyntaxError. See the test
> mjsunit/regress/redeclaration-error-types for a thorough analysis with spec
> references.
>
> The relevant sections of the spec are ES#sec-globaldeclarationinstantiation and
> ES#sec-evaldeclarationinstantiation
>
> BUG=v8:4955
> LOG=y
>
> Committed: https://crrev.com/2b787561763d0f7e8dab698652715a742cf78291
> Cr-Commit-Position: refs/heads/master@{#36940}
TBR=adamk@chromium.org,jwolfe@igalia.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4955
Review-Url: https://codereview.chromium.org/2064793002
Cr-Commit-Position: refs/heads/master@{#36941}
Code like `let a; eval("var a;");` should throw a SyntaxError, not a TypeError
(this caused a test262 failure.). However, the code `eval("function NaN() {}");`
should actually throw a TypeError. This patch changes most cases of
redeclaration errors from TypeError to SyntaxError. See the test
mjsunit/regress/redeclaration-error-types for a thorough analysis with spec
references.
The relevant sections of the spec are ES#sec-globaldeclarationinstantiation and
ES#sec-evaldeclarationinstantiation
BUG=v8:4955
LOG=y
Review-Url: https://codereview.chromium.org/2048703002
Cr-Commit-Position: refs/heads/master@{#36940}
This fixes FastNewStrictArgumentsStub and FastNewRestParameterStub to no
longer assume that the strict arguments object being allocated will fit
into new-space. The case where said object needs to move to large object
space is now handled in the runtime.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-614727
BUG=chromium:614727
Review-Url: https://codereview.chromium.org/2054853002
Cr-Commit-Position: refs/heads/master@{#36917}
Only look at the --ignition-generators flag when determining whether to use
Ignition (in compiler.cc). In generator runtime functions, instead of looking
at the flag, determine the generator kind based on whether the generator has a
bytecode array. This allows compiling some generator function using
full-codegen and others using Ignition, e.g when using --ignition-filter.
R=mstarzinger@chromium.org
BUG=chromium:618657,v8:4907
Review-Url: https://codereview.chromium.org/2052873002
Cr-Commit-Position: refs/heads/master@{#36864}
This removes explicit uses of the RUNTIME_ASSERT macro from some runtime
methods. The implicit ones in CONVERT_FOO_ARG_CHECKED will be addressed
in a separate CL for all runtime modules at once.
R=bmeurer@chromium.org
BUG=v8:5066
Review-Url: https://codereview.chromium.org/2045193002
Cr-Commit-Position: refs/heads/master@{#36852}
When walking up the prototype chain during OrdinaryHasInstance, we first
check if the current prototype equals the expected one, and only
afterwards check the current prototype against null. That's obviously
wrong if we check something like Proxy, whose prototype is null.
R=yangguo@chromium.org
BUG=v8:5085
Review-Url: https://codereview.chromium.org/2041103007
Cr-Commit-Position: refs/heads/master@{#36840}
Adding properties to prototypes is faster when we don't force their
maps into fast mode yet. Once a prototype shows up in the IC system,
its setup phase is likely over, and it makes sense to transition it
to fast properties.
This patch speeds up the microbenchmark in the bug by 20x.
Octane-Typescript sees a 3% improvement.
BUG=chromium:607010
Review-Url: https://codereview.chromium.org/2036493006
Cr-Commit-Position: refs/heads/master@{#36828}
This removes explicit uses of the RUNTIME_ASSERT macro from some runtime
methods. The implicit ones in CONVERT_FOO_ARG_CHECKED will be addressed
in a separate CL for all runtime modules at once.
R=verwaest@chromium.org
BUG=v8:5066
Review-Url: https://codereview.chromium.org/2041353003
Cr-Commit-Position: refs/heads/master@{#36815}
This makes sure {NodeProperties::FindFrameStateBefore} can deal with
effect chains that are marked as dead. This can happen when reducers
looking for frame states run together with other reducers killing some
execution paths within the same reduction phase.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-617567
BUG=chromium:617567,chromium:617224
Review-Url: https://codereview.chromium.org/2041833002
Cr-Commit-Position: refs/heads/master@{#36743}
Introduce a dedicated Float64Log machine operator, that is either
implemented by a direct C call or by platform specific code, i.e.
using the FPU on x64 and ia32.
This operator is used to implement Math.log as a proper TurboFan
builtin on top of the CodeStubAssembler.
Also introduce a NumberLog simplified operator on top of Float64Log
and use that for the fast inline path of Math.log inside TurboFan
optimized code.
BUG=v8:5065
Review-Url: https://codereview.chromium.org/2029413005
Cr-Commit-Position: refs/heads/master@{#36703}
This CL also updates the elements kind transition lookup logic:
1) First we go back to the root map,
2) Follow elements kind transitions,
3) Replay the property transitions.
BUG=v8:5009
LOG=Y
TBR=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2015513002
Cr-Commit-Position: refs/heads/master@{#36652}
Reason for revert:
Triggers crashes on the deopt fuzzer:
https://build.chromium.org/p/client.v8/builders/V8%20Deopt%20Fuzzer/builds/10608
Repro:
out/Release/d8 --test --random-seed=849179141 --deopt-every-n-times 149 --nohard-abort --nodead-code-elimination --nofold-constants --noconcurrent-recompilation test/webkit/resources/standalone-pre.js test/webkit/dfg-arguments-mixed-alias.js test/webkit/resources/standalone-post.js
Original issue's description:
> [crankshaft] Only exclude explicit 'arguments' (and 'this') from liveness analysis.
>
> Currently, we do not emit EnvironmentMarkers if the hydrogen value
> in the environment is arguments object. As the hydrogen value can change
> for local variables, we emit only some environment markers. That can
> cause environment liveness analysis to mark part of live range as live
> and part as dead. The zapping phase then only inserts zaps in
> live->dead transitions, potentially zapping a live value.
>
> With this CL, we only emit EnvironmentMarkers for 'this' and
> 'arguments' local variables, disregarding the hydrogen value.
>
> BUG=chromium:612146
> LOG=n
>
> Committed: https://crrev.com/1428fbe224dc2df0cb6f59e4959430f7aa614064
> Cr-Commit-Position: refs/heads/master@{#36641}
TBR=jkummerow@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:612146
Review-Url: https://codereview.chromium.org/2029563002
Cr-Commit-Position: refs/heads/master@{#36644}
Currently, we do not emit EnvironmentMarkers if the hydrogen value
in the environment is arguments object. As the hydrogen value can change
for local variables, we emit only some environment markers. That can
cause environment liveness analysis to mark part of live range as live
and part as dead. The zapping phase then only inserts zaps in
live->dead transitions, potentially zapping a live value.
With this CL, we only emit EnvironmentMarkers for 'this' and
'arguments' local variables, disregarding the hydrogen value.
BUG=chromium:612146
LOG=n
Review-Url: https://codereview.chromium.org/2026173003
Cr-Commit-Position: refs/heads/master@{#36641}
When we moved the String.fromCharCode builtin to C++, we slightly
regressed the fast single character code argument case. Recovered some
of the performance by implementing the builtin using the TurboFan
CodeStubAssembler.
Drive-by-fix: Make sure the stack trace from the implicit ToNumber
conversion in String.fromCharCode includes the builtin by adding a
regression test for that.
R=yangguo@chromium.org
BUG=chromium:609831,chromium:613947,v8:5049
Review-Url: https://codereview.chromium.org/2021143003
Cr-Commit-Position: refs/heads/master@{#36611}
Rewrite decodeURI and decodeURIComponent as builtin functions
and install them in the bootstrapper.
Delete unused runtime functions:
- TruncateString
- NewString
- OneByteSeqStringGetChar
- OneByteSeqStringSetChar
- TwoByteSeqStringGetChar
- TwoByteSeqStringSetChar
Add regression test for decoding large strings. Clusterfuzz detected
a problem with %TruncateString, see
https://bugs.chromium.org/p/chromium/issues/detail?id=612109#c6
This is automatically fixed by this rewrite because %TruncateString
is deleted anyways.
Crude benchmark on 585 decodeURI and decodeURIComponent tests
averaged over five runs:
* builtin functions
real 0m9.69s
user 2m39.8816s
sys 0m12.6398s
* JS functions calling into the runtime e.g., for %TruncateString
real 0m11.0598s
user 3m6.7026s
sys 0m13.5756s
By running:
$ time tools/run-tests.py --arch=x64 --mode=Release --buildbot
test262/built-ins/decodeURI* mjsunit/uri
>>> Running tests for x64.Release
BUG=v8:4912, chromium:612109
R=yangguo@chromium.org, bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/1994733003
Cr-Commit-Position: refs/heads/master@{#36543}
Removes the DONT_DELETE enum bit from the properties to make them
configurable.
Also, updates the regress-typedarray-length test to --
- Check for true boolean return value on deletion of these
properties.
- Check for undefined return value on trying to access these
properties after deletion.
BUG=v8:4902
LOG=Y
Review-Url: https://codereview.chromium.org/2001393004
Cr-Commit-Position: refs/heads/master@{#36528}
This makes sure the deoptimizer can materialize sloppy arguments objects
with the FAST_SLOPPY_ARGUMENTS_ELEMENTS elements kind. TurboFan's escape
analysis treates those as normal JSObject types and hence materializes
them differently than Crankshaft does.
R=verwaest@chromium.org
TEST=mjsunit/regress/regress-crbug-613919
BUG=chromium:613919
Review-Url: https://codereview.chromium.org/2001133002
Cr-Commit-Position: refs/heads/master@{#36440}
This makes escape analysis skip analyzing the code entry field within
JSFunction objects. Said field is an untagged pointer field and hence
cannot be tracked by an ObjectState node.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-613494
BUG=chromium:613494
Review-Url: https://codereview.chromium.org/1997353002
Cr-Commit-Position: refs/heads/master@{#36436}
The previous JavaScript version created way too many ConsStrings for
longer strings, i.e. when using String.fromCharCode together with
Function.prototype.apply and arrays of char codes.
This version now always allocates sequential strings and therefore uses
way less memory when turning longer character sequences into strings,
and therefore fixes the memory regression on Google Maps.
BUG=chromium:609831
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2004733002
Cr-Commit-Position: refs/heads/master@{#36427}
In VisitArrayLiteral(), we stopped creating boilerplates during
compilation. This created a bug, because we'd emit an HStoreKeyed with an
ElementsKind based on the initial elements kind of the boilerplate. Since
boilerplates may transition as part of elements transition feedback, this can
lead to incorrect values (storing a smi in a double array).
BUG=chromium:606021
Review-Url: https://codereview.chromium.org/2000673002
Cr-Commit-Position: refs/heads/master@{#36408}
In ES2015, the "byteLength" and "byteOffset" properties of DataViews are
getters on the prototype, so the previously-used strategy of special-casing
them using only the receiver map is invalid.
A future CL will need to use the same strategy which will be taken for
TypedArray "length", "byteLength", and "byteOffset": adding a prototype
chain check.
BUG=v8:5018, chromium:593634
Review-Url: https://codereview.chromium.org/1984043002
Cr-Commit-Position: refs/heads/master@{#36382}
This promotes the escape analysis from an experimental feature to be a
fully supported feature. The main goal is to unleach ClusterFuzz on the
implementation so that we can stabilize it.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/1989833002
Cr-Commit-Position: refs/heads/master@{#36324}
These guards are useless anyways once you make it throw the
effect/control linearizer because all memory operations and
calls are connected to the control and/or effect chain anyways
afterwards.
Drive-by-fix: Fail in the InstructionSelector if we ever see
a Guard node.
R=jarin@chromium.org
BUG=chromium:612142
Review-Url: https://codereview.chromium.org/1980383002
Cr-Commit-Position: refs/heads/master@{#36302}
This makes escape analysis treat all guard nodes in the graph as an
escaping use. We eventually want to properly handle guard nodes, this
just serves as a temporary workaround to get things going.
R=bmeurer@chromium.org
BUG=v8:602595
LOG=n
Review-Url: https://codereview.chromium.org/1972323004
Cr-Commit-Position: refs/heads/master@{#36286}
This reverts commit 41d571dfe8.
Reason for revert: This patch breaks the correctness of the typedarray
properties such as length, byteOffset, byteLength.
The accessor check optimization code is dead code eliminated. A follow
up patch will fix this optimization correctly.
BUG=chromium:593634
Review-Url: https://codereview.chromium.org/1977983002
Cr-Commit-Position: refs/heads/master@{#36254}
We eagerly inserted Int32Mul for Math.imul during builtin lowering and
messed up with the types, which confused the representation selection.
This adds a proper NumberImul operator, and fixes the builtin reducer to
do the right thing according to the spec.
R=mstarzinger@chromium.org
BUG=v8:5006
LOG=n
Review-Url: https://codereview.chromium.org/1971163002
Cr-Commit-Position: refs/heads/master@{#36219}
The bailout points for named and keyed property loads when doing super
property calls are not being prepared by full-codegen, even though we
are using them in TurboFan for deopts and stack traces.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-4971
BUG=v8:4971
LOG=n
Review-Url: https://codereview.chromium.org/1960083002
Cr-Commit-Position: refs/heads/master@{#36109}
The flag in question used to fall-back to Crankshaft whenever an OSR
request couldn't be handled by TurboFan. By now OSR in TurboFan is
sufficiently stabilized that one single --use-osr flag should do it.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/1960043002
Cr-Commit-Position: refs/heads/master@{#36102}
Scope analysis is over-conservative when treating variable resolutions
as possibly-shadowed by a sloppy eval. In the attached bug, this comes
into play since catch scopes have different behavior with respect to
the "calls eval" in eager vs lazy compilation (in the latter, they
are never marked as "calls eval" because CatchContexts don't have
an associated ScopeInfo).
This patch changes the scope-type check to also eliminate a few other
cases where shadowing isn't possible, such as non-declaration block scopes.
BUG=chromium:608279
LOG=n
Review-Url: https://codereview.chromium.org/1950803002
Cr-Commit-Position: refs/heads/master@{#36046}
The inline allocation sequence in the optimizing compilers cannot deal
well with funky types like JSRegExp, which have some magic fields in
addition to the inobject properties. In Crankshaft we already use the
FastNewObjectStub for %_NewObject in general, so fix TurboFan to the same.
Hopefully one day we can kill %_NewObject completely.
R=jarin@chromium.org
BUG=chromium:609029
LOG=n
Review-Url: https://codereview.chromium.org/1943403004
Cr-Commit-Position: refs/heads/master@{#36006}
Compiler backends get their language mode from the current
function, but should instead be deriving it from the current scope.
This allows proper handling of the always-strictness of class declarations
and expressions, and in particular the treatment of 'eval' calls in an
extends clause as a strict eval.
Also fix the parser's RecordEvalCall logic to only reach out to the
DeclarationScope in sloppy mode, which fixes the strange case of a
sloppy function thinking it contains a sloppy eval when in fact
it contains only a strict eval.
BUG=v8:4970
LOG=n
Review-Url: https://codereview.chromium.org/1931003003
Cr-Commit-Position: refs/heads/master@{#36001}
The ECMA 402 implementation previously pushed directly to real
Arrays, which risks having observably incorrect behavior in the
presence of monkey patching. This patch uses InternalArrays instead
to avoid that hazard.
R=jshin@chromium.org,yangguo@chromium.org
BUG=chromium:604299
LOG=N
Review-Url: https://codereview.chromium.org/1923803002
Cr-Commit-Position: refs/heads/master@{#35949}
Reason for revert:
[Sheriff] Looks like this breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/6442
Original issue's description:
> Remove more dead code after Object.observe removal
>
> This moves __{define,lookup}{Getter,Setter}__ to builtins.cc to free up the JavaScript implementation of DefineOwnProperty for deletion.
TBR=verwaest@chromium.org,jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/1929293002
Cr-Commit-Position: refs/heads/master@{#35886}
These checks ensure that a TypeError is thrown, per spec, rather than
a runtime assert failure.
BUG=v8:4964
R=adamk
LOG=Y
Review-Url: https://codereview.chromium.org/1929123002
Cr-Commit-Position: refs/heads/master@{#35885}
This moves __{define,lookup}{Getter,Setter}__ to builtins.cc to free up the JavaScript implementation of DefineOwnProperty for deletion.
Review-Url: https://codereview.chromium.org/1904313004
Cr-Commit-Position: refs/heads/master@{#35876}
Between the miss and patching, we run user code. That may already patch the same code. IC refactoring broke this (again), so including a regression test this time around.
BUG=chromium:601392
LOG=n
Review URL: https://codereview.chromium.org/1925583002
Cr-Commit-Position: refs/heads/master@{#35811}
If the target is deprecated, the object will be updated on first store. If the source for that store equals the target, this will invalidate the cached representation of the source. Preventively upgrade the target.
BUG=chromium:604300
LOG=n
Review URL: https://codereview.chromium.org/1905933002
Cr-Commit-Position: refs/heads/master@{#35770}
Fixes a mistake made in r35618 for register OperandSize calculations.
BUG=605470
LOG=N
Review URL: https://codereview.chromium.org/1908033002
Cr-Commit-Position: refs/heads/master@{#35719}
This is a follow-up to 58429beb7b
"Fix KeyedStore stub selection for STRING_WRAPPER_ELEMENTS".
BUG=chromium:602184
LOG=n
Review URL: https://codereview.chromium.org/1912443004
Cr-Commit-Position: refs/heads/master@{#35715}
The feature was deprecated in M49 and flagged off in M50.
This patch removes it entirely from the codebase.
Review URL: https://codereview.chromium.org/1909433003
Cr-Commit-Position: refs/heads/master@{#35714}
Non-vectorized KeyedLoadICs used to remember whether they had seen Names
as keys; Crankshaft uses this information to avoid emitting elements
accesses which would always deopt. This CL restores that functionality
for vector ICs.
BUG=chromium:594183
LOG=y
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1912593002
Cr-Commit-Position: refs/heads/master@{#35706}
Our previous over-conservative answer caused us to emit hole checks in
full-codegen when eagerly parsing but not when lazily parsing.
With this patch, we use the positions of the BinaryOperations making up
the parameter list (which are the positions of the commas) to determine
the appropriate "end position" for each parameter's initializer. This means
that we get accurate-enough positions for the initializers in the eager
parsing step to get the same answers for hole-check-elimination that we
will later during ParseLazy.
In the included test case, for example:
(function() { ((s = 17, y = s) => s)(); } )();
^2 ^1
The old code would generate a hole check when trying to load
|s| for assignment to |y| (because it treated the closing parentheses
pointed to by "^1" as the "initialization position" of |s|).
The new code uses the comma pointed to by "^2" as the initialization
position of |s|. Since that occurs textually before the load of |s|,
full-codegen knows it can avoid the hole check.
BUG=v8:4908
LOG=n
Review URL: https://codereview.chromium.org/1900343002
Cr-Commit-Position: refs/heads/master@{#35678}
Also factor out test cases from test-run-machops.cc into test-run-load-store.cc
BUG=chromium:599717
LOG=Y
Review URL: https://codereview.chromium.org/1858323003
Cr-Commit-Position: refs/heads/master@{#35651}
Add support to optimize certain comparisons of typeof with known
strings to utilize the existing ObjectIs<Type> predicates. Also
add a new ObjectIsCallable, which is used to optimize the common
typeof x === "function" pattern.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1898653003
Cr-Commit-Position: refs/heads/master@{#35562}
Reason for revert:
Did not fail on another roll including this CL ..
Original issue's description:
> Revert of [compiler] Make feedback vector cope with flag changes. (patchset #1 id:1 of https://codereview.chromium.org/1869693003/ )
>
> Reason for revert:
> Blocks current roll: https://codereview.chromium.org/1876713002/ according to bisect: https://codereview.chromium.org/1872353002/#ps80001
>
> Original issue's description:
> > [compiler] Make feedback vector cope with flag changes.
> >
> > This fixes corner cases where the layout of feedback vectors baked into
> > the snapshot is different from the expected layout, depending on some
> > runtime flags. We make sure the feedback vector is regenereated for
> > functions that are not compiled. Flag changes of this kind are only
> > allowed when code is not serialized.
> >
> > An alternative solution would be to not serialize the feedback vector
> > for such cases in the first place. That solution however would have a
> > higher overhead, as it would required the serializer to be able to
> > recognize feedback vectors while generating a snapshot.
> >
> > R=mvstanton@chromium.org
> > TEST=mjsunit/regress/regress-crbug-600995
> > BUG=chromium:600995
> > LOG=n
> >
> > Committed: https://crrev.com/460bff5fb6af2bd79e610f89afdf6da9dba3cf0c
> > Cr-Commit-Position: refs/heads/master@{#35339}
>
> TBR=mvstanton@chromium.org,mstarzinger@chromium.org
>
> BUG=chromium:600995
> LOG=N
> NOTRY=true
>
> Committed: https://crrev.com/78049e9c4837f053575d6c71e53ae12fec99f1aa
> Cr-Commit-Position: refs/heads/master@{#35392}
TBR=mvstanton@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:600995
Review URL: https://codereview.chromium.org/1876973002
Cr-Commit-Position: refs/heads/master@{#35398}
Reason for revert:
Blocks current roll: https://codereview.chromium.org/1876713002/ according to bisect: https://codereview.chromium.org/1872353002/#ps80001
Original issue's description:
> [compiler] Make feedback vector cope with flag changes.
>
> This fixes corner cases where the layout of feedback vectors baked into
> the snapshot is different from the expected layout, depending on some
> runtime flags. We make sure the feedback vector is regenereated for
> functions that are not compiled. Flag changes of this kind are only
> allowed when code is not serialized.
>
> An alternative solution would be to not serialize the feedback vector
> for such cases in the first place. That solution however would have a
> higher overhead, as it would required the serializer to be able to
> recognize feedback vectors while generating a snapshot.
>
> R=mvstanton@chromium.org
> TEST=mjsunit/regress/regress-crbug-600995
> BUG=chromium:600995
> LOG=n
>
> Committed: https://crrev.com/460bff5fb6af2bd79e610f89afdf6da9dba3cf0c
> Cr-Commit-Position: refs/heads/master@{#35339}
TBR=mvstanton@chromium.org,mstarzinger@chromium.org
BUG=chromium:600995
LOG=N
NOTRY=true
Review URL: https://codereview.chromium.org/1876103002
Cr-Commit-Position: refs/heads/master@{#35392}
Function bindings are the only variables in LEGACY_CONST mode.
(https://codereview.chromium.org/1819123002/). Since these variables
can also be accessed in strict mode functions we should support
handling such variables. Assigning to a legacy constant throws
a TypeError in strict mode. Also fixes hydrogen.cc to throw a
TypeError for legacy constants.
BUG=v8:4280,chromium:599068
LOG=N
TBR=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1845223006
Cr-Commit-Position: refs/heads/master@{#35383}
This fixes corner cases where the layout of feedback vectors baked into
the snapshot is different from the expected layout, depending on some
runtime flags. We make sure the feedback vector is regenereated for
functions that are not compiled. Flag changes of this kind are only
allowed when code is not serialized.
An alternative solution would be to not serialize the feedback vector
for such cases in the first place. That solution however would have a
higher overhead, as it would required the serializer to be able to
recognize feedback vectors while generating a snapshot.
R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-crbug-600995
BUG=chromium:600995
LOG=n
Review URL: https://codereview.chromium.org/1869693003
Cr-Commit-Position: refs/heads/master@{#35339}
Pushing undefined onto a FAST_DOUBLE_ARRAY does not enforce the right representation checks.
BUG=chromuim:599089
LOG=n
Review URL: https://codereview.chromium.org/1868973002
Cr-Commit-Position: refs/heads/master@{#35332}
We have to preserve control flow so that the liveness analysis is less
confused. This CL fixes loops to preserve teh original control flow.
BUG=chromium:599710
LOG=n
Review URL: https://codereview.chromium.org/1863123002
Cr-Commit-Position: refs/heads/master@{#35318}
Previously, CreateDataProperty would fail a DCHECK when used to create
an integer indexed property on a TypedArray. This patch makes it throw
a TypeError instead. The issue came up when Array.prototype.concat
was repaired to use CreateDataProperty rather than SetElement; concat
can be tricked into making a new TypedArray if it is given an Array
whose prototype is a TypedArray. This patch prevents the issue.
R=adamk
LOG=Y
BUG=chromium:596394
Review URL: https://codereview.chromium.org/1821723004
Cr-Commit-Position: refs/heads/master@{#35271}
In simplified numbering, we make sanity checks based on types (e.g.,
NumberSubtract should take numbers as inputs), but this can be
violated if optimization passes make types less precise.
In this CL, we fix load elimination to make sure that types are
smaller in the store -> load elimination by taking an intersection
of the load's type with the store value's type and inserting a guard
with that type. Note that the load type comes from type feedback, so
it can be disjoint from the stored value type (in that case, this
must be dead code because the map chack for the load should prevent
us from using the stored value).
BUG=chromium:599412
LOG=n
Review URL: https://codereview.chromium.org/1857133003
Cr-Commit-Position: refs/heads/master@{#35259}
This fixes a corner case where the generator function of a suspended
generator has been marked for optimization. We assume the optimization
approach will cause a bailout because generators are not optimized. But
resuming is more resilient by always activating the unoptimized code.
R=neis@chromium.org,bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-513471
BUG=chromium:513471
LOG=n
Review URL: https://codereview.chromium.org/1856683002
Cr-Commit-Position: refs/heads/master@{#35234}
This CL ensures that we build environments/frame states so that tail caller frame will never become topmost.
BUG=chromium:598998, v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1849503002
Cr-Commit-Position: refs/heads/master@{#35188}
The HandlerCompiler did not properly handle the weird edge case when a
sloppy mode function was installed as an accessor on one of the value
wrapper prototypes and then accessed via a load from a primitive value.
In this case we just passed the primitive value untouched instead of
properly wrapping it first. The CallFunction builtin properly deals with
all the funny edge cases, so we use it instead of duplicating almost all
of the logic here (the performance difference is neglible).
R=verwaest@chromium.org
BUG=chromium:599073, v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1845243005
Cr-Commit-Position: refs/heads/master@{#35187}
Fix and re-enable the flexible representation for Math.floor (which is used to
implement Math.ceil) and Math.round, which allows Math.floor and Math.round to
return double results instead of int32, and therefore allows values outside
the int32 range, especially -0 is now a valid result, which doesn't deopt.
Also port this feature to x64 and ia32 when the CPU supports the SSE4.1
extension.
This addresses all the known deoptimization loops related to Math.round
in the Kraken benchmark suite, and seems to also address most of the
deoptimization loops related to Math.floor in the Oort Online benchmark.
Drive-by-fix: Import the regression tests for the broken HMathFloorOfDiv
optimization that caused the initial revert of the feature (for arm64 only
back then).
BUG=chromium:476477,v8:2890,v8:4059
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1841513003
Cr-Commit-Position: refs/heads/master@{#35094}
It's been on since M49. Also moved tests from harmony -> es6,
one of which was merged with another test of the same name.
While moving stuff over to regexp.js, I also noticed that there
were unused calls to %FunctionSetName and %SetNativeFlag (those
calls are already handled by InstallGetter()).
Review URL: https://codereview.chromium.org/1838563003
Cr-Commit-Position: refs/heads/master@{#35076}
A bug in error printing meant that we failed to do proper type checks
before calling into C++ code, which could lead to RUNTIME_ASSERT
failures if methods are called on alternative receivers. This patch
adds the right type checks.
BUG=chromium:596718
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1831053003
Cr-Commit-Position: refs/heads/master@{#35069}
Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
are no more. This lets us remove a bunch of code from many parts of the
codebase.
In this patch, I remove parser support for generating legacy const variables
from const declarations. This also removes the special "illegal declaration"
bit from Scope, which has ripples into all compiler backends.
Also gone are any tests which relied on legacy const declarations.
Note that we do still generate a Variable in mode CONST_LEGACY in one case:
function name bindings in sloppy mode. The likely fix there is to add a new
Variable::Kind for this case and handle it appropriately for stores in each
backend, but I leave that for a later patch to make this one completely
subtractive.
Review URL: https://codereview.chromium.org/1819123002
Cr-Commit-Position: refs/heads/master@{#35002}
Both of them shipped in Chrome 49 without incident.
Also move relevant tests from harmony/ to es6/.
Review URL: https://codereview.chromium.org/1815773002
Cr-Commit-Position: refs/heads/master@{#34964}
This is necessary to ensure that "Called non callable" exception will get a proper message and stack trace even for calls at tail position.
BUG=chromium:595615, v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1818003002
Cr-Commit-Position: refs/heads/master@{#34962}
Previously only JSFunctions seemed to be valid for toJSON, which doesn't
match the ES6 specification that allows any object with [[Call]]
internal method (i.e. any Callable in V8 terminology), including bound
functions and proxies.
BUG=chromium:595738, chromium:535408
R=yangguo@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1824533002
Cr-Commit-Position: refs/heads/master@{#34913}
This patch fixes two bugs in Array.prototype.concat in conjunction with
subclassing Arrays:
- Create a new property rather than calling Set when adding elements to
the output array. This means setters are not called.
- If there is an exception thrown from DefineProperty, propagate it
outwards properly, rather than swallowing it. This can occur, e.g., with
a Proxy as the new output array.
R=adamk
LOG=Y
BUG=chromium:595319
Review URL: https://codereview.chromium.org/1814933002
Cr-Commit-Position: refs/heads/master@{#34876}
Repair this to match what the runtime correctly does, by first checking if the
function is a constructor before we access the prototype.
R=verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1810953002
Cr-Commit-Position: refs/heads/master@{#34863}
Function declarations were previously permitted by V8 in many locations
which no ECMAScript specification allowed; the ECMAScript 2015 spec
enumerates a few locations (in blocks, as well as after labels and in
conditionals when in sloppy mode). This patch ships the flag to restrict
the usage of function declarations to those contexts.
R=adamk
LOG=Y
BUG=v8:4824
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1799233003
Cr-Commit-Position: refs/heads/master@{#34828}
The monomorphic case already carefully ensures that we don't try to use
a regular elements load stub on string wrapper elements. The polymorphic
path must perform an equivalent check.
BUG=chromium:594955
LOG=n
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1806543002
Cr-Commit-Position: refs/heads/master@{#34807}
This part of Scope has existed since V8's initial check in, but from what
I can tell it's not required to implement "with". The only tests that
depend upon it are tests of the debugger and the Scope mirrors, but the
resulting test behavior after removing the bit still seems perfectly
reasonable to me. In fact, with the included fix for scope name collection,
the scope mirror is actually improved with this change.
As a bi-product, this fixes the attached bug, about the contains_with
bit having inconsistent values in some arrow function compilation
scenarios.
BUG=chromium:592353
LOG=n
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1804783002
Cr-Commit-Position: refs/heads/master@{#34802}
Array.prototype.concat did not work correct with complex elements on the
receiver or the prototype chain.
BUG=chromium:594574
LOG=y
Review URL: https://codereview.chromium.org/1804963002
Cr-Commit-Position: refs/heads/master@{#34798}
These flags have been on by default since version 4.9, which has been
in stable Chrome for over a week now, demonstrating that they're
here to stay.
Also moved the tests out of harmony/ and into es6/.
Review URL: https://codereview.chromium.org/1776683003
Cr-Commit-Position: refs/heads/master@{#34692}
When an Array subclass is used as the receiver for concat, or with
certain usages of @@species, the output that's constructed is of
a different type with new slow path logic. This slow path still
made references to elements, so it's important that bounds checking
for a too-long result still be done. This patch repairs that bounds
checking.
R=cbruni
LOG=Y
BUG=chromium:592340
Review URL: https://codereview.chromium.org/1782443002
Cr-Commit-Position: refs/heads/master@{#34636}
Reading the registers' values back from the FrameDescription
should use the same offset computation as storing them into it.
The offsets must also match what the deoptimizer expects, which
is rx at offset rx.code() * kDoubleSize, even if some registers
are not saved (leaving gaps).
BUG=v8:4800
LOG=n
R=danno@chromium.org
Review URL: https://codereview.chromium.org/1769833006
Cr-Commit-Position: refs/heads/master@{#34633}
The CharacterRange constructor checks the input for validity. However,
CharacterRange::Singleton also uses the constructor and may have
kEndMarker as input, causing the check to fail.
The solution is to move the check to CharacterRange::Range and
consistently use it across the code base.
R=jkummerow@chromium.org
BUG=chromium:593282
LOG=N
Review URL: https://codereview.chromium.org/1776013003
Cr-Commit-Position: refs/heads/master@{#34626}
After fixing the memory barrier for maps (https://codereview.chromium.org/1714513003), we are using a temp register for the map case. The temp register should not be aliased with the stored value (otherwise we perform the mem barrier check with a wrong value). This CL makes sure it is not aliased.
BUG=chromium:590074
LOG=n
Review URL: https://codereview.chromium.org/1775083002
Cr-Commit-Position: refs/heads/master@{#34607}
We cannot optimize away ToNumber conversions based on the Type that we
see in Crankshaft, as this might be the (unchecked or even pretruncated)
lower bound. We can only use the HType, which is based on the definition.
R=jkummerow@chromium.org
BUG=chromium:590989
LOG=n
Review URL: https://codereview.chromium.org/1757013002
Cr-Commit-Position: refs/heads/master@{#34445}
We used to emit debug break location on block entry. This cannot be
ported to the interpreted as we do not emit bytecode for block entry.
This made no sense to begin with though, but accidentally added
break locations for var declarations.
With this change, the debugger no longer breaks at var declarations
without initialization. This is in accordance with the fact that the
interpreter does not emit bytecode for uninitialized var declarations.
Also fix the bytecode to match full-codegen's behavior wrt return
positions:
- there is a break location before the return statement, with the source
position of the return statement.
- right before the actual return, there is another break location. The
source position points to the end of the function.
R=rmcilroy@chromium.org, vogelheim@chromium.orgTBR=rossberg@chromium.org
BUG=v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1744123003
Cr-Commit-Position: refs/heads/master@{#34388}
The CompareICStub produces an untagged raw word value, which has to be
translated to true or false manually in the TurboFan code. But for lazy
bailout after the CompareIC, we immediately go back to fullcodegen or
Ignition with the raw value, to a location where both fullcodegen and
Ignition expect a boolean value, which might crash or in the worst case
(depending on the exact computation inside the CompareIC) could lead to
arbitrary memory access.
Short-term fix is to use the proper runtime functions (unified with the
interpreter now) for comparisons. Next task is to provide optimized
versions of these based on the CodeStubAssembler, which can then be used
via code stubs in TurboFan or directly in handlers in the interpreter.
R=mstarzinger@chromium.org
BUG=v8:4788
LOG=n
Review URL: https://codereview.chromium.org/1738153002
Cr-Commit-Position: refs/heads/master@{#34335}
The LoadBuffer operator that is used for asm.js heap access claims to
return only the appropriate typed array type, but out of bounds access
could make it return undefined. So far we tried to "repair" the graph
later if we see that our assumption was wrong, and for various reasons
that worked for some time. But now that wrong type information that is
propagated earlier is picked up appropriately and thus we generate wrong
code, i.e. we in the repro case we feed NaN into ChangeFloat64Uint32 and
thus get 2147483648 instead of 0 (with proper JS truncation).
This was always considered a temporary hack until we have a proper
asm.js pipeline, but since we still run asm.js through the generic
JavaScript pipeline, we have to address this now. Quickfix is to just
bailout from the pipeline when we see that the LoadBuffer type was
wrong, i.e. the result of LoadBuffer is not properly truncated and thus
undefined or NaN would be observable.
R=mstarzinger@chromium.org, jarin@chromium.org
BUG=chromium:589792
LOG=y
Review URL: https://codereview.chromium.org/1740123002
Cr-Commit-Position: refs/heads/master@{#34322}
This fixes a corner case that triggered an assert in full-codegens
operand stack depth tracking. We stop pushing operands if we overflow
the C-stack while iterating the AST. This makes the tracking go out of
sync before we fully returned from the tree traversal, at which point
the thrown RangeError will abort compilation.
R=ishell@chromium.org
TEST=mjsunit/regress/regress-crbug-589472
BUG=chromium:589472
LOG=n
Review URL: https://codereview.chromium.org/1732903002
Cr-Commit-Position: refs/heads/master@{#34255}
The Crankshaft fast case for String.fromCharCode() unconditionally
deoptimizes on all non-int32 inputs, even tho it would be perfectly
valid to just truncate the index to an int32.
R=ishell@chromium.org
BUG=chromium:587068
LOG=n
Review URL: https://codereview.chromium.org/1727873003
Cr-Commit-Position: refs/heads/master@{#34243}
It turns out that some old polyfill library uses
RegExp.prototype.flags as a way of feature testing. It's not clear
how widespread this is. For now, as a minimal workaround, we can
return undefined from getters like RegExp.prototype.global when
the receiver is RegExp.prototype. This patch implements that strategy
but omits a UseCounter to make backports easier.
R=adamk
CC=yangguo@chromium.org
BUG=chromium:581577
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1640803003
Cr-Commit-Position: refs/heads/master@{#34201}
This was changed to match Annex B.2.5.1 of ES2015 and Firefox in
https://chromium.googlesource.com/v8/v8/+/469d9bfa, but website
breakage was seen in M49 Beta. JSC still returns undefined here.
BUG=chromium:585775
LOG=y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1714903004
Cr-Commit-Position: refs/heads/master@{#34172}
Drive-by-fix: Remove the (now) unused %_SetValueOf and %_JSValueGetValue
intrinsics from the various compilers and the runtime.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1698343002
Cr-Commit-Position: refs/heads/master@{#34037}
for the special case where the same register is used as both left and
right input.
Review URL: https://codereview.chromium.org/1695283002
Cr-Commit-Position: refs/heads/master@{#33996}
This removes support for the %Arguments and %ArgumentsLength runtime
entries and their intrinsic counterparts. If you need variable arguments
in any builtin, either use (strict) arguments object or rest parameters,
which are both compositional across inlining (in TurboFan), and not that
much slower compared to the %_Arguments hackery.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1688163004
Cr-Commit-Position: refs/heads/master@{#33943}
This fact is depended upon by, at least, Parser::ParseLazy, and quite
likely by other code. There was already code in %FunctionSetName
enforcing this invariant. This patch adds similar code to
Factory::NewSharedFunctionInfo().
BUG=v8:4659
LOG=n
Review URL: https://codereview.chromium.org/1686193003
Cr-Commit-Position: refs/heads/master@{#33914}
ES2016 TypedArray subclassing semantics break the Node.js Buffer module,
also used on the web. I wrote a pull request against the web and Node
versions to fix the issue, but the pull request has not yet been granted,
and this is blocking shipping the change. For now, this patch extends the
web compatibility workaround to the --harmony-species flag, so that
Symbol.species and associated subclassing semantics can ship independently.
R=cbruni
BUG=v8:4665
LOG=Y
Review URL: https://codereview.chromium.org/1678123002
Cr-Commit-Position: refs/heads/master@{#33826}
Trying to sort a string should throw a TypeError, proper handling
of elements just needs to get out of the way.
BUG=chromium:584188
LOG=n
R=cbruni@chromium.org
Review URL: https://codereview.chromium.org/1670153002
Cr-Commit-Position: refs/heads/master@{#33777}
This removes --harmony-completion, --harmony-concat-spreadable, and
--harmony-tolength and moves the appropriate tests from harmony/ to es6/.
Review URL: https://codereview.chromium.org/1667453002
Cr-Commit-Position: refs/heads/master@{#33712}
This was inconsistent in the spec in case of has vs get, set. Removing
receiver==holder simplifies the lookup; so tentatively removing this
additional check which was broken until yesterday anyway. See
https://github.com/tc39/ecma262/issues/347 for more information.
Review URL: https://codereview.chromium.org/1660903002
Cr-Commit-Position: refs/heads/master@{#33701}
This includes 2 fixes:
1) We didn't properly advance the holder when checking whether
Receiver==Holder, so we'd inadvertently block loading the property if
the first property we find is on the typed array.
2) Reflect.get may cause any object on the prototype chain of the holder
to be the receiver; so we need to recheck for this special state for
each object we perform lookup on.
Review URL: https://codereview.chromium.org/1651913005
Cr-Commit-Position: refs/heads/master@{#33689}
This patch adds a UseCounter for each of the following:
- Allowing duplicate sloppy-mode block-scoped function declarations
in the exact same scope
- for-in loops with an initializer
The patch also refactors some of the declaration code to clean it up and
enable the first counter, and adds additional unit tests to nail down
the semantics of edge cases of sloppy-mode block-scoped function declarations.
BUG=v8:4693,chromium:579395
LOG=N
R=adamk
Review URL: https://codereview.chromium.org/1633743003
Cr-Commit-Position: refs/heads/master@{#33650}
In the debugger we are interested in getting the context for the
current frame, which is usually a function context. To do that,
we used to call Context::declaration_context, which may also
return a block context. This is wrong and can lead to crashes.
Instead, we now use a newly introduced Context::closure_context,
which skips block contexts. This works fine for the debugger,
since we have other means to find and materialize block contexts.
R=rossberg@chromium.org
BUG=chromium:582051
LOG=N
Review URL: https://codereview.chromium.org/1648263002
Cr-Commit-Position: refs/heads/master@{#33627}
Previously, String.prototype.normalize constructed its ICU input
string as a null-terminated string. This creates a bug for strings
which contain a null byte, which is allowed in ECMAScript. This
patch constructs the ICU string based on its length so that the
entire string is normalized.
R=jshin@chromium.org
BUG=v8:4654
LOG=Y
Review URL: https://codereview.chromium.org/1645223003
Cr-Commit-Position: refs/heads/master@{#33614}
The for-in slow mode implementation in Crankshaft unconditionally
deoptimizes when %ForInFilter returns undefined instead of just
skipping the item. Even worse, there's nothing we can learn from
that deopt, so we will eventually optimize again and hit exactly
the same problem again once we get back to optimized code.
R=mvstanton@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1647093002
Cr-Commit-Position: refs/heads/master@{#33609}
So far the for-in slow path in Crankshaft unconditionally called
%ForInFilter for every iteration of the for-in loop, without paying
attention to the possible enum cache equipped receiver map. So even
though we iterate the enum cache FixedArray associated with the map
we don't check the map, but always go to %ForInFilter. This would be
perfectly fine if the enum cache FixedArray would be immutable, but
due to some funny GC/runtime interaction kicking in, the enum cache
can be right trimmed while we are iterating it, and the only way to
detect this is to ensure that we check the map when accessing the
enum cache.
BUG=v8:3650,v8:4715
LOG=n
Review URL: https://codereview.chromium.org/1650493002
Cr-Commit-Position: refs/heads/master@{#33599}
ParseArrowFunctionLiteral was erroneously checking AllowsLazyCompilation
rather than AllowsLazyParsing when deciding whether to parse lazily.
This meant that lexically-scoped variables that had no other referents
wouldn't get closed over properly.
BUG=chromium:580934, v8:4255
LOG=y
Review URL: https://codereview.chromium.org/1630823006
Cr-Commit-Position: refs/heads/master@{#33530}
The web appears to depend on being able to redeclare functions-in-blocks
in sloppy mode (examples seen so far tend to redeclare identical functions,
most likely accidentally).
This patch opens a minimal hole: two same-named function declarations
in the same scope are allowed, only in sloppy mode.
BUG=v8:4693, chromium:579395
LOG=y
Review URL: https://codereview.chromium.org/1622723003
Cr-Commit-Position: refs/heads/master@{#33478}
In case the receiver map has an enum cache, %ForInPrepare returns the
length of the actual enum cache, which might include properties that
are further down the transition tree tho.
R=jarin@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1619353002
Cr-Commit-Position: refs/heads/master@{#33469}
When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
BUG=v8:4267
LOG=Y
Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
Cr-Commit-Position: refs/heads/master@{#33438}
Review URL: https://codereview.chromium.org/1587073003
Cr-Commit-Position: refs/heads/master@{#33461}
Reason for revert:
let me quickly revert the revert, wut?
Goal: my CL should not be in the tree!
Original issue's description:
> Reland of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #1 id:1 of https://codereview.chromium.org/1619803003/ )
>
> Reason for revert:
> the deopt issues have been taken care of by benedikt
>
> Original issue's description:
> > Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
> >
> > Reason for revert:
> > tanks for-in significantly
> >
> > Original issue's description:
> > > [runtime] Do not use the enum-cache for keys retrieval.
> > >
> > > Currently we fail to properly handle shadowed properties. If the
> > > receiver defines a non-enumerable property that reappears on the
> > > prototype as enumerable it incorrectly shows up in [[Enumerate]].
> > > By extending the KeyAccumulator to track non-enumerable properties
> > > we can now properly filter them out when seeing them further up in
> > > the prototype-chain.
> > >
> > > BUG=v8:705
> > > LOG=y
> > >
> > > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > > Cr-Commit-Position: refs/heads/master@{#33405}
> >
> > TBR=jkummerow@chromium.org,bmeurer@chromium.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG=v8:705
> > LOG=n
> >
> > Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> > Cr-Commit-Position: refs/heads/master@{#33443}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:705
>
> Committed: https://crrev.com/5569e270eda517b5ea74e3a7676b3230cbe2f7a9
> Cr-Commit-Position: refs/heads/master@{#33458}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:705
Review URL: https://codereview.chromium.org/1614313003
Cr-Commit-Position: refs/heads/master@{#33459}
Reason for revert:
the deopt issues have been taken care of by benedikt
Original issue's description:
> Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
>
> Reason for revert:
> tanks for-in significantly
>
> Original issue's description:
> > [runtime] Do not use the enum-cache for keys retrieval.
> >
> > Currently we fail to properly handle shadowed properties. If the
> > receiver defines a non-enumerable property that reappears on the
> > prototype as enumerable it incorrectly shows up in [[Enumerate]].
> > By extending the KeyAccumulator to track non-enumerable properties
> > we can now properly filter them out when seeing them further up in
> > the prototype-chain.
> >
> > BUG=v8:705
> > LOG=y
> >
> > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > Cr-Commit-Position: refs/heads/master@{#33405}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=v8:705
> LOG=n
>
> Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> Cr-Commit-Position: refs/heads/master@{#33443}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:705
Review URL: https://codereview.chromium.org/1612413003
Cr-Commit-Position: refs/heads/master@{#33458}
The internal index used to implement for-in can never leave the
valid smi range, so there's no need to actually check for overflow
in Crankshaft. In fact the overflow only triggered a false alert
in the deopt fuzzer.
R=jarin@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1621623002
Cr-Commit-Position: refs/heads/master@{#33456}
Reason for revert:
[Sheriff] Breaks layout tests. Please fix upstream.
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/4077
Original issue's description:
> Array length reduction should throw in strict mode if it can't delete an element.
>
> When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
>
> Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
>
> This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
>
> BUG=v8:4267
> LOG=Y
>
> Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
> Cr-Commit-Position: refs/heads/master@{#33438}
TBR=verwaest@chromium.org,ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4267
Review URL: https://codereview.chromium.org/1611313003
Cr-Commit-Position: refs/heads/master@{#33444}
Reason for revert:
tanks for-in significantly
Original issue's description:
> [runtime] Do not use the enum-cache for keys retrieval.
>
> Currently we fail to properly handle shadowed properties. If the
> receiver defines a non-enumerable property that reappears on the
> prototype as enumerable it incorrectly shows up in [[Enumerate]].
> By extending the KeyAccumulator to track non-enumerable properties
> we can now properly filter them out when seeing them further up in
> the prototype-chain.
>
> BUG=v8:705
> LOG=y
>
> Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> Cr-Commit-Position: refs/heads/master@{#33405}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:705
LOG=n
Review URL: https://codereview.chromium.org/1619803003
Cr-Commit-Position: refs/heads/master@{#33443}
When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
BUG=v8:4267
LOG=Y
Review URL: https://codereview.chromium.org/1587073003
Cr-Commit-Position: refs/heads/master@{#33438}
Currently we fail to properly handle shadowed properties. If the
receiver defines a non-enumerable property that reappears on the
prototype as enumerable it incorrectly shows up in [[Enumerate]].
By extending the KeyAccumulator to track non-enumerable properties
we can now properly filter them out when seeing them further up in
the prototype-chain.
BUG=v8:705
LOG=y
Review URL: https://codereview.chromium.org/1608523002
Cr-Commit-Position: refs/heads/master@{#33405}
Proxy.
If a constructable Proxy changes the target's prototype during the
prototype lookup the target's initial map stays uninitialized half-way
during object construction.
LOG=n
BUG=chromium:578039
Review URL: https://codereview.chromium.org/1586203003
Cr-Commit-Position: refs/heads/master@{#33359}
When derived constructors return a non-object (or not undefined) we
currently throw an exception directly in the callee context. This was
achieved by desugaring the return statement for derived classes. To
be spec compliamnt a separate ConstructStubForDerived is introduced.
Instead of trowing directly, the desugared return statement inside
a derived constructor only returns an integer to indicate an incompatible
result.
BUG=v8:4509
LOG=n
Review URL: https://codereview.chromium.org/1593553002
Cr-Commit-Position: refs/heads/master@{#33336}
Previous changes with subclassable builtins and @@species were a bit
aggressive in making TypedArray.prototype.subarray act like the
ES2016 specification in terms of returning an instance of the
subclass as a result. It turns out that Node.js, and extracted
libraries for the web, subclass TypedArrays but don't expect the
subclass constructor to be called by subarray. @@species will provide
an escape hatch, but it has not shipped yet, and will take some time
for uptake by libraries.
For now, this patch makes TypedArray.prototype.subarray fall back to
constructing an instance of the parent TypedArray class, such as
Uint8Array.
R=adamk
LOG=Y
BUG=v8:4665
Review URL: https://codereview.chromium.org/1583773005
Cr-Commit-Position: refs/heads/master@{#33312}
This avoids generating different scopes on the two compilation passes, which
results in various delirious side-effects.
There's some cleanup to be done in lazy arrow function parsing, but I'd
rather do that in a separate patch, with this one targeted at fixing the
particular crash.
BUG=chromium:572589
LOG=n
Review URL: https://codereview.chromium.org/1575333004
Cr-Commit-Position: refs/heads/master@{#33311}
As luck would have it, there doesn't seem to be a way to trigger
observable misbehavior currently (only with special flags).
BUG=chromium:380671
LOG=n
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1588013002
Cr-Commit-Position: refs/heads/master@{#33305}
This migrates the remaining Date builtins to C++ and removes obsolete
intrinsics and JavaScript wrappers. This reduces the overhead imposed
by the Date builtins, and will allow us to optimize them later in the
TurboFan compiler, while the interpreter doesn't need to worry about
them.
R=yangguo@chromium.org
BUG=chromium:576574
LOG=n
Committed: https://crrev.com/1e51af1a5c80b1650de47dd4bc8f846fa2d85281
Cr-Commit-Position: refs/heads/master@{#33228}
Review URL: https://codereview.chromium.org/1579613002
Cr-Commit-Position: refs/heads/master@{#33231}
Reason for revert:
[Sheriff] Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/5711
Original issue's description:
> [builtins] Refactor the remaining Date builtins.
>
> This migrates the remaining Date builtins to C++ and removes obsolete
> intrinsics and JavaScript wrappers. This reduces the overhead imposed
> by the Date builtins, and will allow us to optimize them later in the
> TurboFan compiler, while the interpreter doesn't need to worry about
> them.
>
> R=yangguo@chromium.org
> BUG=chromium:576574
> LOG=n
>
> Committed: https://crrev.com/1e51af1a5c80b1650de47dd4bc8f846fa2d85281
> Cr-Commit-Position: refs/heads/master@{#33228}
TBR=yangguo@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:576574
Review URL: https://codereview.chromium.org/1574223002
Cr-Commit-Position: refs/heads/master@{#33230}
This migrates the remaining Date builtins to C++ and removes obsolete
intrinsics and JavaScript wrappers. This reduces the overhead imposed
by the Date builtins, and will allow us to optimize them later in the
TurboFan compiler, while the interpreter doesn't need to worry about
them.
R=yangguo@chromium.org
BUG=chromium:576574
LOG=n
Review URL: https://codereview.chromium.org/1579613002
Cr-Commit-Position: refs/heads/master@{#33228}
This patch improves ArrayBuffer and TypedArray subclassing by adding
support for @@species and constructing outputs to certain methods
by creating an instance of the constructor determined by the
SpeciesConstructor algorithm, rather than fixed to a superclass or
naively the constructor. The new behavior is enabled by the
--harmony-species flag. Care is taken to not significantly change the
observable behavior when the flag is off. Previously, TypedArrays
already supported subclassing by reading the constructor of the
receiver, but ArrayBuffers did not, and this old behavior is
preserved and tested for, to avoid a multi-stage upgrade path and keep
things simple for users.
R=adamk
BUG=v8:4093
LOG=Y
Review URL: https://codereview.chromium.org/1574903004
Cr-Commit-Position: refs/heads/master@{#33223}
This patch moves the semantics of 'const' in sloppy mode to match those
in strict mode, that is, const makes lexical (let-like) bindings, must
have an initializer, and does not create properties of the global object.
R=adamk
LOG=Y
BUG=v8:3305
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1571873004
Cr-Commit-Position: refs/heads/master@{#33218}
As V8 becomes more and more spec-compliant, Promise polyfill libraries
like core.js expect fully correct. However, our Promises do not yet
support Symbol.species. Therefore, a case like
```
var test = new Promise(function(){});
test.constructor = function(){};
Promise.resolve(test)
```
would lead to an unhandled Promise rejection, whereas it should not
because test.constructor[Symbol.species] is undefined, so test.then
should end up constructing %Promise% as a fallback, rather than
calling test.constructor as if it were a constructor, which leads
this error checking code to throw.
For now, this patch removes the error checking code (which was not
present until recently). In an interactive test using core.js, the
error message on the console goes away with this patch. When @@species
support is in place, this patch can be reverted. A regression test
is added which checks for the same thing.
Partially reverted patch was originally out for review at
https://codereview.chromium.org/1531073004
BUG=v8:4633
LOG=Y
R=adamk,caitp88@gmail.com
Review URL: https://codereview.chromium.org/1578893002
Cr-Commit-Position: refs/heads/master@{#33217}
Reason for revert:
Crash fixed by https://codereview.chromium.org/1564923007
Original issue's description:
> Revert of Ship ES2015 sloppy-mode function hoisting, let, class (patchset #7 id:120001 of https://codereview.chromium.org/1551443002/ )
>
> Reason for revert:
> Causes frequent crashes in Canary: chromium:537816
>
> Original issue's description:
> > Ship ES2015 sloppy-mode function hoisting, let, class
> >
> > This patch doesn't ship all features of ES2015 variable/scoping
> > changes, notably omitting the removal of legacy const. I think
> > function hoisting, let and class in sloppy mode can stand to
> > themselves as a package, and the legacy const change is much
> > riskier and more likely to be reverted, so my intention is to
> > pursue those as a separate, follow-on patch.
> >
> > R=adamk@chromium.org
> > BUG=v8:4285,v8:3305
> > LOG=Y
> > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
> >
> > Committed: https://crrev.com/fcff8588a5a01587643d6c2507c7b882c78a2957
> > Cr-Commit-Position: refs/heads/master@{#33133}
>
> TBR=adamk@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=v8:4285,v8:3305,chromium:537816
> LOG=Y
>
> Committed: https://crrev.com/adac5956c6216056a211cfaa460a00ac1500d8f8
> Cr-Commit-Position: refs/heads/master@{#33162}
TBR=adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4285,v8:3305,chromium:537816
Review URL: https://codereview.chromium.org/1571793002
Cr-Commit-Position: refs/heads/master@{#33189}
Reason for revert:
Causes frequent crashes in Canary: chromium:537816
Original issue's description:
> Ship ES2015 sloppy-mode function hoisting, let, class
>
> This patch doesn't ship all features of ES2015 variable/scoping
> changes, notably omitting the removal of legacy const. I think
> function hoisting, let and class in sloppy mode can stand to
> themselves as a package, and the legacy const change is much
> riskier and more likely to be reverted, so my intention is to
> pursue those as a separate, follow-on patch.
>
> R=adamk@chromium.org
> BUG=v8:4285,v8:3305
> LOG=Y
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
>
> Committed: https://crrev.com/fcff8588a5a01587643d6c2507c7b882c78a2957
> Cr-Commit-Position: refs/heads/master@{#33133}
TBR=adamk@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:4285,v8:3305,chromium:537816
LOG=Y
Review URL: https://codereview.chromium.org/1565263002
Cr-Commit-Position: refs/heads/master@{#33162}
Some tests passed a string as second argument to assertThrows, expecting it to
be matched against the exception. However, assertThrows simply ignored these.
(Some other tests actually seem to use that argument as a comment ...)
This CL
- changes assertThrows to fail if the second argument is not a function,
- adds assertThrowsEquals which compares the exception to a given value using
assertEquals
- fixes some bogus tests that got exposed by this.
R=jarin@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1544793002
Cr-Commit-Position: refs/heads/master@{#33159}
This patch doesn't ship all features of ES2015 variable/scoping
changes, notably omitting the removal of legacy const. I think
function hoisting, let and class in sloppy mode can stand to
themselves as a package, and the legacy const change is much
riskier and more likely to be reverted, so my intention is to
pursue those as a separate, follow-on patch.
R=adamk@chromium.org
BUG=v8:4285,v8:3305
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1551443002
Cr-Commit-Position: refs/heads/master@{#33133}
For a prototype chain foo -> global_proxy -> global_object, we used to
register a dependency from foo -> global_object. This is incorrect when
the global_proxy/global_object pairing is modified, e.g. when navigating
in iframes. With this patch, we properly register foo -> global_proxy and
global_proxy -> global_object dependencies.
Additionally, when a prototype's prototype changes from null to something
else, this new usage relation must be registered if there are other users
further down on the prototype chain that might expect a complete chain of
registrations to exist (which was the case before, and must be preserved).
BUG=chromium:571517
LOG=n
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1559323002
Cr-Commit-Position: refs/heads/master@{#33119}
In the Date constructor or Date.parse, other browsers will accept time
zones like GMT-8, but before this patch, Chrome would interpret 8 as
8 minutes. This patch interprets GMT-+ a one or two digit number as hours,
not minutes.
R=adamk,jshin@chromium.org
LOG=Y
BUG=chromium:422858
Review URL: https://codereview.chromium.org/1557053002
Cr-Commit-Position: refs/heads/master@{#33100}
1. Location names with more than one underscores (e.g. Ho_Chi_Minh)
didn't work because of the way capturing works with repeated patterns
in RE. It's now supported by changing the RE to capture the whole string
and splitting on '_' in the next step.
2. Adds support for location names with a hyphen
3. Adds support for timezone ids with three parts (e.g.
American/Argentina/Buenos_Aires)
4. Adds special handling of 'au', 'es' and 'of' in zone ids. They need to be kept in lowercase. (see the full list at https://en.wikipedia.org/wiki/List_of_tz_database_time_zones )
5. Adds regression tests for all the above and make the existing tests
more robust against future ICU changes. ICU canonicalizes zone names to
deprecated names, but it may change. (
http://bugs.icu-project.org/trac/ticket/12044 )
BUG=364374
LOG=Y
Review URL: https://codereview.chromium.org/1529363005
Cr-Commit-Position: refs/heads/master@{#33097}
In addition to ThrowTypeError not being a constructor, it was invalidly set up by simply swapping the map. Swapping the map is insufficient since NewFunction* actually set up the function depending on the used map.
BUG=chromium:573858
LOG=n
Review URL: https://codereview.chromium.org/1552223002
Cr-Commit-Position: refs/heads/master@{#33082}
The Object.freeze, Object.isExtensible, Object.isFrozen,
Object.isSealed, Object.preventExtensions and Object.seal builtins were
already implemented in C++, but they still had some funny JavaScript
wrappers that just called into the C++ implementation on every
(interesting) execution path.
Review URL: https://codereview.chromium.org/1553043002
Cr-Commit-Position: refs/heads/master@{#33074}
Unify the constructors and isView methods for ArrayBuffer and
SharedArrayBuffer, moving them to C++ because there's no point
in having the JavaScript wrappers for them.
We choose to deliberately violate the ES2015 specification and
implement the ArrayBuffer constructor in a way that matches
Firefox and Safari instead.
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
BUG=chromium:565917, v8:4592
TBR=hpayer@chromium.orgR=cbruni@chromium.org
LOG=n
Committed: https://crrev.com/3235ccbb7826ceec2188f6ebab98fc851b54f60e
Cr-Commit-Position: refs/heads/master@{#32590}
Review URL: https://codereview.chromium.org/1500543002
Cr-Commit-Position: refs/heads/master@{#33072}
In a rare edge case, a difference in checks between C++ and
JavaScript lead to an 'illegal access' being thrown by the Date
constructor. This patch harmonizes the checks from both sides.
It's possible that slightly larger dates could be permitted,
as the ECMAScript 2015 specification indicates that +287396-10-12
would be a permissible date in the note in
http://tc39.github.io/ecma262/#sec-extended-years
This patch does not revisit the limit, only clears up the
inconsistency.
BUG=v8:4640
R=cbruni
LOG=Y
Review URL: https://codereview.chromium.org/1545883003
Cr-Commit-Position: refs/heads/master@{#33068}
Reason for revert:
Should be fixed again with this Blink change to add NeedsManualRebaseline
Original issue's description:
> Revert of Use ES2015-style TypedArray prototype chain (patchset #5 id:80001 of https://codereview.chromium.org/1541233002/ )
>
> Reason for revert:
> [Sheriff] Changes layout tests. Please fix upstream first if intended.
>
> https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3689
>
> Original issue's description:
> > Use ES2015-style TypedArray prototype chain
> >
> > This patch switches TypedArrays to use the prototype chain described
> > in the ES2015 specification, which adds a %TypedArray% superclass above
> > all individual TypedArray types. Most methods are defined on the
> > superclass rather than the subclasses.
> >
> > In order to prevent a performance regression, a few methods are
> > marked as inline. Inlining might prevent code which was previously
> > monomorphic from becoming polymorphic, and it was specifically
> > applied in places where methods became more polymorphic than before.
> > Tests with realistic workloads would be nice to do before this
> > ships in stable.
> >
> > This patch does not bring TypedArrays up to full spec compliance. In
> > particular, @@species is not yet supported.
> >
> > R=cbruni
> > BUG=v8:4085
> > LOG=Y
> >
> > Committed: https://crrev.com/07c91dccbe55c7be3ec75857dee5ad59873330b7
> > Cr-Commit-Position: refs/heads/master@{#33050}
>
> TBR=caitpotter88@gmail.com,cbruni@chromium.org,littledan@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4085
>
> Committed: https://crrev.com/28b55ffd1e32e09aaf42b8bbb407944d4808e07c
> Cr-Commit-Position: refs/heads/master@{#33053}
TBR=caitpotter88@gmail.com,cbruni@chromium.org,machenbach@chromium.org
BUG=v8:4085
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1558663002
Cr-Commit-Position: refs/heads/master@{#33067}
This patch relands a change to ES2015 Promises which brings us closer to
spec compliance. In this new version, a bug which would lose async callstack
data was fixed.
R=adamk
CC=rossberg,caitp
LOG=Y
BUG=v8:3641
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1538663002
Cr-Commit-Position: refs/heads/master@{#33065}
This matches the behavior of JSObject::JSObjectVerify() and seems to be
the current contract for --verify-heap.
BUG=chromium:572590
LOG=n
Review URL: https://codereview.chromium.org/1553463002
Cr-Commit-Position: refs/heads/master@{#33056}
Reason for revert:
[Sheriff] Changes layout tests. Please fix upstream first if intended.
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3689
Original issue's description:
> Use ES2015-style TypedArray prototype chain
>
> This patch switches TypedArrays to use the prototype chain described
> in the ES2015 specification, which adds a %TypedArray% superclass above
> all individual TypedArray types. Most methods are defined on the
> superclass rather than the subclasses.
>
> In order to prevent a performance regression, a few methods are
> marked as inline. Inlining might prevent code which was previously
> monomorphic from becoming polymorphic, and it was specifically
> applied in places where methods became more polymorphic than before.
> Tests with realistic workloads would be nice to do before this
> ships in stable.
>
> This patch does not bring TypedArrays up to full spec compliance. In
> particular, @@species is not yet supported.
>
> R=cbruni
> BUG=v8:4085
> LOG=Y
>
> Committed: https://crrev.com/07c91dccbe55c7be3ec75857dee5ad59873330b7
> Cr-Commit-Position: refs/heads/master@{#33050}
TBR=caitpotter88@gmail.com,cbruni@chromium.org,littledan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4085
Review URL: https://codereview.chromium.org/1554523002
Cr-Commit-Position: refs/heads/master@{#33053}
This patch switches TypedArrays to use the prototype chain described
in the ES2015 specification, which adds a %TypedArray% superclass above
all individual TypedArray types. Most methods are defined on the
superclass rather than the subclasses.
In order to prevent a performance regression, a few methods are
marked as inline. Inlining might prevent code which was previously
monomorphic from becoming polymorphic, and it was specifically
applied in places where methods became more polymorphic than before.
Tests with realistic workloads would be nice to do before this
ships in stable.
This patch does not bring TypedArrays up to full spec compliance. In
particular, @@species is not yet supported.
R=cbruni
BUG=v8:4085
LOG=Y
Review URL: https://codereview.chromium.org/1541233002
Cr-Commit-Position: refs/heads/master@{#33050}
According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.
There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.
The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n
Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
Cr-Commit-Position: refs/heads/master@{#33042}
Review URL: https://codereview.chromium.org/1542963002
Cr-Commit-Position: refs/heads/master@{#33044}
Reason for revert:
Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind
Original issue's description:
> [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
>
> According to the ES2015 specification, bound functions are exotic
> objects, and thus don't need to be implemented as JSFunctions. So
> we introduce a new JSBoundFunction type to represent bound functions
> and make them optimizable. This already improves the performance of
> calling or constructing bound functions by 10-100x depending on the
> use case because we avoid the crazy dance between JavaScript and C++
> that was implemented in v8natives.js previously.
>
> There's still room for improvement in the performance of actually
> creating bound functions, which is also relevant in practice, but
> we already have a plan how to accomplish that later.
>
> The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
>
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
> BUG=chromium:535408, chromium:571299, v8:4629
> LOG=n
>
> Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
> Cr-Commit-Position: refs/heads/master@{#33042}
TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:535408, chromium:571299, v8:4629
Review URL: https://codereview.chromium.org/1552473002
Cr-Commit-Position: refs/heads/master@{#33043}
According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.
There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.
The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n
Review URL: https://codereview.chromium.org/1542963002
Cr-Commit-Position: refs/heads/master@{#33042}
These constructors always go through C++ at least twice anyway, so
there's not really a point in trying to implement them in JavaScript.
R=yangguo@chromium.org
BUG=chromium:535408
LOG=n
Review URL: https://codereview.chromium.org/1548623002
Cr-Commit-Position: refs/heads/master@{#33012}
