Age | Commit message (Collapse) | Author |
|
Change-Id: Ibe6cbbd618aab5c145913235dc90fec3c98cd504
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169723
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...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>
|
|
Change-Id: I6f6e06ad32ffa87242f5a0f41c176149b754e2ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169187
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
|
|
Change-Id: Ied532cf271644f424fbf9661a0b8d246124ca324
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168689
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
|
|
Change-Id: Ic30d2de582f952555ec672984da78a07a9319443
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168224
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
|
|
(Without 22ce8ed05be37d676739a578b05cc5217109fd87 "Emscripten: Unconditional
--enable-wasm-exceptions", this would have failed to link due to missing
__cxa_current_exception_type and __cxa_get_globals.)
Change-Id: If89a3c62e4d2ac24d68f867b2fd7a4cd813d5a39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168176
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 77129fbb74bcefde4551d494f029169e7c6026e3
"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>
|
|
(and add a console.assert(false) to verify that an exception actually gets
thrown)
Change-Id: I885301a5730b54c817c8a9ed97e60f49f8c8baf9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168149
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
|
|
Change-Id: I9f399b3752da9df930e0647536ffcd4e82beb1ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167856
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ieabea4a0ddf8f95ea01b8b0275be0924ad055694
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167524
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I5ac6013d6c0bd72fe840a592628fd0d5b265b8ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167391
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
|
|
...which had caused an additional getNull/isNull check for
a469aea9c0b532d928cd41e389c9c51de1af06f0 "Emscripten: Towards a working C++ UNO
bridge" to fail
Change-Id: Ibe87ca05f795253c9ede8cab6f96da8fe4496f87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167344
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...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 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>
|
|
Change-Id: I23265f46b25cb88796267abe28aac1100523e71b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166298
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>
|
|
The note at
<https://emscripten.org/docs/porting/exceptions.html#handling-c-exceptions-from-javascript>
is a bit vague whether decrementExceptionRefcount would only be needed for
Wasm-based (-fwasm-exceptions) exceptions, or also for the JS-based
(-fexceptions) ones that we currently use. (But it does state clearly that for
the latter we need to manually call incrementExceptionRefcount first.)
Change-Id: I7714935607c990385f68730d02e367e70fa0ea03
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166250
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
We don't need a dedicated implXInterface, any other interface derived from it
works as well. But we should arguably implement css.lang.XTypeProvider. Which
in turn requires two sequences, which need to be eventually .delete()'ed, so add
impl* for them. And while at it, rename refcount to implRefcount for
consistency.
Change-Id: I8cfd0df74058383bd432e2a6a86f7f2039a87ffb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166181
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>
|
|
Change-Id: I3a8bf5986b91b886547cfe57e49275f7c79ddc11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166020
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...so it will be able to use e.g. css.task.XJob in its tests
Change-Id: I15e50c07ee4b1b315d2687dc7e7ea0c00ccc638c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165998
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I985562995714c04c569e3a794cf748443ed02865
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165886
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
As UNO exceptions are not derived from std::exception in C++, the corresponding
JS object's name property is present but has undefined value. And the UNO
Message property is not present at all.
Change-Id: Ibe152377e5970faa8a518c77b5171d9f3c160f38
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165885
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I43d924126f4d34e0efbcea61dd5f4bd9be235426
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164650
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I1b2167e261f1020b228f8ca2618c7f0009ca1d3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164646
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...now that all the relevant Any getter functionality is available
Change-Id: I5824dd50d177506b0450506146df109ded7e20d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164588
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Iac5ac8de7bfb19b90d54edc6f4b791d8c0e98977
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164594
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...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>
|
|
Change-Id: Id93d7f48dedb362206828b5e3bd946525f95ea77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164590
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Ia56439e0e99c193c7cc56676677df2c671278e24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164554
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...so that the Exception's Message is something like "error at
unotest/source/embindtest/embindtest.cxx:271" instead of just plain "error"
Change-Id: I3b236dc91cc75f859000a2283f04413fcbbd6b39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164470
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Ief3cdebc1ee7c7b9f012741c9db8637dba9bbd07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164433
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I10bb684cce75c5ccb00bae7793f9bb58420241ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164432
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I5b81ad3d5f1351062aef43105ea7ec4678045a90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164360
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>
|
|
Change-Id: I82e38ac815765b62601076cf61745fe9889451b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164358
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I4dd65567900658c23637a6a10823b67e93bad768
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164182
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>
|
|
Change-Id: I87d55236ee09b80aadcc95e2c0f06f15b9e24a44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164100
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>
|
|
...that return the "hierarchical object", rather than setting it as a member of
the passed-in instance
Change-Id: I17ad7dd426114c7979f1ba6edaebe83b43eedfed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164064
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
80d3f33876a2ad4ce32d3c6183131984e8c6b5da "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>
|
|
...as the workdir/UnoApiTarget/embindtest.rdb type library would not be
available at runtime
Change-Id: Ie674ff212b1303c8925136235446cc97447b0897
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163815
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I151969acde242bc9c7ee88e2b2da44c8c2101456
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163816
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|