Adds a service to embindtest that implements XInvocation to handle all
possible method names and returns the name as a string. A Python unit
test then uses this. Without the fix pyuno would throw an exception when
it tries to use the XInvocation object that doesn’t also implement
XInvocation2 and return a valid reference for getIntrospection.
Change-Id: Icb3359c788acd5eda37980252e5fc5c956b38100
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209087
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
When any2PyObject is given an interface which is actually an adapter for
a Python object, it now returns the original Python object instead of a
new wrapper for the object. This means that calling methods on the
returned object will be faster because they won’t involve UNO bridging.
It also means that Python implementations of UNO interfaces can detect
when they are given Python objects as a parameter and take advantage of
any internal private data attached to the object.
Change-Id: Ie13d0612f48e70973bd523e68710ec33a7875a16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207507
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
This leverages the existing framework for embindtest to add interfaces
and services to test with. Hopefully that means the tests will run on
the CI without ending up in the final release builds because they are
only enabled with --enable-embindtest-uno.
Change-Id: Idd394e616ad14943cecd60bf3a3e228d93166e34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199105
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
...for cases where one operand is a PyUNO Adapter of the other (i.e., one
operand is a Python object that got passed out and back in again, and the other
operand is that same Python object). This fixes the second "TODO" from
1e2e9a20a4 "More exhaustive testing of PyUNO type
mapping based on embindtest".
Change-Id: I0fc938db5c464ed56adee3b428537925fff0fc81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195392
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
...by implementing all the getSequence... variants that were left out of
3320b5fe2e "Add exhaustive testing of PyUNO type
mapping based on embindtest".
Change-Id: Ia0dde7362484f83923999db68d80f57c7baa914c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195426
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
That
> // the exception base functions want to have an "args" tuple,
> // which contains the message
code is there ever since e80bdbafeb "initial
checkin for the pyuno-0.9.2 release" for reasons that are not clear to me, but
at least in the "TODO" scenarios from 3320b5fe2e
"Add exhaustive testing of PyUNO type mapping based on embindtest" and
1e2e9a20a4 "More exhaustive testing of PyUNO type
mapping based on embindtest" (which are hereby fixed), that
PyObject_SetAttrString would cause a Python exception, cf.
> info:pyuno.runtime:1489432:1489432:pyuno/source/module/pyuno_runtime.cxx:533: setting exception args raised Python exception <class 'AttributeError'>: AttributeError('args')
so at least catch that. (And maybe that code is obsolete anyway it would make
even more sense to drop it altogether.)
Change-Id: Ic651d106f34e0b316cba59ae66d2402b8f86b0f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195340
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
...by implementing all the getAny... variants that were left out of
5f05929fd1498e418618d7570192877055de2c80 "Add exhaustive testing of PyUNO type
mapping based on embindtest".
Which revealed that the code in Adapter::invoke (in
pyuno/source/module/pyuno_adapter.cxx) was apparently broken, and would cause
the C++ call in doExecuteTest (in unotest/source/embindtest/embindtest.cxx) of
the Python
> def getAnyByte(self):
> return uno.Any('byte', -12)
(in pyuno/qa/pytests/embindtest.py) to fail with a nonsensical
> uno.com.sun.star.uno.RuntimeException: uno.Any instance not accepted during method call, use uno.invoke instead at pyuno/source/module/pyuno_runtime.cxx:785 at stoc/source/invocation_adapterfactory/iafactory.cxx:203
In addition, there's two new places marked with TODO comments:
For one, executing C++
> bool const ok = test->isAnyException(val);
would cause an odd
> python.bin: Objects/typeobject.c:4745: PyObject *_PyType_Lookup(PyTypeObject *, PyObject *): Assertion `!PyErr_Occurred()' failed.
failure that needs further investigation.
And for another, executing Python
> return value == self
would always return false. It appears that PyUNO_cmp (in
pyuno/source/module/pyuno.cxx isn't yet prepared to be called with `that` being
a native Python UNO-implemenation object (`class Test(unohelper.Base, XTest)`)
instead of a proxy for a binary/C++ UNO object.
Change-Id: I0289e1f5ee6dab53b589af783c0c53302989394c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195287
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
...in preparation for doing fixes for tdf#169229 "PyUNO: Hard to create null UNO
interface references, to use in a method invocation" etc. (Basing it on
embindtest means it requires --enable-embindtest-uno, at least for now.)
Various places in pyuno/qa/pytests/embindtest.py are marked with TODO comments.
(Executing
> v = test.getAnyException()
would cause an odd
> Fatal Python error: _Py_CheckFunctionResult: a function returned a result with an exception set
failure that needs further investigation.)
To not only test calls from PyUNO to binary (C++) UNO, but also from binary
(C++) UNO to PyUNO, add an executeTest method to the
org.libreoffice.embindtest.XTest interface. For now, it only does those tests
that were already done by the org.libreoffice.embindtest.BridgeTest service
implementation, but the plan is to extend those (e.g., don't just only test
getAnyVoid, but all the getAny... variants). And the corresponding Test class
implementation in pyuno/qa/pytests/embindtest.py for now only defines those
methods that are actually called, and will need to be extended as well.
Change-Id: I0dd66b9aed14cc7e679da78b86d0dc657625fe94
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195238
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tested-by: Jenkins
Otherwise, running the embindtest code in a LOKit-based scenario (analogously to
how it is run under certain circumstances via
--post-js $(SRCDIR)/unotest/source/embindtest/embindtest.js
in desktop/Executable_soffice_bin.mk) would cause a deadlock when
TestThread::execute (in unotest/source/embindtest/embindtest.cxx) calls
SolarMutexGuard g;
on that additional thread, but the main thread never released the SolarMutex
because of that acquire in lo_runLoop.
The code in lo_runLoop had originally been added with
b693fb5cf1 "We apparently need to drop the Solar
Mutex when exiting lo_runLoop() on iOS" (curiously using explicit calls to
acquire and release, instead of using an additional SolarMutexGuard; the
difference being that a SolarMutexGuard would automatically be released upon an
exception, which skips the explicit call to release), originally only for iOS,
then extended to Android with 0abdf307ea "android:
Unregistering in runLoop() is important even on Android", then extended to
Emscripten with 1e421b30e2 "Attempt to add ifdefs
for WASM (Emscripten) for LOKit-based code" for no apparent reason.
I have no idea how the Android and iOS scenarios are meant to cope with
soffice_main being called with SolarMutex being acquired twice, so that no other
threads could ever acquire it (except thanks to temporary uses of
SolarMutexReleaser, which might explain things).
However, what happens in the Emscripten scenario is that executing soffice_main
leads to a call to emscripten_set_main_loop_arg in SvpSalInstance::DoExecute
(vcl/headless/svpinst.cxx), which quits by throwing an exception all the way to
the JS event loop, so that in lo_runLoop the inner SolarMutexGuard automatically
gets released, while the outer explicit call to release got skipped, leaving the
SolarMutex locked forever on the main thread.
As there is no apparent reason why the Emscripten scenario should have this
double locking here (and the call to vcl::lok::unregisterPollCallbacks at the
bottom of lo_runLoop would never be executed in the Emscripten scenario, anyway,
thanks to the exception being thrown from emscripten_set_main_loop_arg), and
1e421b30e2 "Attempt to add ifdefs for WASM
(Emscripten) for LOKit-based code" maybe just added it in a blind copy/paste,
lets just skip it.
(And add a DBG_TESTNOTSOLARMUTEX to the embindtest code, to document that code's
assumptions.)
Change-Id: Ibae0d1d8b5f29f08d30829251ed2bb58413ea4e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188973
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tested-by: Jenkins
Like file:///C:/lo/core//sw/qa/extras/rtfexport/data//tabs.rtf
Reimplement Directories::get{URL,Path}From{Src,Workdir} to check
and insert missing / remove excessive slashes as needed.
Change-Id: Ibd3657b0557bf1712c2de9ac74db0977754a2ed9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187932
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
...not just --enable-dbgutil ones, which gives more flexibility in using that
infrastructure downstream. (The unotest/source/embindtest/embindtest.js code is
still only included in desktop/Executable_soffice_bin.mk for --enable-dbgutil
builds, though.)
Building unotest/source/embindtest/embindtest.cxx also outside of
--enable-dbgutil, and thus implicitly --enable-assert-always-abort, builds
required moving from assert() to some hand-crafted verify().
Change-Id: I3f0fa00feee25b4ea6e7866c22a5b4a4d40cb3d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178361
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
... and reset the view options that are toggled in
testHiddenParagraphFollowFrame and testHiddenParagraphFlys.
Backporting these tests to the libreoffice-24-8 branch broke 2 unrelated
tests because of the changed view settings:
Test name: (anonymous namespace)::testHiddenSectionPageDescs::TestBody
equality assertion failed
- Expected: 532
- Actual : 798
- In <>, attribute 'height' of '/root/page[2]/body/section[1]/infos/bounds' incorrect value.
xmltesttools.cxx:203:Assertion
Test name: (anonymous namespace)::testTable0HeightRows::TestBody
equality assertion failed
- Expected: 28
- Actual : 22
- In <>, XPath '/root/page[1]/body/tab/row' number of nodes is incorrect
Change-Id: Ie58242348fecabe163e54048f3896c6d427d2608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177691
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
we can just take a "const &".
(found by running clang-tidy with the
performance-unnecessary-copy-initialization warning)
Change-Id: I20fd208c65303da78170b1ac06c638fdf3aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176267
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
...before disappearing through the QApplication::exec() hole, or else the
SolarMutex would remain locked forever on the application's main thread.
This requires changing SalInstance::ReleaseYieldMutexAll() to
SalInstance::ReleaseYieldMutex(bool all). (Further recursive locking of the
SolarMutex via SolarMutexGuard instances that would be present on the call stack
leading up to the call to QApplication::exec() would be released during the
stack unwinding, so just undo the one acquiring done in InitVCL, not all of
them.)
Change-Id: I9ef57abb7da7f840999700e4eaeeefd2da784645
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171956
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
The problem was that running UITest_xmlsecurity_gpg changed the files in
test/signing-keys/ ... prevent that by copying the directory in that
test, which is more complicated than initially expected.
Change-Id: Ie3be922e0b2e9dae49f9a70e35ad5270c90b4fc4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171322
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
...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
...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>
...so that testing its StringAttribute stars out with a known state. And which
revealed that the test code in unotest/source/embindtest/embindtest.js was
actually wrong in assuming that that UNO attribute would be represented by a JS
accessor property, when actually it is represented by a pair of
get-/setStringAttribute member functions.
Change-Id: I1a6e7c9f26e9a08cd089b7972a23f4c608c6b1bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170414
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>
...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>
Neil Roberts