summaryrefslogtreecommitdiff
path: root/unotest
AgeCommit message (Collapse)AuthorFilesLines
6 daysImplement attribute handlingStephan Bergmann2-0/+14
Change-Id: Ic30d2de582f952555ec672984da78a07a9319443 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168224 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
7 daysImplement exception catchingStephan Bergmann1-0/+19
(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>
7 daysEmscripten: Unconditional --enable-wasm-exceptionsStephan Bergmann1-14/+4
(...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>
7 daysEmscripten: Document failing getExceptionMessageStephan Bergmann1-0/+8
(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
2024-05-20loplugin:ostr in variousNoel Grandin2-9/+9
Change-Id: I9f399b3752da9df930e0647536ffcd4e82beb1ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167856 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-05-12WaE: C6011 Dereferencing NULL pointer warningsCaolán McNamara1-1/+1
Change-Id: Ieabea4a0ddf8f95ea01b8b0275be0924ad055694 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167524 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-05-09Fix missing UNO<->C++ argument/return value conversionsStephan Bergmann1-0/+52
Change-Id: I5ac6013d6c0bd72fe840a592628fd0d5b265b8ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167391 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-05-09Embind: Fix uno_Any.get for null interface valuesStephan Bergmann1-0/+17
...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>
2024-05-08Emscripten: Towards a working C++ UNO bridgeStephan Bergmann2-0/+353
...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
2024-04-30Embind: Fix out-param handlingStephan Bergmann2-3/+50
...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>
2024-04-20Embind: Test and Fix out-param handlingStephan Bergmann2-0/+65
(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>
2024-04-20Embind: Drop $equals, add sameUnoObjectStephan Bergmann1-1/+1
$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>
2024-04-20Embind: Don't use new when getting UNO singletonsStephan Bergmann1-1/+1
Change-Id: I23265f46b25cb88796267abe28aac1100523e71b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166298 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-04-19Embind: Consistently represent empty interface references as JS nullStephan Bergmann2-0/+22
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>
2024-04-18Embind: throwUnoException from JSStephan Bergmann2-1/+13
(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>
2024-04-18Embind: call decrementExceptionRefcount upon catchingStephan Bergmann1-0/+5
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>
2024-04-17Embind: Clean up JS UNO obj implementation in embindtest.jsStephan Bergmann1-7/+20
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>
2024-04-16Embind: No need for $queryStephan Bergmann1-1/+1
...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>
2024-04-12Embind: support .implement()-based JS UNO objectsStephan Bergmann2-0/+58
Change-Id: I3a8bf5986b91b886547cfe57e49275f7c79ddc11 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166020 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-04-11Move org.libreoffice.embindtest from udkapi to offapiStephan Bergmann1-3/+1
...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>
2024-04-08Fix indentationStephan Bergmann1-5/+5
Change-Id: I985562995714c04c569e3a794cf748443ed02865 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165886 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-04-08Embind: Clarify poor UNO exception supportStephan Bergmann2-0/+13
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>
2024-03-11Embind construction of UNO Any sequence/struct/exception/interfaceStephan Bergmann1-17/+17
Change-Id: I43d924126f4d34e0efbcea61dd5f4bd9be235426 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164650 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-03-11Embind construction of UNO Any enumStephan Bergmann1-5/+5
Change-Id: I1b2167e261f1020b228f8ca2618c7f0009ca1d3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164646 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-03-09Enable (and fix) some TODO test codeStephan Bergmann1-9/+11
...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>
2024-03-08Embind construction of UNO Any TypeStephan Bergmann1-3/+3
Change-Id: Iac5ac8de7bfb19b90d54edc6f4b791d8c0e98977 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164594 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-03-08Redesign Embind UNO Any constructionStephan Bergmann1-23/+26
...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>
2024-03-08Improve Embind'ing of UNO TypeStephan Bergmann1-1/+7
Change-Id: Id93d7f48dedb362206828b5e3bd946525f95ea77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164590 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-03-07Add Embind'ing of UNO Any getter for interfacesStephan Bergmann2-0/+24
Change-Id: Ia56439e0e99c193c7cc56676677df2c671278e24 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164554 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-03-06Adapt Exception test to emcc/Clang versions that support std::source_locationStephan Bergmann2-2/+2
...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>
2024-03-06Add Embind'ing of UNO Any getter for exceptionsStephan Bergmann2-0/+34
Change-Id: Ief3cdebc1ee7c7b9f012741c9db8637dba9bbd07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164433 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-03-05Fix typos in commented-out TODO codeStephan Bergmann1-3/+3
Change-Id: I10bb684cce75c5ccb00bae7793f9bb58420241ae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164432 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-03-04Add Embind'ing of UNO Any getter for sequencesStephan Bergmann1-9/+9
Change-Id: I5b81ad3d5f1351062aef43105ea7ec4678045a90 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164360 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-03-04Add Embing'ing of UNO Any getter for enumsStephan Bergmann1-1/+1
...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>
2024-03-04Improve Embing'ing of UNO Any somewhatStephan Bergmann2-1/+382
Change-Id: I82e38ac815765b62601076cf61745fe9889451b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164358 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-03-02Some minor embindtest clean upStephan Bergmann2-3/+3
Change-Id: I4dd65567900658c23637a6a10823b67e93bad768 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164182 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-29Some minimal Embind support for UNO typeStephan Bergmann2-0/+40
...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>
2024-02-29Test Embind'ing of UNO enumsStephan Bergmann2-0/+42
Change-Id: I87d55236ee09b80aadcc95e2c0f06f15b9e24a44 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164100 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-29Embind support for constant groupsStephan Bergmann1-0/+20
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>
2024-02-28Generate slightly more flexible JS init_unoembind_* functionsStephan Bergmann1-3/+2
...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>
2024-02-28Fold InternalUnoApi_embindtest into UnoApi_udkapiStephan Bergmann4-100/+0
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>
2024-02-23Library_embindtest should use comprehensive InternalUnoApi_embindtestStephan Bergmann1-1/+1
...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>
2024-02-23unoembind sequence testsStephan Bergmann3-0/+332
Change-Id: I151969acde242bc9c7ee88e2b2da44c8c2101456 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163816 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-22Embind: Add UNO char supportStephan Bergmann3-0/+12
Change-Id: I4ced49774baafdf620ae167c53794932766aca86 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163741 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-22A first cut at embindtestStephan Bergmann3-1/+162
(UNO boolean should arguably map to JS Boolean, not Number) Change-Id: I21847c558b14ead053aa5c5ea94a508a73aaf36b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163722 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-22Framework for some UNOIDL to test the Embind UNO binding withStephan Bergmann7-0/+143
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>
2024-01-30tdf#105844 unotest,xmlsecurity: fix tests on MacOSXMichael Stahl1-13/+33
The new tests fail with: > core/xmlsecurity/qa/unit/signing/signing2.cxx: > 252: Assertion > Test name: testPasswordPreserveMacroSignatureODFWholesomeLO242::TestBody > equality assertion failed > - Expected: 1 > - Actual : 4 This is because only the first test that runs sees the testing CA certificates that are copied in MacrosTest::setUpNssGpg(); when the second test runs, they have somehow vanished. This is because apparently SQLite on MacOSX, unlike on Linux, monitors the file descriptors of its database files, and then invalidates itself when setUpNssGpg() via osl::File::copy() renames and unlinks the existing database files: > cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode renamed while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/cert9.db.osl-tmp > cppunittester[29873:5483181] [logging] invalidated open fd: 5 (0x20) > cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode unlinked while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/cert9.db.osl-tmp > cppunittester[29873:5483181] [logging] invalidated open fd: 5 (0x11) > cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode renamed while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/key4.db.osl-tmp > cppunittester[29873:5483181] [logging] invalidated open fd: 6 (0x20) > cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode unlinked while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/key4.db.osl-tmp > cppunittester[29873:5483181] [logging] invalidated open fd: 6 (0x11) Split MacrosTest::setUpNssGpg()/tearDownNssGpg() into functions setUpX509() which only does something on the 1st invocation, and setUpGpg()/tearDownGpg() which may be invoked per-test (they could also be run once for the whole test suite, but not obvious how to do that); PDF related tests don't need GPG. Presumably this is (along with the WNT-specific problem fixed in commit 3e9a700091872480dd085f0928d1d30b7d74cfd7) the reason why most of the tests not only accept the expected result of SignatureState::OK but also SignatureState::NOTVALIDATED. Change-Id: I59b85ca651cecaccfdea729ed1e645c53079c8bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162693 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-12-27tdf#158803 Fix issues detected by pyflakesChenxiong Qi1-5/+1
Change-Id: Iaa329dff61db894e7d5fecd840e785a53a48b26f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160889 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2023-05-05loplugin:unnecessarygetstrStephan Bergmann1-2/+1
The plugin in its current form is probably not intending to find these cases. But it happened to do so on macOS with libc++, where the std::basic_string ctors taking a final defaulted Allocator argument are instead implemented by a pair of overloaded ctors, one taking no Allocator at all (see 671d1c6cd14b28b5960ad56086299bd69533dfd8 "Adapt loplugin:unnecessarygetstr to libc++"). But these changes here are useful regardless, so lets leave it at that. Change-Id: I2776671e2953182bdcad36432951a75f82412ebb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151410 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-21qa: call ProcessEventsToIdle inside dispatchCommandXisco Fauli2-1/+6
Change-Id: I909e6f334f4a659282141a97ccb3ffdea6ecc364 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147397 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-05 07:24:33 +0000