- 11 Dec, 2018 1 commit
-
-
Clemens Hammacher authored
This callback is not being used by now, so we can just change it without the deprecation dance. Instead of the WasmModuleObject, it now receives the new CompiledWasmModule wrapper which contains a shared pointer to the NativeModule. This is all that's needed for serialization. Some classes are pulled out of WasmModuleObject to allow reuse. R=adamk@chromium.org, mstarzinger@chromium.org CC=bbudge@chromium.org Bug: chromium:912031 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Icedb64efa92e66bec45cf8742942a07ae22f59c8 Reviewed-on: https://chromium-review.googlesource.com/c/1363140Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Bill Budge <bbudge@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58142}
-
- 05 Dec, 2018 1 commit
-
-
Clemens Hammacher authored
A WasmModuleObject represents an instance of WebAssembly.Module. It is called WasmModuleObject internally, so also use that name externally. We still have a typedef for WasmCompiledModule which will be deprecated once chromium has been updated to use WasmModuleObject. R=titzer@chromium.org, adamk@chromium.org Bug: v8:8238, chromium:912031 Change-Id: I2d7708d4dc183cb4f4714f741b1ea0c153014430 Reviewed-on: https://chromium-review.googlesource.com/c/1362048Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58055}
-
- 21 Jun, 2018 1 commit
-
-
Clemens Hammacher authored
The name {CallerOwnedBuffer} does not make sense in all situations, especially if such an object is returned instead of being passed as argument. I am working on moving the wasm wire bytes off the JS heap, and hence will return unowned references via the API. To prepare this change, I deprecate the existing {CallerOwnedBuffer} and introduce a new {BufferReference} struct with proper field names. R=titzer@chromium.org, adamk@chromium.org Bug: v8:7868 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Ic8953951447038a831b15a336a52a199bfbeafd5 Reviewed-on: https://chromium-review.googlesource.com/1108207Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53929}
-
- 09 Nov, 2017 1 commit
-
-
Karl Schimpf authored
Like CSP flag 'unsafe-eval', which communicates if both JS source files and WASM binary files may be compiled, this CL adds a similar flag for the compilation of WASM binary files. That is, a WASM binary file will be compiled only if the new flag is defined, or the flag for 'unsafe-eval' allows it. These flags are implemented as callback functions on the isolate. The callbacks get a (CSP) context, and a string, and returns the corresponding value of the flag. Both callbacks are initialized with the nullptr, and is used to communicate that no CSP policy is defined. This allows this concept to work, independent of it running in Chrome. It also does a small clean up in api.cc to use macro CALLER_SETTERS, instead of explicit code when appropriate. Bug: v8:7041 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Idb3356574ae2a298057e6b7bccbd3492831952ae Reviewed-on: https://chromium-review.googlesource.com/759162Reviewed-by: Bill Budge <bbudge@chromium.org> Reviewed-by: Eric Holk <eholk@chromium.org> Commit-Queue: Karl Schimpf <kschimpf@chromium.org> Cr-Commit-Position: refs/heads/master@{#49243}
-