- 31 May, 2019 5 commits
-
-
Jaroslav Sevcik authored
Truncation::Float64 is confusing; in reality, we mean that oddballs and big-ints are identified with their ToNumber counterparts. Bug: v8:9183 Change-Id: Ibcce990327ac7e01e36a2237ad39c374ac9922aa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632224 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61937}
-
Yang Guo authored
R=rmcilroy@chromium.org Bug: v8:9247 Change-Id: I2644436fd44ecf0e206a81cf28071cccb49793df Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1635690 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#61936}
-
v8-ci-autoroll-builder authored
Rolling v8/test/wasm-js/data: https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+log/bc7d300..41747be Remove extraneous copyright from bikeshed document (#1030) (Ben Smith) https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+/41747be [test/interpreter] Rounding edge cases for float literals (#1025) (Andreas Rossberg) https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+/4bf74f6 Editorial: Remove links from Number, Object when checking types (Daniel Ehrenberg) https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+/b8faae7 [interpreter] Fix edge cases for f32_convert_i64 (#1021) (Andreas Rossberg) https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+/356886f [spec] Address feedback on section 4 (#1022) (Andreas Rossberg) https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+/9fd0547 [spec] Tweak wording (#966) (Andreas Rossberg) https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+/a0e1a7e [spec][js-api] Fix some links (#1020) (Ben Smith) https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+/39646d1 TBR=ahaas@chromium.org,clemensh@chromium.org Change-Id: I543114a3147fac367f9e03962b7cbbad172c9fd8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1638223Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#61935}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/19aa2f3..355210a Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/7760fd2..b8451b7 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/9779b14..bad01ad Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/65e8ecf..1f646a8 TBR=machenbach@chromium.org,sergiyb@chromium.org,tmrts@chromium.org Change-Id: I5cf09857950c36a67630c3ed6e0cdf37202b4141 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1638222Reviewed-by:
-
Yu Yin authored
port https://crrev.com/c/1632235 (65f3861e) to mips. Original Commit Message: So far, calls to Wasm C/C++ API functions reused the call descriptors of WasmImportWrappers, and the stack frame type of regular Wasm functions. This CL cleans that up by introducing separate implementations for both. No change in functionality or performance is expected. Change-Id: I1d068e9baab403d714ddb31c26f97fa4e5becb41 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1635275 Commit-Queue: Yu Yin <xwafish@gmail.com> Auto-Submit: Yu Yin <xwafish@gmail.com> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#61933}
-
- 30 May, 2019 7 commits
-
-
Irina Yatsenko authored
WeakFixedArray, WeakArrayList, JSFinalizationGroup, JSFinalizationGroupCleanupIterator, WeakCell, JSWeakRef, BytecodeArray, SourcePositionWithFrameCache Note: SourcePositionTableWithFrameCache doesn't derive from Tuple2 anymore. Bug: v8:8952 Original CL: https://chromium-review.googlesource.com/c/v8/v8/+/1504433 Change-Id: I13f102b445c9ff3e1ebabe0cdf013c62bb6d771d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559212 Commit-Queue: Irina Yatsenko <irinayat@microsoft.com> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Suraj Sharma authored
Bug: v8:8952 Change-Id: I37410feab6fb24b306ba8712013267ba1ff5bc5d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1618341Reviewed-by:
-
Johannes Henkel authored
This makes it so that v8 stops using the copy of the endoding library in the template - that is, third_party/inspector_protocol/lib/encoding_{h,cpp}.template - and uses the C++ library directly instead. This is done by having third_party/inspector_protocol/lib/Values_cpp.template include it, which is configured in the inspector_protocol_config.json. Change-Id: I1f8f2541ac2ed588ca35249e383b4c569434022b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1635598Reviewed-by:Alexei Filippov <alph@chromium.org> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#61930}
-
Dan Elphick authored
Fixes LookupNameOfBytecodeHandler so it actually returns non-nullptr values with embedded builtins enabled. Also now correctly handles wide and extra-wide bytecodes and always works regardless of whether ENABLE_DISASSEMBLER is set. Bug: v8:9215 Change-Id: I787134f2145d02daaf5b50ecb6c174dfc129a4fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1635890Reviewed-by:
-
Yang Guo authored
Bug: v8:9247 Change-Id: Id6860e7b0f932990ac3cda39e369b0809e4f6a2b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632072Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Daniel Clifford <danno@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61928}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/c93f946..19aa2f3 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/5db62d3..7760fd2 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/b97d193..9779b14 Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/f71fb4f..f5edb4f Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/64bb071..65e8ecf TBR=machenbach@chromium.org,sergiyb@chromium.org,tmrts@chromium.org Change-Id: Iafa053df8859ac7040338af3f6655c5c15b2a007 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1636487Reviewed-by:
-
Yu Yin authored
port https://crrev.com/c/1627539 to mips. Change-Id: I18029495b6793fa1b981e28505a7c42842dacc97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634629Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Yu Yin <xwafish@gmail.com> Cr-Commit-Position: refs/heads/master@{#61926}
-
- 29 May, 2019 22 commits
-
-
Michael Mclaughlin authored
Currently, Number.prototype.toString(radix) often fails to produce the least significant bit for doubles near zero. For example, for the minimum double, 5e-324, toString(2) produces "0". This means that a user cannot reliably get the exact binary or hexdecimal value of a double from JavaScript using toString. This patch makes a slight amendment to the DoubleToRadixCString function, so that doubles where the gap to the next double is 5e-324 (i.e. doubles less than 2**-1021), are represented exactly in binary and other power-of-two bases, and close to exactly otherwise. It results in Number.prototype.toString producing the correct binary value for all doubles. R=jkummerow@chromium.org, mathias@chromium.org, yangguo@chromium.org Bug: v8:9294 Change-Id: I71506149b7c4c0eac8c38675a1ee15fb4f36f9ef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631601 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#61925}
-
Frank Tang authored
Speed up Intl.PluralRules constructor x3.4 $python -u tools/run_perf.py --binary-override-path \ out/x64.release/d8 --filter "JSTests/Intl" \ test/js-perf-test/JSTests5.json Score for NewIntlPluralRules BEFORE 550 581 576 AFTER 1856 1978 1996 Bug: v8:9300 Change-Id: I76b4290aa433b1049e3ee770d391b86e468e967d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630134 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
-
Johannes Henkel authored
New revision: e8ba1a7665bdcd8336915d5ca4b390e0cf6b1f6f Change-Id: I6a916f003a29b0b9436ad031bbd43eddfa189e63 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634938 Auto-Submit: Johannes Henkel <johannes@chromium.org> Reviewed-by:
-
Z Duong Nguyen-Huu authored
Bug: chromium:966460 Change-Id: I418eab656510fe3f799f552e75be10140d25bcab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1625864Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#61922}
-
Milad Farazmand authored
Port 157b9181 Original Commit Message: Port 878ccb33 Original Commit Message: This CL was generated by an automatic clang AST rewriter using this matcher expression: callExpr( callee( cxxMethodDecl( hasName("operator->"), ofClass(isSameOrDerivedFrom("v8::internal::Object")) ) ), argumentCountIs(1) ) The "->" at the expression location was then rewritten to ".". R=miladfar@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I620c2104b649a75a01fd7a92dacadd652b23be7e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634931Reviewed-by:
Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#61921}
-
Milad Farazmand authored
Port f5ab7d38 Port 65f3861e Original Commit Message: In a new test suite: "wasm-api-tests", using a new binary "wasm_api_tests", powered by gtest/gmock (like unittests). Also fix a bunch of issues that these tests uncovered, mostly to ensure that the stack is walkable. R=jkummerow@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I9ec54193216d1b2024ee9c4f8f6dbda34bbf4586 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632354Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#61920}
-
Andreas Haas authored
The newly introduced select-with-type instruction is only available when anyref is enabled. R=clemensh@chromium.org Bug: chromium:967998 Change-Id: Idcb9ab447eedb93fe5374726da162ca1c79b3f16 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634927 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61919}
-
Michael Lippautz authored
AccessCheckInfo is a struct which is initialized with undefined values as placeholders. Update the definiton so that the verifier that could run between allocation and setting a field is happy. Bug: chromium:967433 Change-Id: I21b99645c01e109d7ba0b61a5366e1f66a7f98d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634922Reviewed-by:
-
Jakob Gruber authored
ArrayBuffer objects have a larger maximal size than TypedArray objects. The inspector TypedArray objects to preview ArrayBuffer objects; ensure we don't exceed the maximal size here. Bug: chromium:964663,v8:9308 Change-Id: Ia787ff87c799a3f2ca073e36cb54e57e86dacae9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634921 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Maya Lekova authored
According to the spec, in case where the property is non-configurable and non-writable, the value passed to the set trap should be compared to the data. Instead, the trap result was compared, because of the misleading name of the CheckGetSetTrapResult parameter. Regression was introduced in https://chromium-review.googlesource.com/c/v8/v8/+/1604071 Bug: chromium:966450 Change-Id: I77501980475da3aeb4f6153321da39e6fc2e6bd9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632238 Auto-Submit: Maya Lekova <mslekova@chromium.org> Reviewed-by:
-
Michael Hablich authored
TBR=machenbach@chromium.org NOTRY=true Change-Id: I1b095c0957f8cb4282bcd73993e2fd19631ffe86 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634925 Commit-Queue: Michael Hablich <hablich@chromium.org> Reviewed-by:
Michael Hablich <hablich@chromium.org> Cr-Commit-Position: refs/heads/master@{#61915}
-
Jakob Kummerow authored
So far, calls to Wasm C/C++ API functions reused the call descriptors of WasmImportWrappers, and the stack frame type of regular Wasm functions. This CL cleans that up by introducing separate implementations for both. No change in functionality or performance is expected. Change-Id: I79301fa81da52283cc776ddf19d4712372f3a58b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632235 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61914}
-
Andreas Haas authored
The proposal is changing accordingly, see https://github.com/WebAssembly/reference-types/issues/36. In our tests we were already using the new format implicitly, because bulk-memory-operations are enabled by default. I noticed the missing implementation when I executed spec tests with --no-experimental-wasm-bulk-memory. R=mstarzinger@chromium.org Bug: v8:7581 Change-Id: I13aaba9a8d60e8542245aac7f0a072da1be357dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631591Reviewed-by:
-
Jakob Gruber authored
The backtracking stack (which is actually a generic stack) used to be statically sized. At 10k elements, it was fairly large, but still easy to overflow on large subject strings. This CL changes it to a std::vector-based implementation instead which grows on-demand. Drive-by: Add braces to the BYTECODE cases to make clang-format produce a nicer output. Bug: v8:8776 Change-Id: If41a444fe3d05f6d5be1be019129788a86e6118b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634914Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#61912}
-
Clemens Hammacher authored
This removes two default switch cases for unsupported opcodes, and replaces them by explicit lists. This makes it easy to see what is currently not supported in Liftoff. In a follow-up CL, each bailout will be associated with a category to track which features currently cause Liftoff to bailout. This change also makes Liftoff crash (in UNREACHABLE) if invoked with asm.js code. Hence, change the asm.js tests to not test Liftoff. In production, we do not invoke Liftoff for asm.js anyway. R=mstarzinger@chromium.org Change-Id: I971c6146ed325103d14008c0e67a973a47a35bc2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634909 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Michael Starzinger authored
This is a reland of 8092acbe Original change's description: > [wasm] Store signature with {WebAssembly.Function} objects. > > This adds simple serialization and deserialization of the signature > provided when a {WebAssembly.Function} object is constructed. For now > this signature is only used by the {WebAssembly.Function.type} method, > but will soon be used when importing such functions as well. > > R=jkummerow@chromium.org > TEST=mjsunit/wasm/type-reflection > BUG=v8:7742 > > Change-Id: If4a687ea537d8c12f4f01a7d3ac5a795ceb999c6 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632211 > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61898} Bug: v8:7742 Change-Id: I5d784165c460abd9d7b07f5cdafc746d5380ccd6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632159Reviewed-by:
-
Yu Yin authored
see https://crrev.com/c/1630678 that patch modify this by mistake. Change-Id: I7db0205a08beff3f7e6372d62dd810ef859c9fcc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1633932 Auto-Submit: Yu Yin <xwafish@gmail.com> Reviewed-by:
-
Benedikt Meurer authored
Also generally cleanup the Copy* code in elements.cc a bit. Bug: v8:9183 Change-Id: I4a56db1f0b382a4b9583cae3b47e4ce572393d9e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634249Reviewed-by:
-
Georg Neis authored
There's a still a bug in the serializer related to resumables. I know what the problem is but I may not have time to prepare a fix this week. Given that --future is enabled on some canaries, let's exclude --concurrent-inlining for now. Bug: v8:7790 Change-Id: I78331ae423239ee7f0417a49e9eb58601a9a1590 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634189 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#61907}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/4cebfa3..c93f946 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/a7b3312..5db62d3 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/26af0d3..b97d193 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/fe8ba88..64bb071 TBR=machenbach@chromium.org,sergiyb@chromium.org,tmrts@chromium.org Change-Id: I74025ba882b945cb2aeae34e9390a4426b8a5a8a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1633599Reviewed-by:
-
Georg Neis authored
A given target offset may already have an environment associated with it (there can be multiple jumps to the same target). In that case we used to throw away the previous environment. With this CL we merge the environments instead. Bug: v8:7790 Change-Id: I0c22182436fc48e29675e49627729a33cbeaaf4d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631603 Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#61905}
-
Georg Neis authored
Kill the environment when encountering Throw, Rethrow or Abort, because the following code may be dead. Also add support for the SwitchOnSmi bytecode. Bug: v8:7790 Change-Id: Ia925aec854fea031be1df88a6a924e4b0d0406e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631602 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
-
- 28 May, 2019 6 commits
-
-
Ross McIlroy authored
On Android libraries there are zero length entries within the ranged symbols which break our range processing. This updates the logic to only add entries for zero-length entries if they aren't within the range of the previously added entry. Change-Id: I511a6221817c535d967a50413948a29d9deb1e85 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627985 Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#61903}
-
Ross McIlroy authored
On Android we load the native library directly from the APK. As such, we need to convert symbols from the mapped APK to the underlying .so when symbolizing the ticks. This CL adds a --apk-embedded-library argument to tick processor to enable specifying which unstripped library file was embeded in the APK and enable symbolizing. Change-Id: Ic992825b831f984a1217eed71847bdb158eb992b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627546 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Seth Brenith authored
If we need to build an icu::UnicodeString for a string that is currently in one-byte representation, we first have to expand the string's content into a two-byte representation. Doing so involves allocating an array, which is slow. With this change, we can convert short strings on the stack instead to save time. The cutoff length for what counts as "short" is pretty arbitrary, but we believe many strings fit into an 80-column line. This increases the score of cdjs in JetStream 2 by 35% on my machine, because cdjs is basically a test of localeCompare throughput. Bug: v8:9305 Change-Id: Iba081ac5a8fa7659edf06ac97ba8acf3f8328d59 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630848 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
-
Peter Marshall authored
These are unused and unmaintained, there are probably a lot of paths by now which don't funnel through this, so remove them. Bug: v8:9183 Change-Id: I4b48034e396b3ee481ae87283ab9a860f2f41d1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632155 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
-
Michael Starzinger authored
This reverts commit 8092acbe. Reason for revert: Causes UBSan warnings: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/6436 Original change's description: > [wasm] Store signature with {WebAssembly.Function} objects. > > This adds simple serialization and deserialization of the signature > provided when a {WebAssembly.Function} object is constructed. For now > this signature is only used by the {WebAssembly.Function.type} method, > but will soon be used when importing such functions as well. > > R=jkummerow@chromium.org > TEST=mjsunit/wasm/type-reflection > BUG=v8:7742 > > Change-Id: If4a687ea537d8c12f4f01a7d3ac5a795ceb999c6 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632211 > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61898} TBR=jkummerow@chromium.org,mstarzinger@chromium.org Change-Id: I56ea9df5db3f95c05068186097e298cb73a3675d No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7742 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632218Reviewed-by:
-
Michael Starzinger authored
This adds simple serialization and deserialization of the signature provided when a {WebAssembly.Function} object is constructed. For now this signature is only used by the {WebAssembly.Function.type} method, but will soon be used when importing such functions as well. R=jkummerow@chromium.org TEST=mjsunit/wasm/type-reflection BUG=v8:7742 Change-Id: If4a687ea537d8c12f4f01a7d3ac5a795ceb999c6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632211Reviewed-by:
-
