...taking a full UNO Type instead of just a UNO Type class (so that it will be
able to construct Any containing sequence, enum, struct, exception, and
interface, in later steps); moving the Type argument first (as that looks more
natural), and renaming from Any to uno_Any (in line with the other uno_Type,
uno_Sequence_..., etc.)
Change-Id: I154681c4b9187f5f5d037d503652fe7bcd41adcd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164593
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...where it failed with
> In file included from static/source/unoembindhelpers/PrimaryBindings.cxx:13:
> In file included from ~/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:23:
> ~/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/val.h:226:20: error: assigning to 'void *' from 'const void *' discards qualifiers
> 226 | cursor->w[0].p = wt;
> | ^~
> ~/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/val.h:248:3: note: in instantiation of function template specialization 'emscripten::internal::writeGenericWireType<const void>' requested here
> 248 | writeGenericWireType(cursor, BindingType<First>::toWireType(std::forward<First>(first)));
> | ^
> ~/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/val.h:256:5: note: in instantiation of function template specialization 'emscripten::internal::writeGenericWireTypes<const void *>' requested here
> 256 | writeGenericWireTypes(cursor, std::forward<Args>(args)...);
> | ^
> static/source/unoembindhelpers/PrimaryBindings.cxx:309:56: note: in instantiation of member function 'emscripten::internal::WireTypePack<const void *>::WireTypePack' requested here
> 309 | emscripten::internal::WireTypePack argv(self.getValue());
> | ^
see the comment at
<https://github.com/emscripten-core/emscripten/commit/0f83fd40533248cce42464e1b9b586281202f247#r139443236>
"[Wasm64] Fix embind with addresses over 4gb (#20071)"
Change-Id: I1f472e9dc57b3abfbe1ba8a0f3a3bd70c1c484f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164463
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...which taps into the internals of emscripten::val, which is based on
std::type_info identifiers, so we need an additional statically-built mapping
between UNO (enum, for now) types and std::type_info
Change-Id: I9fc1ff33fe31a1e1052504905de446ed2193e014
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164359
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...which should be rare enough in practical use that it should be sufficient to
only have toString-functionality for instances mapped from C++ to JS, but no
constructor for new instances on the JS side. (The natural choice for the
latter would be a mapping of the C++
> inline Type( TypeClass eTypeClass, const ::rtl::OUString & rTypeName );
constructor, but which requires a mapping for the css::uno::TypeClass UNOIDL
enum, which is only provided "later" through CustomTarget_static/unoembind, so
would at least conceptually be a bit dirty.)
This Embind mapping treats css::uno::Type as a smart pointer for the underlying
typelib_TypeDescriptionReference, to benefit from the fallback garbage
collection (in more recent Emscripten versions, at least) for smart pointers,
obviating the need to call .delete() on each instance mapped to JS.
Change-Id: Ic113967c264c28641dfd1fe159012c85519f4a9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164140
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
The constants are only reflected directly as JS values in the generated *.js
file. Reflecting them via emscripten::constant in the generated *.cxx did not
work well: Most importantly, emscripten::constant (and its underlying
_embind_register_constant) coerce all values to double, so UNO (unsigned) hyper
would not survive as JS BigInt, which would then cause e.g.
> console.assert(test.isHyper(uno.org.libreoffice.embindtest.Constants.Hyper));
passing such a (JS number, not BigInt) value into the
org.libreoffice.embindtest.XTest::isHyper method (which expects a UNO hyper) to
fail. (Also, constants of UNO boolean type would be represented as numbers 0/1
rather than as false/true.)
Change-Id: I056db0ccce0bf40eb53728fd439cc74964eb6951
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164097
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Upcoming code that changes the Embind'ing of UNO sequences will require
availability of the UNO type manager during that Embind init code, so only call
that after UNO has been bootstrapped (rather than as part of the initialization
of global static data, which is what EMSCRIPTEN_BINDINGS does).
Change-Id: Iba19851ffb82c055dcab10a28a8c1fafa9d2a414
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164065
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
80d3f33876 "Library_embindtest should use
comprehensive InternalUnoApi_embindtest" was an attempt at making type
information about that library available at runtime. Which worked for cases
where code directly called one of the types' cppu_detail_getUnoType function.
But it would still fail for cases where code indirectly wants to obtain one of
the types' information by type name---which is what upcoming code will do that
changes the Embind'ing of UNO sequences.
So InternalUnoApi_embindtest would need to become a UnoApi_embindtest whose
instdir/program/types/embindtest.rdb would be available at runtime. But I'm too
dumb to convince gbuild to create that new UnoApi_embindtest. So instead just
tack the embindtest UNOIDL entities onto the existing UnoApi_udkapi for the
EMSCRIPTEN-ENABLE_DBGUTIL case. (Which requires that the single embindtest.idl
is split into individual per-entity files, sigh.)
Change-Id: Ie189b17213ac5b2de7a61ac5f97a143fa097337f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
It is only built for --enable-dbgutil builds. Load
instdir/program/qt_soffice.html in a browser and see "Running embindtest" in its
console. For now, it only contains a Test singleton with an empty XTest
interface, which is meant to grow additional methods over time.
(The code needs to reside in the unotest rather than in the static module, or
else the wasm build would run into cyclic dependencies.)
Change-Id: I6f65f0c904648a4fd96fc6215c8d59a1544f48a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163693
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...though
> let seq = new Module.uno_Sequence_string(["foo", "bar", "baz"]);
> // ...
> delete seq;
is still ugly.
And Embind only allows for overload resolution by number of parameters, not by
their type, so using the original sequence constructor had to be changed to
> let seq = new Module.uno_Sequence_string(3, Module.uno_Sequence.FromSize);
> seq.set(0, "foo");
> seq.set(1, "bar");
> seq.set(2, "baz");
> // ...
> delete seq;
Change-Id: If26ff4a485ba16b65cf24b6fe729d379c733c473
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163097
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Ideally, JS code would have a way to create instances of arbitrary UNO sequence
types (to e.g. put them into Anys), but that goes against the static nature of
Embind. So at least register JS support for all those UNO sequence types that
are actually used in the UNO API. (This would cause duplicate failures, though,
if we generated multiple separate .cxx files from embindmaker invocations, with
registration code for the same UNO sequence types.)
(Even more ideally, UNO sequence types could map to JS arrays, and/oror be
garbage-collected on the JS side rather than needing explicit delete(). The
resize/size/get/set interface in unoembindhelpers::registerSequence is modelled
after Embind's emscripten::register_vector.)
Change-Id: Icd38b2e03db442dd613b9222b9bd092f947f7bec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162849
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...to harmonize with the other existing uno_Type_... etc. names, and with
upcoming uno_Sequence_... names. (And template'ize the registration code.)
Change-Id: I5dace5bc643ab636977fde84fa51825efc5cafa5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162838
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...to make use of the automatic finalization clean-up of smart pointers
available with recent versions of Embind (so that explicitly calling delete() on
them should largely be optional now). See the changes to static/README.wasm.md
for how code should look like now. (The Module.uno_Reference.FromAny dummy
argument for the interface constructor converting from an Any is only necessary
to distinguish it from the other constructor, as otherwise Embind complains
because: "Overload resolution is currently only performed using the parameter
count, not actual type info!")
Change-Id: Ia8a8c12e38af1093948bf8a20ecd31aa6591e912
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162697
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
What I'm after in the context of our Embind-related code is the claim at
<https://emscripten.org/docs/porting/connecting_cpp_and_javascript/embind.html#memory-management>:
"JavaScript only gained support for finalizers in ECMAScript 2021, or ECMA-262
Edition 12. The new API is called FinalizationRegistry and it still does not
offer any guarantees that the provided finalization callback will be called.
Embind uses this for cleanup if available, but only for smart pointers, and only
as a last resort." However, with the recommended emsdk 2.0.31 my tests did not
show any use of that finalization support. So I wanted to try with the latest
emsdk 3.1.51 instead. But then, linking vcldemo failed with
> wasm-ld: error: ~/allotropia-qt5/lib/libQt5Core.a(qlogging.o): undefined symbol: std::__2::__vector_base_common<true>::__throw_length_error() const
etc., so I gave it a try to rather build against latest Qt6.7, with
> --with-distro=LibreOfficeWASM32
> --disable-qt5
> --enable-qt6
> QT6DIR=...
TODO: The result is highly experimental, and it uses ENABLE_QT5 (i.e., the
recommended setup with emsdk 2.0.31 and the
<https://github.com/allotropia/qt5.git> v5.15.2+wasm branch) vs. ENABLE_QT6
(i.e., my experimental setup with emsdk 3.1.51 and the
<https://github.com/qt/qt5.git> 6.7 branch) not only to distinguish between Qt5-
vs. Qt6-specific behavior, but also to distinguish between old- vs.
new-Emscripten-specific behavior. Of note:
* The startup code appears to have changed substantially (and required setting
-s MODULARIZE=1 and -s EXPORT_NAME=soffice_entry now, and telling emcc to
build just soffice.js and not the wrapper soffice.html. TODO: This also
required hacking into qt_soffice.html: (1) The command-line arguments
(--norestore, --nologo, --writer, and the exammple.odt; all of which we should
eventually get rid of, anyway). (2) Saving the generated instance as
window.Module (and adapting the embindmaker-generated code, cf. the changes to
static/README.wasm.md).
* There were some symbol clashes between external/argon2 and
libQt6Core.a(qcryptographichash.cpp.o, so renamed the problematic symbols in
external/argon2.
Change-Id: I5420ab566d560b11954ac6613249bfc53d8acb31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162695
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...workdir/CustomTarget/static/unoembind/bindings_uno.cxx, reducing an otherwise
no-op build for me (against emcc 3.1.51) from multiple hours to "just" 3 min
wall-clock time.
Change-Id: Ic6477134b72f9d28cc3193fb514ceaa32b84209c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162666
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Stephan Bergmann