Restructure the code a little, and change how we detect sloppy block function
redeclaration so we don't dereference a possibly nullptr function.
Bug: chromium:900786
Change-Id: Ief124fe767603ca36f4dc8865c4aeb3e0635b4cf
Reviewed-on: https://chromium-review.googlesource.com/c/1314331
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57206}
This reverts commit 7350e7b220.
Reason for revert: Braking layout test, blocking the roll, see
https://bugs.chromium.org/p/v8/issues/detail?id=8405
Original change's description:
> Get BytecodeArray via current frame where possible.
>
> With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak.
> Instead of getting the bytecode array from the SFI, get it from the frame instead
> (which is a strong pointer). Note: This won't actually change behaviour since the
> fact that the bytecode array was on the frame will retain it strongly, however it
> makes the contract that the BytecodeArray must exist at these points more explicit.
>
> Updates code in runtime-profiler.cc, frames.cc and runtime-test.cc to do this.
>
> BUG=v8:8395
>
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
> Change-Id: Id7a3e6857abd0e89bf238e9b0b01de4461df54e1
> Reviewed-on: https://chromium-review.googlesource.com/c/1310193
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57198}
TBR=rmcilroy@chromium.org,mythria@chromium.org
Change-Id: Ie5db0ec1d68ca01d62e9880a4476704ad4d013b5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8395
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1314330
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57205}
The fast-path in the `ArrayPrototypeLastIndexOf` torque implementation
didn't check that the `fromIndex` is within the bounds of the JSArray
_AFTER_ the call to ToInteger, which can have arbitrary side-effects,
i.e. it can change the length of the array.
R=yangguo@chromium.org
Bug: chromium:898785
Change-Id: I7ef84143ec8c33148f6e9d451bd52769d5074fb4
Reviewed-on: https://chromium-review.googlesource.com/c/1314329
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57204}
Add a templates: Intl::GetStringOptionTo<> to simplify the reading
of string from options.
Add GetCaseFirst and GetHourCycle into Intl for later reuse
by different Intl objects
Move some enum shared by Intl object into Intl::
Bug: v8:5751
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: If9ed1889a594f7c0ee6669b4679dda9169e4a771
Reviewed-on: https://chromium-review.googlesource.com/c/1297772
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57201}
To fix the to-be-landed-soon test262 test failure in
test262/intl402/DateTimeFormat/prototype/resolvedOptions/order
The spec change from "any order" to "table " order
in https://github.com/tc39/ecma402/pull/279
Change the order of creating each property
Move the code inside SetPropertyFromPattern into ResolvedOptions
so we can easily follow the spec.
Bug: v8:8379
Change-Id: Ibe9ea72a2557474fd81a9f350fffa298f4b7738f
Reviewed-on: https://chromium-review.googlesource.com/c/1302803
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57200}
With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak.
Instead of getting the bytecode array from the SFI, get it from the frame instead
(which is a strong pointer). Note: This won't actually change behaviour since the
fact that the bytecode array was on the frame will retain it strongly, however it
makes the contract that the BytecodeArray must exist at these points more explicit.
Updates code in runtime-profiler.cc, frames.cc and runtime-test.cc to do this.
BUG=v8:8395
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Id7a3e6857abd0e89bf238e9b0b01de4461df54e1
Reviewed-on: https://chromium-review.googlesource.com/c/1310193
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57198}
The previous AtomicElement wrapper fundamentally relied on
reinterpret_casting a heap address to an instance of a C++
object, which is an invalid cast. This patch replaces that
pattern with an ObjectSlot-based alternative that does not
rely on UB.
Bug: v8:3770
Change-Id: I62fb3c7589ac59e9e18139b525174de77e0e2149
Reviewed-on: https://chromium-review.googlesource.com/c/1309297
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57197}
Change the order of creating property for the return object
of Intl.NumberFormat.property.resolvedOptions()
according to the table in the spec.
This is due to spec change in from "any order" to "table "
in https://github.com/tc39/ecma402/pull/279
Failure w/o fixing it will happen once we land
test262/intl402/NumberFormat/prototype/resolvedOptions/order
Bug: v8:8378
Change-Id: Ic68fcfeba78af87d9bbd13c935ad9a91e76f4965
Reviewed-on: https://chromium-review.googlesource.com/c/1303195
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57195}
This was removed from gtest and is necessary to roll gtest in
Chromium.
TBR=adamk@chromium.org
Bug: chromium:893369
Change-Id: I21762aa65ab2fc3f52731e7e812f0bf155f285e6
Reviewed-on: https://chromium-review.googlesource.com/c/1310598
Commit-Queue: Fabrice de Gans-Riberi <fdegans@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57193}
This is preparation to support the Torque port of Object.fromEntries,
including tests to make sure that the interface of the iterator functions
is correct and compiles when used.
Change-Id: I2a30ef80a80f42d4744a92746c8cd383abc10c19
Reviewed-on: https://chromium-review.googlesource.com/c/1303726
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57192}
Fix the broken test of the to-be-landed
test262/intl402/ListFormat/prototype/resolvedOptions/order
The ecma402 spec change from "any order" to "table " order
in https://github.com/tc39/ecma402/pull/279 the intl* proposals
will follow.
Bug: v8:7871
Change-Id: If47ab44791920c23fe2e1101e60205589d0ac093
Reviewed-on: https://chromium-review.googlesource.com/c/1302058
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57191}
The Intl.RelativeTimeFormat.prototype.formatToParts does not
correctly implement the spec. Change the implementation by refactoring
the JSNumber::FormatToParts and delegate part of the
JSRelativeTimeFormat::FormatToParts to call the new refactored function.
Bug: v8:8382
Change-Id: Ie153aa256ca78ce71c92efcdad55262564349ca9
Reviewed-on: https://chromium-review.googlesource.com/c/1305936
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57188}
This is a reland of 0f15ed05b9
Original change's description:
> [torque]: Implement catch handlers for try blocks
>
> In addition (and in combination), try statements now support "catch"
> clauses at the end that catch JavaScript exceptions throw by any builtin
> or runtime function contained in the try block:
>
> try {
> ThrowTypeError(context, ...);
> }
> catch (e) {
> // e has type Object
> }
>
> Bug: v8:7793
> Change-Id: Ie285ff888c49c112276240f7360f70c8b540ed19
> Reviewed-on: https://chromium-review.googlesource.com/c/1302055
> Commit-Queue: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57169}
Bug: v8:7793
Change-Id: I3c4182303acfdfa625654976bec372cf531d954f
Reviewed-on: https://chromium-review.googlesource.com/c/1310295
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57184}
We'd flatten upon compile anyway; and hashing the cons string also
creates a local flattened version that's not cached.
Change-Id: Ib5c82385ab009464b45bf1ceb289d04caaa77fcf
Reviewed-on: https://chromium-review.googlesource.com/c/1309827
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57182}
- introduced ValueMirror interface, this interface contains methods to generate
different protocol entities,
- introduced DebugPropertyIterator, this iterator iterates through object properties
in the following order: exotic indices, enumerable strings, all other properties,
- removed all injected script infra, e.g. closure compiler,
R=dgozman@chromium.orgTBR=yangguo@chromium.org
Bug: chromium:595206
Change-Id: I030fdb3a80074ca6edd4749f86b39b590776ae6f
Reviewed-on: https://chromium-review.googlesource.com/c/1310056
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57181}
JSON format does not support \xNN encoding. Use \uNNNN instead.
+ Add myself to the src/tracing/OWNERS
BUG=chromium:895974
Change-Id: I410a09d44af08b61837579fa09d263d897b9385e
Reviewed-on: https://chromium-review.googlesource.com/c/1303535
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57180}
This reverts commit 9392727982.
Reason for revert: Speculative revert, seems the most probable cause of
https://bugs.chromium.org/p/v8/issues/detail?id=8396
Revert "[ubsan] More Object** replacements"
This reverts commit 5cce694d60.
Speculative revert.
NOTRY=true
Bug: v8:8396
Change-Id: I9c2866a9db707cd03e4cf90822acde20813cebf0
Reviewed-on: https://chromium-review.googlesource.com/c/1309761
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57174}
The slow path in Runtime_ArrayIndexOf allocates handles in each
iteration over the input object. This CL gives each iteration its
own handle scope in order to avoid consuming more and more memory
the longer the loop runs.
This can be observed e.g. by executing
console.log(new Proxy(new Array(2**30), {}).indexOf(42))
which used to run out of memory on my machine.
Bug: v8:8386
Change-Id: Idab98ef7e1e4047c21c1dc0e01ba2d3d363c1f09
Reviewed-on: https://chromium-review.googlesource.com/c/1309759
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57173}
In addition (and in combination), try statements now support "catch"
clauses at the end that catch JavaScript exceptions throw by any builtin
or runtime function contained in the try block:
try {
ThrowTypeError(context, ...);
}
catch (e) {
// e has type Object
}
Bug: v8:7793
Change-Id: Ie285ff888c49c112276240f7360f70c8b540ed19
Reviewed-on: https://chromium-review.googlesource.com/c/1302055
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57169}
Move code logging out of the finisher task. Schedule a separate task
for logging, but only if logging is actually enabled.
R=mstarzinger@chromium.org
Bug: v8:7921
Change-Id: Ib2c7db22c87e60e204096df3e8ef5b354802984f
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/1308113
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57165}
You can now serve the page locally by running
npm i
npm run-script build
npm run-script dev-server
Notry: true
Change-Id: Iefe8459a8c53445570ecfed4cc843a4e8ed9c42d
Bug: v8:7327
Reviewed-on: https://chromium-review.googlesource.com/c/1309753
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57163}
Now that lazy deserialization has been removed, we can roll back all
the mechanisms we introduced to support lazy single-builtin
deserialization.
This CL moves serialized builtin code objects (i.e.
off-heap-trampolines in most cases) back into the startup snapshot.
Support classes for builtin serialization and deserialization, as well
as the builtins snapshot itself are removed. Templatization on the
allocator class is removed as well.
Tbr: delphick@chromium.org
Bug: v8:6666, v8:7990
Change-Id: I2a910f8d3278b7e27b5f18ad408361ebd18871cc
Reviewed-on: https://chromium-review.googlesource.com/c/1304539
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57160}
Obvious in hindsight. The problem wasn't that a signaling nan snuck
into the array, but that equality comparisons always return false if
either operand is a nan.
Bug: chromium:900133
Change-Id: I9cf82afd1ad1fcc3bf7138b612f615b1bd51b98a
Reviewed-on: https://chromium-review.googlesource.com/c/1309634
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57159}
CanCover is not transitive. The counter example are Nodes A,B,C such
that CanCover(A, B) and CanCover(B,C) and B is pure. In this case the
effect level of A and B might differ.
This CL adds a missing CanCover check to a case of shift reduction where
we assumed transitivity.
Change-Id: I9f368ffa6907d2af21bbc87b3e6570d0d422e125
Bug: v8:8384
Reviewed-on: https://chromium-review.googlesource.com/c/1307419
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57157}
