...and not the browser's main thread. Those are different threads now since
6e6451ce96 "Emscripten: Move the Qt event loop off
the JS main thread". Running `Module.uno_init.then` on the browser's main
thread would never trigger, as that promise is only resolved on LO's main
thread.
When external code was included in soffice.js via
EMSCRIPTEN_EXTRA_SOFFICE_POST_JS, that didn't make a difference: Emscripten
effectively replicates that code to all the worker threads, so whatever worker
thread resolved the Module.uno_init promise (i.e., the LO main thread) had the
external code available and ran it. But when external code was included
directly in some HTML file (which "manually" provides a canvas and loads
soffice.js, not relying on the qt_soffice.html convenience functionality), it
was available in the browser's main thread but not in LO's main thread. For
that use case, introduce a new Module.uno_scripts array that can be set up in
the HTML file to contain an array of URLs (represented as strings) of scripts to
load into LO's main thread.
(Alternatively, running external code on the browser's main thread rather than
on LO's main thread could be more ideal in the sense that the external code
would then have access to the browser's document object. But, for one, it would
be less ideal in the sense that we would then potentially again execute LO code
(which we call into from the external code via UNO) on the browser's main
thread, which would bring back the issues that
6e6451ce96 "Emscripten: Move the Qt event loop off
the JS main thread" solved. And, for another, when I experimentally tried it
out, it caused massive Qt threading issues, so I quickly gave up again.)
Change-Id: If01a7859751706f168e93ccac75758ae5ce17cd2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171870
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...to have $(WORKDIR)/installation/LibreOffice/emscripten populated with just
the relevant files from $(INSTDIR). (This doesn't reuse the complicated
CustomTarget_instsetoo_native/install used for other PKGFORMATs; as a special
case, it uses a much simpler CustomTarget_instsetoo_native/emscripten-install.)
Change-Id: I9c7509aadbc0e6e49ec95bf51c748c2ff9f778b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171066
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...mostly because the relevant parts of the code are hard-disabled (even if you
would --disable-wasm-strip) with ENABLE_WASM_STRIP_RECOVERYUI=TRUE and
ENABLE_WASM_STRIP_SPLASH=TRUE. (And if there are places in the code that would
need the equivalent of either --norestore or --nologo after all, we could
probably better add explicit #if EMSCRIPTEN there instead.) This allows to get
rid of hard-coding the Qt Emscripten LO command line arguments, which means that
e.g. web applications embedding LO would now be able to specify them themselves.
Change-Id: I8e2dcfd170cc32276bfb9007f098f6ae6a7f9ec1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171063
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...as there can be situations (cf. the newly added test code in embindtest.js)
where objects that need to be deleted are passed as payload of the exception
value to be thrown. So there now is a (mandatory, as Embind doesn't allow to
implicitly pass undefined) third parameter now that must be an array of objects
on which to call .delete().
(75fe059974 "Embind: throwUnoException from JS"
had deliberately made throwUnoException take two arguments, because if it
"directly took a css::uno::Any argument, JS client code would need to create one
with `new Module.uno_Any(...)` and call .delete() on it, but there is no place
where it could call .delete()". There now would be such a place, but it would
probably still be tedious most of the time to explicitly construct a new uno_Any
to pass into throwUnoException both as the exception and in the toDelete array.
So keep that design decision to have throwUnoException take individual type and
value arguments.)
Change-Id: Idec029d9e500457b02d20d899b9a2328cd7a5d7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171024
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...and let it open with that instead of with a hard-coded example.odt. (But
keep that example.odt in CustomTarget,static_emscripten_fs_image and adapt the
example code in static/README.wasm.md to explicitly load it now.)
Change-Id: Ie43e3795e44542acba5a8e755f65acc56fa753f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171019
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...by keeping the worker threads around by default instead of joining and later
re-spawning them; see 5b1df7709d "Document the
Emscripten threads issue". But lets be cautious and change the bJoin default
only for Emscripten.
Also, cap the thread pool size to MAX_CONCURRENCY=4 and increase to
-sPTHREAD_POOL_SIZE=6. In an experimental setup where the Emscripten build
starts up with the start center rather than a Writer document, that is just
enough to cover the thread-spawning needs when executing the start center
window's paint task: Four threads for the comphelper::ThreadPool (used from
within drawinglayer::convertToBitmapEx -> ... ->
BitmapBasicMorphologyFilter::filter), and one each for
configmgr::Components::WriteThread (see e8358d0a0f
"Keep around a single configmgr::Components::WriteThread instance") and
salhelper::TimerManager.
Change-Id: I5b1d0e9dc09f05fb3b679c8dc1c38ee45c61c0f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171004
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...that is resolved from within C++ Desktop::InitApplicationServiceManager once
UNO is fully initialized, so client code can trigger on
Module.uno_init.then(...)
Change-Id: I2d4c542d9729d09f434502e3f966e9ee474e926c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170683
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
As we need to generate data upfront for all the UNOIDL entities anyway, we might
just as well extend that with annotations (keyed to some new
Module.unoTagSymbol) that are useful at runtime. The general idea is to let
such annotations be objects with certain well-known keys, the main one being a
string-valued `kind` representing the UNOIDL kind of the annotated data.
As a first thing, individual UNOIDL enum type enumerators are annotated with a
`type` representing the UNOIDL enum type they belong to. That turns out to be
useful for some experimental approach of mine where I wrap the Embind-based JS
binding in something that makes the result more idiomatic JS.
Change-Id: Iec466bab05ba3d1b56b2398e5c361465af49dc13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170398
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...after 875997c896 "Properly implement
cppu::throwException for Emscripten" had implemented only those parts that were
absolutely necessary for that exception throwing. As detailed in the commit
message there, wasmcallgen has been extended to additionally generate all the
required vtable slot call trampoline code (which cannot be generated on the fly
for Wasm, as would be done for other platforms). Consequently, some of the
"callvirtualfunction"-centric file names have been changed to "generated" as the
output of wasmcallgen is now more general. (And wasmcallgen itself should also
be renamed, in a follow-up commit. And when adding to the wasmcallgen code
here, some existing parts of its implementation have been cleaned up, too.)
There is no direct way to test this half of the Wasm UNO bridge directly from
unotest/source/embindtest/embindtest.js, so a new
org.libreoffice.embindtest.BridgeTest singleton has been added, which triggers
new test code in unotest/source/embindtest/embindtest.cxx that tests the bridge
in a way similar to testtools' bridgetest machinery.
Change-Id: I521a1d6c2160aedc814f7603b0b99861e5fbd1eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170374
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...by implementing (for now) just enough of the cpp2uno half of the Wasm UNO
bridge to make it work. In general, that half suffers from the same issue as
the already-implemented uno2cpp half, namely that Wasm doesn't allow to generate
code on the fly (which, in this case, would be needed to implement the vtable
slot trampoline functions). So, for now just hard-code the few
vtableSlotFunction_* that are needed by the UNO interfaces for
cppuhelper/source/exc_thrower.cxx. (A proper fix would probably use the same
approach as for the uno2cpp half, and use something like wasmcallgen to generate
at least all the vtableSlotFunction_* needed for udkapi/offapi upfront.)
The RTTI for the exceptions needs to be unique across the executable for
exception catching to actually work (as it compares exception types by RTTI
address rather than by name). We thus need to export all the relevant RTTI
symbols (which I hacked into the existing wasmcallgen for now, even if that
makes that executable's name a slight misnomer now), and access them with a new
jsGetExportedSymbol. (This exporting would also be needed by the "classical"
approach of using dlsym on the main module, cf.
<https://gerrit.libreoffice.org/c/core/+/167187> "WIP: Emscripten: Set up
support for dlsym from main module". And while that dlsym approach would work,
it is much simpler to just use that jsGetExportedSymbol than to use a dlsym
detour, and thereby avoid all the hassle of -sMAIN_MODULE detailed in the commit
message of that Gerrit change.)
It also turned out that including Emscripten's <cxxabi.h> needs
__USING_WASM_EXCEPTIONS__ to be defined, because it uses that in its declaration
of __cxa_throw. (The source for setting that define internally in Emscripten is
get_cflags in the emsdk's upstream/emscripten/tools/system_libs.py, which
defines __USING_EMSCRIPTEN_EXCEPTIONS__ for the non-Wasm, Emscripten JS
exception mode, and defines __USING_WASM_EXCEPTIONS__ for
--enable-wasm-exceptions, which we use. The commit message of
f4ec967599 "Fix redefinion of Emscripten
__cxxabiv1::__cxa_exception" documents my prior confusion of when one or the
other would be defined.)
Change-Id: Id08765ab5b4ce1553dc3a61648324526185cb64c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170246
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...with a new Module.catchUnoException JS function that can be used in a JS
catch block to provide the thrown UNO exception as an Any. (For a non-C++
exception, it rethrows the exception, and for a non-UNO C++ exception it maps it
to css.uno.RuntimeException.)
The implementation reuses parts of bridges/source/cpp_uno/gcc3_wasm/, which have
been moved to a new StaticLibrary_emscriptencxxabi.
Change-Id: I708fe6121c43a1b9736de5dff449f6c4f32a45f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169325
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
When a JS function implementing a UNO interface method returns any or a sequence
type (like queryInterface, getType, and getImplementationId in uno.js), it
could not create a new instance of that type and return it, as it would have
needed to call .delete() on that instance, but couldn't. In uno.js, getType and
getImplementationId solved that by returning pre-instantiated instances that
were deleted in the final release call. But that did not work for
queryInterface, as pre-instantiating the relevant any instances would have
caused cyclic references that would have caused the final release call never to
occur.
So redesign the C++ the_wrapper classes (used by the Embind allow_subclass
machinery): If a UNO interface method returns any or a sequence type (i.e., a
type on which .delete() must be called), change the JS implemenation's return
type from by-value (which meant that the C++ code received a copy) to
by-reference---which means that now the C++ code can access the original
instance and delete it. But which also means that the JS code must always
return a fresh instance now!
(Ideally, the embindmaker-generated code would use by-pointer rather than
by-reference for that return type, but that caused
> emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:116:19: error: static assertion failed due to requirement '!std::is_pointer<com::sun::star::uno::Any *>::value': Implicitly binding raw pointers is illegal. Specify allow_raw_pointer<arg<?>>
> 116 | static_assert(!std::is_pointer<T*>::value, "Implicitly binding raw pointers is illegal. Specify allow_raw_pointer<arg<?>>");
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
errors with no obvious place where to put such allow_raw_pointer markers, so
lets go with this little hack at least for now.)
Change-Id: I3c37b79b8fbf09c19782c6532bc95d4d63505c63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169008
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...and confine the _impl map to an internal detail. Client code should have no
need to access that _impl map (renamed here to impl_interfaces), nor the
Module.uno_Type_*.reference functions (nor the Module.uno_Type_*.implement
functions).
Change-Id: Ic9c74f22cedb9b5eeecb42d7c13ee0555e92690d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168732
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...so that the unoObject function can be moved there too (so that other code
outside embindtest.js can reuse it)
Change-Id: Id3edb7cede56321db29ba435f221cb7702a3513c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168700
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...that proved useful in experiments wrapping a JS Proxy around the Embind
representation of C++ UNO objects.
Change-Id: Ia4018ec8dee2c222fb76ba8e2f529f4845f0134c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168518
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
* Consistently use `const` to introduce variable bindings.
* Don't rely on `xText` from the first example in the second one.
* No (more) need to query for base interfaces.
* No (more) need to delete interface references.
* Add a missing delete of Any `next`.
* Remove a redundant empty line.
* Adapt to our 100 character line width.
Change-Id: Ie116021a4b0cc6d88c6204e7ea5147a837c251f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168405
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
(...which will be beneficial, in turn, to implement exception handling in the
work-in-progress bridges/source/cpp_uno/gcc3_wasm UNO bridge).
As per
<https://developer.mozilla.org/en-US/docs/WebAssembly#browser_compatibility>,
Wasm exceptions appear to be supported by most if not all relevant engines by
now.
* Lets see whether the "Note that to really use WASM exceptions everywhere" for
external libraries in solenv/gbuild/platform/EMSCRIPTEN_INTEL_GCC.mk does have
any practical consequences (but ignoring it for now).
* This change depends on the preceding 77129fbb74
"Emscripten: Add hack to prepare for --enable-wasm-exceptions" to work around
the issue that was mentioned in static/README.wasm.md.
* In unotest/source/embindtest/embindtest.js, getExceptionMessage started to
work now, no longer exhibiting the RuntimeError that had been documented there
for non-Wasm-based exceptions.
Change-Id: Ifa2165b62208cc927844684911ddf21a4a2b624f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168169
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
(...which will be beneficial, in turn, to implement exception handling in the
work-in-progress bridges/source/cpp_uno/gcc3_wasm UNO bridge).
Once setting --enable-wasm-exceptions, plus the corresponding
-sSUPPORT_LONGJMP=wasm in qt5, I indeed started to see the "RuntimeError: null
function or function signature mismatch" that was already mentioned in
static/README.wasm.md. I could track it down to the early destruction of the
aDesktop local variable in soffice_main, as I now explain there. However, it
beats me why that variable gets destroyed early. The desktop::Desktop::~Desktop
dtor claims to be called from within main -> soffice_main ->
desktop::Desktop::~Desktop, but at a time when the call to main -> soffice_main
-> SVMain has not yet returned. There also does not appear to be any C++
exception handling stack unwinding going on. (It could be related somehow to
-sSUPPORT_LONGJMP=wasm, I don't know.) And everything appears to just work fine
after turning that aDesktop local variable into a (leaked) heap instance
instead, so go with that hack for now...
Change-Id: I8e00c988ee9a44fd3befbe41c844eec050f0e509
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167694
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...by making the general UNO -> C++ function call case work (modulo handling
exceptions, which I'll look into later).
Wasm call_indirect unfortunately needs to statically know the call target's
signature, so we statically need to know all possible signatures. So introduce
wasmcallgen helper to scan the existing UNOIDL API upfront and generate the
relevant callvirtualfunction-wrapper.cxx and callvirtualfunction-inst.s code.
(The good thing is that the number of different signatures is somewhat limited,
each parameter can only be one of i32, i64, f32, or f64. So even if 3rd-party
extensions bring along new UNOIDL interface methods, chances are relatively high
that the signatures needed for them would already be covered by the existing
ones.)
Testing this can nicely be done in unotest/source/embindtest/embindtest.js via
css.script.Invocation (which internally exercises the relevant code). (Instead
of adding individual org.libreoffice.embindtest.StructLong/String etc., it would
be nicer to introduce some polymorphic StructOne<T>, but the Emind UNO binding
does not support polymorphic structs, so the embindtest.js code would not work.)
Change-Id: If829c9e3772bfd27561f3ad743d38a71d11545b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167308
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
...by using UnoInOutParam in all cases. Some types whose Embind mappings don't
employ any smart pointers (like any and sequence) would have worked directly
with pointers, but others (like string and type) would have caused Embind errors
at runtime. So consistently use UnoInOutParam in all cases (and generate
bindings for all the used cases in embindmaker).
Change-Id: If26551bf4e99d10748aec1597d6e99f994dfd86e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166854
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
(the types that are meant to be passed directly by pointer will need more
thought, to make them actually work)
Change-Id: Ia0f2e6f5335fad1140629477e89fc96121c2927e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166318
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
$equals was the last remaining special $... method that we added to the UNO
interfaces, and it looks better anyway to turn it into a symmetric free function
(that can be called with null for either argument) that is actually independent
of specific interface types
Change-Id: I22a1d08b8b15a0ed2dd37fa9fbc95f568641dec3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166317
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...which are needed at compile time (the emscripten::class_<T> ctor always
records the address of emscripten::internal::raw_destructor<T>, even in cases
where it never calls it; and raw_destructor internally calls delete, but the
dtor of the UNO interface types is protected) but not at runtime (as those UNO
interface types are only accessed through css::uno::Reference smart pointers)
Change-Id: I09e4f258f8dfc0fc53c0fe7210c7f709d86be176
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166304
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
The existing code had two issues: For one, e.g. calling a function that
returned a null interface reference mapped that to JS null, while querying an
object for a non-supported interface via `new css.uno.X...(y)` mapped that to
an "empty" JS object instead. (So checking for a non-null reference needed to
be done as either `x !=== null` or as `x.is()`, depending on context.) And for
another, while calling $is() on a non-"empty" object worked fine, it failed on
such an "empty" object (as the Embind internals of that object lacked the $$
property).
So change the querying mechanism from the `new css.uno.X...(y)` constructor to a
`css.uno.X....query(y)` function call syntax, which now returns JS null when
querying for a non-supported interface. (And drop the broken $is method.)
Change-Id: I8fa488ab2892423f2a461d9b72db47e1d4df3b8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166255
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
(If throwUnoException directly took a css::uno::Any argument, JS client code
would need to create one with `new Module.uno_Any(...)` and call .delete() on
it, but there is no place where it could call .delete(), so make
throwUnoException take two arguments instead and assemble the css::uno::Any on
the C++ side.)
Change-Id: Iae4ae6af804354d5cf752115e272b79d61427440
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166253
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Given the reasoning in 0957ee9f5d "Embind: No need
for $query", those sharing_policies appear to be (solely) about upcasting of
those smart pointers, and css::uno::Type doesn't involve any class hierarchies,
so NONE ("no upcasting", in genericPointerToWireType in Emscripten's
src/embind/embind.js) appears to be the best match here.
Change-Id: I74b74d3c31cc17a7fd0a6d072160316e60884557
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166160
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...to "upcast" from css::uno::Reference<T> to base
css::uno::Reference<css::uno::XInterface>. My understanding now is that due to
the sharing_policy::INTRUSIVE we specify for
emscripten::smart_ptr_trait<css::uno::Reference<T>>
(include/static/unoembindhelpers/PrimaryBindings.hxx), Embind can internally
"upcast" from a css::uno::Reference<T> to a base
css::uno::Reference<css::uno::XInterface> by just treating the encapsulated raw
pointer of type T* as a raw pointer of type css::uno::XInterface* (see the use
of that sharingPolicy in genericPointerToWireType in Emscripten's
src/embind/embind.js; though documentation of that Embind sharing_policy is
rather poor).
Change-Id: I6ed60a9c94af6aba6fc6119bf644da7f507a997f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166142
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Stephan Bergmann