This fixes a missing name check for keyed property loads targeting the
global object where the feedback was warmed up with a single name. This
affects {JSLoadProperty} nodes only, syntactic global property loads via
the {JSLoadGlobal} operator are not affected.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-694416
BUG=chromium:694416
Change-Id: I54aa3f27eaa72630539f02602ec7642b04835b27
Reviewed-on: https://chromium-review.googlesource.com/445224
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43344}
Two controls, one for instantiation and one for compilation. They allow
the embedder (e.g. Chrome) check properties of the parameters of those
two operations, and decide if they are allowed to continue.
For example, Chrome may now decline compilation of certain size buffers,
in synchronous cases; same for instantiation (where the buffer size
refers to the size of the buffer containing wasm wire bytes)
BUG=v8:5981
Review-Url: https://codereview.chromium.org/2699843003
Cr-Original-Commit-Position: refs/heads/master@{#43295}
Committed: d9bc0ffb16
Review-Url: https://codereview.chromium.org/2699843003
Cr-Commit-Position: refs/heads/master@{#43336}
This patch refactors the Atomics builtins so that they are implemented
as C++ builtins rather than experimental JS builtins. Previously, each
of these functions called out to a runtime function, so no significant
change in performance is anticipated. The goal of this patch is to
remove the last user of experimental JS builtins so that the mechanism
can be removed, for performance reasons. The patch includes a drive-by
fix of a check-fail. For the most part, the patch is just moving code
without modification from runtime-atomics.cc to
builtins-sharedarraybuffer.cc .
BUG=v8:5880
Review-Url: https://codereview.chromium.org/2698813004
Cr-Commit-Position: refs/heads/master@{#43335}
qNaN and sNaN values have different binary representation on MIPS
compared to ARM/x86 architectures. We are skipping these tests because
we can't provide specific NaNs encodings from ARM/x86 architectures.
BUG=
Review-Url: https://codereview.chromium.org/2702213003
Cr-Commit-Position: refs/heads/master@{#43327}
Take runtime path if startIndex parameter requires a ToInteger() call,
which can modify the elements kind of the receiver.
This removes a stub call from the builtin, and simplifies code slightly.
BUG=v8:5986
R=bmeurer@chromium.org, cbruni@chromium.org
Change-Id: Id238a81ab8ba28621858004b34d00a4356b8037f
Reviewed-on: https://chromium-review.googlesource.com/445006
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#43323}
info.This returns a Local<Object>, which results in a call to
Utils::OpenHandle<JSReceiver>. Casting to a Local<Value> first uses the
correct OpenHandle<Object> overload.
BUG=chromium:693500
Review-Url: https://codereview.chromium.org/2706833002
Cr-Commit-Position: refs/heads/master@{#43314}
The constant field tracking is still disabled.
BUG=v8:5495
Change-Id: I543fe50b82e2255bbf200ea785ec53e3623e30cb
Reviewed-on: https://chromium-review.googlesource.com/440924
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43304}
Reason for revert:
Introduces a new test failure/flake: https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/16427
Original issue's description:
> [wasm] Embedder can control what buffers wasm compilation works on.
>
> Two controls, one for instantiation and one for compilation. They allow
> the embedder (e.g. Chrome) check properties of the parameters of those
> two operations, and decide if they are allowed to continue.
>
> For example, Chrome may now decline compilation of certain size buffers,
> in synchronous cases; same for instantiation (where the buffer size
> refers to the size of the buffer containing wasm wire bytes)
>
> BUG=v8:5981
>
> Review-Url: https://codereview.chromium.org/2699843003
> Cr-Commit-Position: refs/heads/master@{#43295}
> Committed: d9bc0ffb16TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5981
Review-Url: https://codereview.chromium.org/2701413002
Cr-Commit-Position: refs/heads/master@{#43303}
The bytecode generator did not necessarily know for which scope, and
thus language mode, it was generating code, because it only tracked
scopes that have a context. This led to wrong behavior in some
examples involving class expressions (which are always in strict
mode).
With this CL, the bytecode generator explicitly tracks the current
scope, independent of whether it has a context.
BUG=v8:5927
Change-Id: Ifa6b3ee5e13e07b63d00e74c7f557a328633c88b
Reviewed-on: https://chromium-review.googlesource.com/444785
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43300}
Currently, typeof o, where o is an undetectable
callable object (such as document.all), returns 'function' if
optimised. It should, however, return 'undefined'.
This CL excludes undetectable objects from the optimization
resulting in type 'function' and renames the related code to
reflect that.
BUG=v8:5972
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2697063002
Cr-Commit-Position: refs/heads/master@{#43298}
Two controls, one for instantiation and one for compilation. They allow
the embedder (e.g. Chrome) check properties of the parameters of those
two operations, and decide if they are allowed to continue.
For example, Chrome may now decline compilation of certain size buffers,
in synchronous cases; same for instantiation (where the buffer size
refers to the size of the buffer containing wasm wire bytes)
BUG=v8:5981
Review-Url: https://codereview.chromium.org/2699843003
Cr-Commit-Position: refs/heads/master@{#43295}
Adds five new TF builtins for the spec defined functions/closures. This follows
mechanism similar to promise resolving functions approach where we store the
closure variables in a custom context.
Adds a new --harmony-promise-finally flag.
BUG=v8:5967
Review-Url: https://codereview.chromium.org/2695753002
Cr-Commit-Position: refs/heads/master@{#43294}
For functions declared in source code, the .toString() representation
will be an excerpt of the source code.
* For functions declared with the "function" keyword, the excerpt
starts at the "function" or "async" keyword and ends at the final "}".
The previous behavior would start the excerpt at the "(" of the
parameter list, and prepend a canonical `"function " + name` or
similar, which would discard comments and formatting surrounding the
function's name. Anonymous functions declared as function expressions
no longer get the name "anonymous" in their toString representation.
* For methods, the excerpt starts at the "get", "set", "*" (for
generator methods), or property name, whichever comes first.
Previously, the toString representation for methods would use a
canonical prefix before the "(" of the parameter list. Note that any
"static" keyword is omitted.
* For arrow functions and class declarations, the excerpt is unchanged.
For functions created with the Function, GeneratorFunction, or
AsyncFunction constructors:
* The string separating the parameter text and body text is now
"\n) {\n", where previously it was "\n/*``*/) {\n" or ") {\n".
* At one point, newline normalization was required by the spec here,
but that was removed from the spec, and so this CL does not do it.
Included in this CL is a fix for CreateDynamicFunction parsing. ')'
and '`' characters in the parameter string are no longer disallowed,
and Function("a=function(", "}){") is no longer allowed.
BUG=v8:4958, v8:4230
Review-Url: https://codereview.chromium.org/2156303002
Cr-Commit-Position: refs/heads/master@{#43262}
We were looking at the unreachable flag or stack_depth of the target frame
instead of the current one in a couple of places (most notably BreakTo).
This change fixes these bugs and makes us pass the latest spec tests for
br_table validation. Also need to ensure that br_table targets have consistent
types, which is not implied if the stack is polymorphic.
R=titzer@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2696813002
Cr-Commit-Position: refs/heads/master@{#43250}
One optimization in the machine-operator-reducer did not consider that
that word32 shift left instructions only consider the last 5 bits of
the shift input.
The issue only occurs for WebAssembly because in JavaScript we always
add a "& 0xf" on the shift value to the TurboFan graph.
For additional background: The JavaScript and WebAssembly spec both
say that only the last 5 bits of the shift value are used in the
word32-shift-left operation. This means that an "x << 0x29", in the
code is actually executed as "x << 0x09". Therefore the changes in
this CL are okay because they mask the last 5 bit of the shift value.
BUG=chromium:689450
Change-Id: Id92f298ed6d7f1714b109b3f4fbcecd5ac6d30f7
Reviewed-on: https://chromium-review.googlesource.com/439312
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43245}
Reason for revert:
Please remove the file in status file too. Breaks presubmit:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20presubmit/builds/14754
Or lets call it post-submit :(
Original issue's description:
> This is a workaround for the fact that %SetCode can "lose" the script for a js native. If the js native is re-initialized (for a Realm or something), then the source SharedFunctionInfo won't have a script anymore. Nonetheless, we may want to optimize the function. If we've compiled bytecode, then we can compile optimized code without a script.
>
> Here, we carve out a special exception for this case, so that we can turn on the --mark-shared-functions-for-tier-up.
>
> BUG=v8:5946
> R=leszeks@chromium.org
>
> Review-Url: https://codereview.chromium.org/2684033007
> Cr-Commit-Position: refs/heads/master@{#43240}
> Committed: 4123a3dd79TBR=leszeks@chromium.org,mstarzinger@chromium.org,marja@chromium.org,mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5946
Review-Url: https://codereview.chromium.org/2703553002
Cr-Commit-Position: refs/heads/master@{#43242}
ES2016 changed the default timezone of dates to be conditional on
whether a time is included. The semantics were a compromise approach
based on web compatibility feedback from V8, but until now, we have been
shipping ES5.1 default timezone semantics. This patch implements the
new semantics, following ChakraCore and SpiderMonkey (though JSC
implements V8's previous semantics).
BUG=chromium:589858
Review-Url: https://codereview.chromium.org/2648603002
Cr-Commit-Position: refs/heads/master@{#43239}
@@replace has a pretty complex implementation, taking different paths
for various situations (e.g.: global/nonglobal regexp, functional/string
replace argument, etc.). Each of these paths must implement similar
logic for calling into the RegExpBuiltinExec spec operation, and many
paths get this subtly wrong.
This CL fixes a couple of issues related to the way @@replace handles lastIndex:
* All paths now respect lastIndex when calling into exec (some used to assume 0).
* lastIndex is now advanced after a successful match for sticky regexps.
* lastIndex is now only reset to 0 on failure for sticky regexps.
BUG=v8:5361
Review-Url: https://codereview.chromium.org/2685183003
Cr-Commit-Position: refs/heads/master@{#43234}
When --harmony-async-iteration is enabled, it is now possible to
use the for-await-of loop, which uses the Async Iteration protocol
rather than the ordinary ES6 Iteration protocol.
the Async-from-Sync Iterator object is not implemented in this CL,
and so for-await-of loops will abort execution if the iterated object
does not have a Symbol.asyncIterator() method. Async-from-Sync
Iterators are implemented seperately in https://codereview.chromium.org/2645313003/
BUG=v8:5855, v8:4483
R=neis@chromium.org, littledan@chromium.org, adamk@chromium.org
Review-Url: https://codereview.chromium.org/2637403008
Cr-Commit-Position: refs/heads/master@{#43224}
The mips64 implementation always ended up in the slowpath due to some
loads that were the wrong width, so that is also fixed here.
BUG=v8:5974
Change-Id: Ie448a1fab5b7fca87597c5a1bf75443864e30c28
Reviewed-on: https://chromium-review.googlesource.com/443247
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43222}
- Removes shared InnerArrayCopyWithin JS builtin from src/js/array.js
- Implements %TypedArray%.prototype.copyWithin as a C++ builtin, which
relies on std::memmove rather than accessing individual eleements.
- Fixes the case where copyWithin is invoked on a TypedArray with a
detached buffer.
- Add tests to ensure that +/-Infinity (for all 3 parameters) is handled
correctly by the
algorithm
The C++ version gets through the benchmark more than 25000 times as
quickly as the JS implementation.
BUG=v8:5925, v8:5929, v8:4648
R=cbruni@chromium.org, adamk@chromium.org, littledan@chromium.org
Review-Url: https://codereview.chromium.org/2697593002
Cr-Commit-Position: refs/heads/master@{#43213}
ParserBase::is_any_identifier currently does not recognise
Token::ESCAPED_STRICT_RESERVED_WORD as an identifier. This seems different
from what ParserBase::ParseIdentifierName does, and also prevents
"l\u0065t", unlike "let", from becoming a label.
This CL extends is_any_identifier to also accept ESCAPED_STRICT_RESERVED_WORD.
BUG=v8:5692
Review-Url: https://codereview.chromium.org/2695973003
Cr-Commit-Position: refs/heads/master@{#43204}
BUG=
Change-Id: I4a5db9bc045a63e710d0115523ab23b98e7c7ae6
Reviewed-on: https://chromium-review.googlesource.com/442504
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43189}
If the Reflect.construct receives an argument expected to be a constructor,
and the argument is not a constructor, V8 currently declares that
Reflect.construct is not a function. It should instead say that the offending
argument is not a constructor.
This is the case for all ports of builtins
(Builtins::Generate_ReflectConstruct). All of them make an
attempt to at least pass the right argument to the TypeError parametrised
message, calling out the offending Reflect.construct argument. However,
Runtime::kThrowCalledNonCallable extracts the callsite from those arguments,
discarding the precise information.
This CL adds Runtime::kNotConstructor, which reports the arguments passed
to it, and the CL also modifies the ports of builtins to make use of
Runtime::kNotConstructor
BUG=v8:5671
Review-Url: https://codereview.chromium.org/2688393003
Cr-Commit-Position: refs/heads/master@{#43182}
I identified lots of asm.js tests that are actually not valid according
to the spec, hence they execute in default-javascript-mode.
This CL fixes most of them by adding additional type annotations.
The atomic tests are totally non-spec-compliant by expecting a fourth
argument, and infinite-loops-taken expects a function-type parameter,
so I did not fix those.
I also did not fix the regression tests.
R=titzer@chromium.org, bradnelson@chromium.org
BUG=v8:4203
Review-Url: https://codereview.chromium.org/2663243002
Cr-Commit-Position: refs/heads/master@{#43179}
The constructor for TypedArray in js/typedarray.js emitted
kInvalidTypedArrayAlignment if the array offset exceeded the size of the
underlying buffer. This seems like a typo introduced in
https://codereview.chromium.org/2090353003.
The error message to be emitted instead coincides with the already existing
kInvalidDataViewOffset. The message string is independent of whether the
object in question is a DataView or a typed array, so this CL:
(1) renames kInvalidDataViewOffset to just kInvalidOffset, and
(2) uses kInvalidOffset instead of kInvalidTypedArrayAlignment for cases
when the TypedArray is constructed with an offset exceeding the buffer
size.
BUG=v8:5733
TEST=Run d8, execute "new Uint8Array(new ArrayBuffer(1),2)", see the error message mention the invalid offset 2.
Review-Url: https://codereview.chromium.org/2692753002
Cr-Commit-Position: refs/heads/master@{#43151}
This CL fixes some nits in TypeError messages, unifying the form of
kDefineDisallowed and kObjectNotExtensible to match what is used by the
majority of the other messages:
* "Cannot" vs. "Can't" -> choose "Cannot"
* "property:%" -> "property %"
* omit the full-stop at the end of the message
BUG=v8:5673
Review-Url: https://codereview.chromium.org/2686233008
Cr-Commit-Position: refs/heads/master@{#43150}
This adds support for deoptimizing into the JSConstructStub after the
receiver instantiation but before the actual constructor invocation.
Such a deoptimization point is needed for cases where instantiation
might be observed (e.g. when new.target is a proxy) and hence might
trigger a deopt.
We use this new deoptimization point for the "after" frame-state the
inliner attaches to {JSCreate} nodes being inserted when constructor
calls are being inlined.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-5638b
BUG=v8:5638
Change-Id: I7c72c807ee8fb76d12e0e9ccab86d970ab1a0efd
Reviewed-on: https://chromium-review.googlesource.com/440125
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43149}
We cannot skip the @@hasInstance lookup in instanceof depending on a
global protector cell, as the lookup of the property is observable
via proxies or accessors. So remove the global protector and properly
implement CSA::InstanceOf via GetPropertyStub, with an appropriate
fast-path for Function.prototype[@@hasInstance] where we call the
builtin code object directly if the function matches, skipping all
the checks from the call sequence, and also avoid the redundant
ToBoolean conversion on the result.
R=yangguo@chromium.orgTBR=ulan@chromium.org
BUG=v8:5958
Review-Url: https://codereview.chromium.org/2684033012
Cr-Commit-Position: refs/heads/master@{#43137}
Reason for revert:
Due to security issue described in review thread.
Original issue's description:
> [typedarrays] move %TypedArray%.prototype.copyWithin to C++
>
> - Removes shared InnerArrayCopyWithin JS builtin from src/js/array.js
> - Implements %TypedArray%.prototype.copyWithin as a C++ builtin, which
> relies on std::memmove rather than accessing individual eleements.
> - Fixes the case where copyWithin is invoked on a TypedArray with a
> detached buffer.
> - Add tests to ensure that +/-Infinity (for all 3 parameters) is handled correctly by the
> algorithm
>
> The C++ version gets through the benchmark more than 25000 times as
> quickly as the JS implementation.
>
> BUG=v8:5925, v8:5929, v8:4648
> R=cbruni@chromium.org, adamk@chromium.org, littledan@chromium.org
>
> Review-Url: https://codereview.chromium.org/2671233002
> Cr-Commit-Position: refs/heads/master@{#42975}
> Committed: 0f1c626d55TBR=cbruni@chromium.org,adamk@chromium.org,bmeurer@chromium.org,cwhan.tunz@gmail.com,caitp@igalia.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5925, v8:5929, v8:4648
Review-Url: https://codereview.chromium.org/2693753002
Cr-Commit-Position: refs/heads/master@{#43132}
Do not allow that holey properties are defined in Array sort.
Throw a type error if the array is not extensible and there are holey
properties in the middle of the array.
BUG=v8:4888
Review-Url: https://codereview.chromium.org/2664173002
Cr-Commit-Position: refs/heads/master@{#43126}
Alternative approach to https://codereview.chromium.org/2667983004/, which
does not depend on implicit control flow changes from
https://codereview.chromium.org/2664083002
- Remove handling for `async function` from Parser::RewriteReturn(). This functionality
is moved to BytecodeGenerator::BuildAsyncReturn(). This ensures that promise resolution
is deferred until all finally blocks are evaluated fully.
- Add a new deferred command (CMD_ASYNC_RETURN), which instructs ControlScope to
generate return code using BuildAsyncReturn rather than BuildReturn.
- Parser has a new `NewReturnStatement()` helper which determines what type of return
statement to generate based on the type of function.
BUG=v8:5896, v8:4483
R=littledan@chromium.org, neis@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, gsathya@chromium.org
Review-Url: https://codereview.chromium.org/2685683002
Cr-Commit-Position: refs/heads/master@{#43104}
This fixes the case where the index passed to {HMaybeGrowElements} used
to derive the new capacity for the elements backing store does not fit
into Smi range. Such an overflow would fail the capacity check and cause
growing to be skipped. Subsequent keyed stores would potentially go out
of bounds.
R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-crbug-686427
BUG=chromium:686427
Review-Url: https://codereview.chromium.org/2686263002
Cr-Commit-Position: refs/heads/master@{#43101}
