- 30 Jan, 2019 1 commit
-
-
Sven Sauleau authored
We noticed that almost every call site were loading both files, the split isn't necessary anymore. In some message tests, removed the absolute line number to allow future changes. Bug: v8:8726 Change-Id: I8527f0a1ecfa685aa01a5e2f5f47ddf1cb13a545 Reviewed-on: https://chromium-review.googlesource.com/c/1446452 Commit-Queue: Sven Sauleau <ssauleau@igalia.com> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#59220}
-
- 25 Oct, 2017 1 commit
-
-
Andreas Haas authored
This reverts commit 361bb1a0. Reason for revert: See https://crbug.com/v8/6981 BUG=v8:6981 Original change's description: > [test] Refactor assertPromiseResult > > This patch introduces assertPromiseFulfills and assertPromiseFulfills as > a replacement for assertPromiseResult because it’s more JavaScript-y. > > BUG=v8:6921 > R=ahaas@chromium.org > > Also-By: ahaas@chromium.org > Change-Id: I2f865dba3992ddf3b58987bf0b376d143edb5c31 > Reviewed-on: https://chromium-review.googlesource.com/718746 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48578} Change-Id: Ie760d2422451f16acc616aae001fe9fd18bf5cd4 Reviewed-on: https://chromium-review.googlesource.com/738249Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#48936}
-
- 16 Oct, 2017 1 commit
-
-
Mathias Bynens authored
This patch introduces assertPromiseFulfills and assertPromiseFulfills as a replacement for assertPromiseResult because it’s more JavaScript-y. BUG=v8:6921 R=ahaas@chromium.org Also-By: ahaas@chromium.org Change-Id: I2f865dba3992ddf3b58987bf0b376d143edb5c31 Reviewed-on: https://chromium-review.googlesource.com/718746 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#48578}
-
- 18 Apr, 2017 1 commit
-
-
mtrofin authored
Today, the semantics of: WebAssembly.instantiate and WebAssembly.compile().then(new WebAssemblyInstance) are subtly different, to the point where attempting the proposed change uncovered bugs. In the future, it's possible that .instantiate actually have different semantics - if we pre-specialized to the provided ffi, for example. Right now that's not the case. This CL: - gets our implementation closer to what developers may write using the compile -> new Instance alternative, in particular wrt promise creation. By reusing code paths, we uncover more bugs, and keep maintenance cost lower. - it gives us the response-based WebAssembly.instantiate implicitly. Otherwise, we'd need that same implementation on the blink side. The negative is maintenance: imagine if the bugs I mentioned could only be found when running in Blink. BUG=chromium:697028 Review-Url: https://codereview.chromium.org/2806073002 Cr-Original-Commit-Position: refs/heads/master@{#44592} Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb Review-Url: https://codereview.chromium.org/2806073002 Cr-Commit-Position: refs/heads/master@{#44669}
-
- 12 Apr, 2017 2 commits
-
-
hablich authored
Revert of [wasm] instantiate expressed in terms of compile (patchset #6 id:140001 of https://codereview.chromium.org/2806073002/ ) Reason for revert: Roll blocker: https://bugs.chromium.org/p/chromium/issues/detail?id=710824 Original issue's description: > [wasm] instantiate expressed in terms of compile > > Today, the semantics of: > > WebAssembly.instantiate > > and > > WebAssembly.compile().then(new WebAssemblyInstance) > > are subtly different, to the point where attempting the proposed > change uncovered bugs. > > In the future, it's possible that .instantiate actually have different > semantics - if we pre-specialized to the provided ffi, for example. > Right now that's not the case. > > This CL: > - gets our implementation closer to what developers may write using > the compile -> new Instance alternative, in particular wrt promise > creation. By reusing code paths, we uncover more bugs, and keep > maintenance cost lower. > > - it gives us the response-based WebAssembly.instantiate implicitly. > Otherwise, we'd need that same implementation on the blink side. The > negative is maintenance: imagine if the bugs I mentioned could only be > found when running in Blink. > > BUG=chromium:697028 > > Review-Url: https://codereview.chromium.org/2806073002 > Cr-Commit-Position: refs/heads/master@{#44592} > Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb TBR=bradnelson@chromium.org,ahaas@chromium.org,adamk@chromium.org,mtrofin@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:697028 Review-Url: https://codereview.chromium.org/2810203002 Cr-Commit-Position: refs/heads/master@{#44614}
-
mtrofin authored
Today, the semantics of: WebAssembly.instantiate and WebAssembly.compile().then(new WebAssemblyInstance) are subtly different, to the point where attempting the proposed change uncovered bugs. In the future, it's possible that .instantiate actually have different semantics - if we pre-specialized to the provided ffi, for example. Right now that's not the case. This CL: - gets our implementation closer to what developers may write using the compile -> new Instance alternative, in particular wrt promise creation. By reusing code paths, we uncover more bugs, and keep maintenance cost lower. - it gives us the response-based WebAssembly.instantiate implicitly. Otherwise, we'd need that same implementation on the blink side. The negative is maintenance: imagine if the bugs I mentioned could only be found when running in Blink. BUG=chromium:697028 Review-Url: https://codereview.chromium.org/2806073002 Cr-Commit-Position: refs/heads/master@{#44592}
-
- 09 Jan, 2017 1 commit
-
-
titzer authored
R=clemensh@chromium.org BUG= Review-Url: https://codereview.chromium.org/2595733003 Cr-Commit-Position: refs/heads/master@{#42141}
-
- 29 Apr, 2016 1 commit
-
-
titzer authored
[wasm] Binary 11: Swap the order of section name / section length. [wasm] Binary 11: Shorter section names. [wasm] Binary 11: Add a prefix for function type declarations. [wasm] Binary 11: Function types encoded as pcount, p*, rcount, r* [wasm] Fix numeric names for functions. R=rossberg@chromium.org,jfb@chromium.org,ahaas@chromium.org BUG=chromium:575167 LOG=Y Review-Url: https://codereview.chromium.org/1896863003 Cr-Commit-Position: refs/heads/master@{#35897}
-
- 07 Mar, 2016 1 commit
-
-
titzer authored
R=ahaas@chromium.org,binji@chromium.org BUG= Review URL: https://codereview.chromium.org/1770913002 Cr-Commit-Position: refs/heads/master@{#34559}
-
- 28 Feb, 2016 1 commit
-
-
titzer authored
R=binji@chromium.org,jfb@chromium.org BUG= Review URL: https://codereview.chromium.org/1740373002 Cr-Commit-Position: refs/heads/master@{#34346}
-
- 03 Feb, 2016 1 commit
-
-
bradnelson authored
Now that we have full fledged module instantiation, keeping alive a second interface seems clunky. Droping it and switching the tests. BUG= https://code.google.com/p/v8/issues/detail?id=4203 TEST=test-asm-validator,asm-wasm,other wasm R=titzer@chromium.org,aseemgarg@chromium.org LOG=N Review URL: https://codereview.chromium.org/1660083002 Cr-Commit-Position: refs/heads/master@{#33700}
-
- 12 Jan, 2016 1 commit
-
-
titzer authored
R=ahaas@chromium.org,bradnelson@chromium.org LOG=Y BUG=chromium:575167 Review URL: https://codereview.chromium.org/1577803002 Cr-Commit-Position: refs/heads/master@{#33251}
-
- 17 Dec, 2015 1 commit
-
-
bradnelson authored
In preparation for switching wasm from a compile to a runtime option, add the runtime flag to all mjsunit tests. R=ahaas@chromium.org BUG= Review URL: https://codereview.chromium.org/1537643002 Cr-Commit-Position: refs/heads/master@{#32938}
-
- 11 Dec, 2015 1 commit
-
-
titzer authored
As discussed in person, this adds the code from v8-native-prototype into V8 proper, guarded by GYP flags that do not build the code by default. Passing wasm=on to 'make' or setting v8_wasm as a GYP flag activates building of this code. An additional header file is added to and exported from the compiler directory, src/compiler/wasm-compiler.h. This exposes a limited interface with opaque Node and Graph types to the decoder to build TF graphs, as well as functions to compile WASM graphs. The mjsunit tests added are blacklisted because they fail without the WASM object exposed to JS, which is also disabled by the build config option. This corresponds closely to https://github.com/WebAssembly/v8-native-prototype/commit/5981e06ebc9b1e578831d03100f17ebb77970ee0, with some formatting fixes and moving some files into src/compiler. R=mstarzinger@chromium.org, bradnelson@chromium.org BUG= Review URL: https://codereview.chromium.org/1504713014 Cr-Commit-Position: refs/heads/master@{#32794}
-