summaryrefslogtreecommitdiff
path: root/toolkit
AgeCommit message (Collapse)AuthorFilesLines
2019-11-22Extend loplugin:external to warn about classesStephan Bergmann11-4/+51
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-15make some classes module-privateNoel Grandin1-1/+1
Change-Id: I95845d7217fc5e77e3f8e205030e9cd761ad0cc5 Reviewed-on: https://gerrit.libreoffice.org/82116 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-14Resolves: tdf#128792 progressbar control not createdCaolán McNamara1-2/+5
Change-Id: I81ff4e56d5ea2a4f5b7c034c2a99df881969b119 Reviewed-on: https://gerrit.libreoffice.org/82655 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-13revert action button changes to UNO XStyleSettingTomaž Vajngerl2-45/+11
As there is no need for this UNO changes instead set the values with other appropriate button settings so the previous behaviour is retained. Change-Id: I5952a9ce9f2f72faeb12a7a945c53ed048719b27 Reviewed-on: https://gerrit.libreoffice.org/82620 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2019-11-12toolkit: UnoEditControl::insertText() assert on invalid indexMichael Stahl1-1/+6
... in replaceAt(): if the selection that is passed in is invalid, throw an exception. This obviously isn't thread-safe but naively adding a GetMutex() guard quickly deadlocks against SolarMutex; why does it use its own mutex? Reproduces when installing APSO 1.2.5 and starting the Python REPL. Change-Id: I4fb16ab820641f1a031537b0c4d6f8664d67dc0c Reviewed-on: https://gerrit.libreoffice.org/82460 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-11-11tdf#127921 Revert mouse/key listeners to original stateSamuel Mehrbrodt1-68/+49
The changes caused several issues in the presenter console (mouse events delivered to wrong widgets). Also it turned up that parent windows got the notification about mouse events from their children, but the position was always relative to the top widget, so very unhelpful for the parent widgets. Also I found out that there are XKeyHandler and XMouseClickHandler interfaces which already do what I tried to do with the below commits (events get passed down to parent widgets, and they even can be marked as consumed). So the original issue reported can be fixed by using XKeyHandler/XMouseClickHandler instead. This reverts the following two commits: * "Related tdf#122920 Treat UNO key events the same as mouse events" 9e0e97b716ab074d4558c76a62a66bf597f332a5 * "tdf#122920 Send UNO mouse events to parent window listeners as well" 6f43902b12dd36fa2b69401065df198ef9ffdb09 Change-Id: I005d22770a7a4db9588c5bc22197dc0ae526627e Reviewed-on: https://gerrit.libreoffice.org/82423 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2019-11-09custom widgets: support custom action button text colorsAshod Nakashian2-0/+47
Change-Id: I314183a1d6434c043183a600740c786e22a67503 Reviewed-on: https://gerrit.libreoffice.org/82276 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2019-11-07ButtonDialog is only inherited fromCaolán McNamara2-8/+0
Change-Id: Icc827ba76432e6ed454acf12dc18c83c6908487b Reviewed-on: https://gerrit.libreoffice.org/82197 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-07rename Dialog::ImplInit so no need for using directiveCaolán McNamara1-1/+1
Change-Id: I01a8591def7a559d3152e9c4875c6785940331f7 Reviewed-on: https://gerrit.libreoffice.org/82202 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-04ProgressBar now only use in vcl and toolkitCaolán McNamara2-2/+2
Change-Id: I5d56a4df155806e41cafa6f65a3a030e8443b8f7 Reviewed-on: https://gerrit.libreoffice.org/82005 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-04move VCLXProgressBar to toolkitCaolán McNamara2-0/+257
Change-Id: I3aa21aff97346a9a43ad7b25621e8a8733fc4041 Reviewed-on: https://gerrit.libreoffice.org/82004 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-04FixedHyperlink now only used in vcl and toolkitCaolán McNamara2-2/+2
Change-Id: Id1eacb01ab7ed985d1495d3949bc185556246e3a Reviewed-on: https://gerrit.libreoffice.org/82003 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-04move VCLXFixedHyperlink creation to toolkitCaolán McNamara1-0/+6
Change-Id: I3aa47a194f2b10b15faaa142c7dc6d57dffff96e Reviewed-on: https://gerrit.libreoffice.org/82002 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-02New loplugin:conditionalstringStephan Bergmann1-1/+1
Change-Id: I2eab990c15f845b44a3b598571aca361dadf9ff3 Reviewed-on: https://gerrit.libreoffice.org/81946 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-31Fix StringAdd::isCompileTimeConstantStephan Bergmann1-3/+1
...to find StringLiteral on the RHS of +=. Which revealed that the VisitCompoundStmt/checkForCompoundAssign logic needed to be fixed, too, so that s += side_effect(); s += "literal"; s += side_effect(); only gets combined to s += side_effect() + "literal"; s += side_effect(); and not all the way to s += side_effect() + "literal" + side_effect(); Change-Id: I432e3458b933a7d0ad6141c747b675cc8b0f0ba4 Reviewed-on: https://gerrit.libreoffice.org/81804 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-30imgctrl.hxx only used by vcl and toolkitCaolán McNamara2-2/+2
Change-Id: I77e2efa77d9fbc0830553faed269e1fec2b2a286 Reviewed-on: https://gerrit.libreoffice.org/81713 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-10-30SpinButton only needed by vcl and toolkitCaolán McNamara2-2/+2
Change-Id: I1a99231a895269bc728ed7730fe277bb8e73a25e Reviewed-on: https://gerrit.libreoffice.org/81711 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-10-15new loplugin:bufferaddNoel Grandin1-4/+2
look for OUStringBuffer append sequences that can be turned into creating an OUString with + operations Change-Id: Ica840dc096000307b4a105fb4d9ec7588a15ade6 Reviewed-on: https://gerrit.libreoffice.org/80809 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-15move HAVE_FEATURE_DESKTOP/OPENCL to their dedicated headersLuboš Luňák1-1/+1
HAVE_FEATURE_OPENCL is included by a common Calc header and HAVE_FEATURE_DESKTOP is included by a common Writer header, causing pretty much their full rebuilds if any feature changes. Change-Id: If29bf78bd4fd70b37981e0826a577777fd255c89 Reviewed-on: https://gerrit.libreoffice.org/80776 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2019-10-08use cppu::WeakImplHelper in VCLXRegionNoel Grandin1-23/+0
Change-Id: I93bb52b35b4c15dc93d7638d7fc1e00652a2a1e7 Reviewed-on: https://gerrit.libreoffice.org/80400 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-08use cppu::WeakImplHelper in VCLXBitmapNoel Grandin1-25/+0
Change-Id: I789646591caca8ee164d32e07b050b862f627973 Reviewed-on: https://gerrit.libreoffice.org/80385 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-07use cppu::WeakImplHelper in VCLXGraphicsNoel Grandin1-23/+0
Change-Id: If862818ef3eb534493ac61d5071ec1adf590ebf2 Reviewed-on: https://gerrit.libreoffice.org/80388 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-07use cppu::WeakImplHelper in VCLXDeviceNoel Grandin1-25/+0
Change-Id: Ia83cc372d53db41edc8199077db91cb7b1d06e24 Reviewed-on: https://gerrit.libreoffice.org/80386 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-07use cppu::WeakImplHelper in VCLXFontNoel Grandin1-25/+0
Change-Id: Iab0ff79ba1f94f087b57faefa3945aba1ed42448 Reviewed-on: https://gerrit.libreoffice.org/80387 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-04find-unneeded-includes: ignore extra recommendationsGabor Kelemen1-3/+0
When IWYU is used to check cxx files it also checks associated hxx (but for .hxx -> .h too) files too and gives addition/removal recommendations There is no documented way of disabling this. Currently f-u-i does not differentiate between recommendations for the checked file and its header and prints everything. Which means sometimes I need to update .hxx files or blacklist warnings that interestingly are not shown when the same .hxx is checked with IWYU. The worst example is ucb/source/ucp/ftp/curl.hxx where IWYU gives recommendations for /usr/include/x86_64-linux-gnu/curl/curl.h Remedy this with considering the full filename + should add these lines: / should remove these lines: string as beginning of interesting recommendations Also remove some now obsolete blacklist entries from yaml files Change-Id: I1d139536992e4b56c699c31a4cc6491d373c2002 Reviewed-on: https://gerrit.libreoffice.org/80172 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-10-03merge msgbox and stdtextCaolán McNamara1-1/+1
Change-Id: If95d78746eff3ae5343e7d4c6bb2433537ccb84d Reviewed-on: https://gerrit.libreoffice.org/80099 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-09-26add property name when throwing css::uno::UnknownPropertyExceptionNoel Grandin1-1/+1
Change-Id: I17f06c9415b9d43b6d8896360e07216c2856367a Reviewed-on: https://gerrit.libreoffice.org/79627 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-18tdf#42949 Fix IWYU warnings in toolkit/Gabor Kelemen52-187/+29
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ib49e2f29daa6d9b2a8195915c4ba10a8cef965ce Reviewed-on: https://gerrit.libreoffice.org/78722 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-09-17move GetStandardText to stdtext.hxxCaolán McNamara1-1/+2
Change-Id: Iaf9b5107cf88390f62d5ca94bf985c77bcb8b7ad Reviewed-on: https://gerrit.libreoffice.org/79048 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-09-12Fix typosAndrea Gelmini1-1/+1
Change-Id: I7fdeba2d7407989a00befaad1c186cd6f132cb85 Reviewed-on: https://gerrit.libreoffice.org/78827 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-09-06Fixing "...."Andrea Gelmini5-10/+10
Change-Id: I3424e17cfdfb563fdc5882942031deafae8689fe Reviewed-on: https://gerrit.libreoffice.org/78678 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-09-01Fix '..'Andrea Gelmini1-1/+1
To complete this: https://gerrit.libreoffice.org/#/c/78312/ This is a massive replace for lines ending with ".." instead of "..." It passed "make check" on Linux. Change-Id: I07fa7b2e30ba9ea17a1f9a5e21c57216ba958efe Reviewed-on: https://gerrit.libreoffice.org/78356 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2019-08-31throbber.hxx only used by vcl and toolkit nowCaolán McNamara3-3/+3
Change-Id: I69e7f99a02ea1f1144896e83aa188d0eec9a638b Reviewed-on: https://gerrit.libreoffice.org/78324 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-08-31roadmap.hxx only used by vcl and toolkit nowCaolán McNamara1-4/+4
Change-Id: I2a00687fbc53b2b5f2b8ad94e4813e778eb15f21 Reviewed-on: https://gerrit.libreoffice.org/78323 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-08-31move SVTXRoadmap to toolkitCaolán McNamara1-0/+314
Change-Id: If1ef35fe778b67ab028fdadb3804f437e127aa67 Reviewed-on: https://gerrit.libreoffice.org/78322 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-08-26tdf#93998 toolkit: restore support for setting dialog background from shapeMiklos Vajna2-4/+23
Regression from commit fb29e6eeeaad5255bb924ff59162a83ed80bfb0a (svx: removing GraphicURL and OWN_ATTR_GRAFURL, fix writerfilter, 2018-03-08), the problem was that an in-document macro tried to assign a bitmap shape to a dialog background, which broke during the image handling rework. Note that in this case the actual type of the "URL" is not interesting, we can just return an XGraphic and then take it on the other side as well, without re-introducing the intentionally removed graphic URLs which point to memory addresses. This also made it necessary to extend UnoDialogControl::ImplModelPropertiesChanged(), so that in case a graphic is assigned to the dialog model, then the dialog model -> dialog sync code doesn't just copy over the empty image URL string. With this, finally clicking on the button of the bugdoc makes the dialog show up with the correct background. Change-Id: Id78269643289efb435b96a6a0b9f8a93fa49ec04 Reviewed-on: https://gerrit.libreoffice.org/78153 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-08-23tdf#39593 extract UnoTunnelId comparison to template functionArkadiy Illarionov2-3/+4
Change-Id: Ia2b5dea273c8de7b8c54e74780193a8d4cba7b45 Reviewed-on: https://gerrit.libreoffice.org/73874 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-22loplugin:constmethod in toolkitNoel Grandin2-4/+4
Change-Id: Id80ee487d7083da5c1f1c4d012d6339700471204 Reviewed-on: https://gerrit.libreoffice.org/77952 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-20loplugin:constvars in test..unotoolsNoel Grandin3-6/+6
Change-Id: I087dc53ca5c18893974bbd9d959de56d5a4cdfa0 Reviewed-on: https://gerrit.libreoffice.org/77827 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-17tdf#88205 Adapt uses of css::uno::Sequence to use initializer_list ctorJulien Nabet4-15/+6
in testtools and toolkit Change-Id: I14b53c27906eb615e68482cbc3918be8da464212 Reviewed-on: https://gerrit.libreoffice.org/77624 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-16use more TOOLS_WARN_EXCEPTIONNoel Grandin1-4/+2
Change-Id: Ic21ea11ff106e0732bb8fa600ef39a549d7bda86 Reviewed-on: https://gerrit.libreoffice.org/77569 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-15loplugin:sequenceloop in test..toolkitNoel Grandin12-23/+23
Change-Id: Ic8dad06c535b0af713bfe7cd46e601c8ea7ba6c7 Reviewed-on: https://gerrit.libreoffice.org/77531 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-15replace ".get->" with "->"Noel Grandin1-4/+4
Change-Id: I327a6fda1fe0170da33e06b735f09a39421c8a58 Reviewed-on: https://gerrit.libreoffice.org/77469 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-12Fix typosAndrea Gelmini4-5/+5
Change-Id: Iedac37e0e056815e64294c70a233242df6dbf110 Reviewed-on: https://gerrit.libreoffice.org/77278 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-12Fix typosAndrea Gelmini6-8/+8
Change-Id: Ic472270afa13d2c96a4c7ccc185d183c3b7ade2c Reviewed-on: https://gerrit.libreoffice.org/77277 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-08tdf#74702: use OutputDevice::GetBackgroundColor()Chris Sherlock1-1/+1
Apply the Liskov substitution principle to OutputDevice::GetBackgroundColor(). This helps in SmTmpDevice::Impl_GetColor() because it no longer needs to know about what type of OutputDevice it is calling to get the background color. This forced a rename of basctl::ModulWindowLayout::GetBackgroundColor() to be GetSyntaxBackgroundColor(), but this is a happy coincidence as it makes the function intent clearer anyway. Change-Id: I11298a63cb01c187f3a8a4a2c9e90eacda6c3e6b Reviewed-on: https://gerrit.libreoffice.org/75521 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2019-08-07Resolves: tdf#126717 default that formcontrols show acceleratorsCaolán McNamara1-0/+3
Change-Id: I755cb19d08ae2a2036a86422d2e455c1033a54df Reviewed-on: https://gerrit.libreoffice.org/77085 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-07-31Improved loplugin:stringconstant (now that GCC 7 supports it): toolkitStephan Bergmann30-114/+114
Change-Id: I598d89be70d476663ffef95029015cba17bf09b9 Reviewed-on: https://gerrit.libreoffice.org/76636 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-21loplugin:referencecasting in test..toolkitNoel Grandin7-29/+20
Change-Id: Ib1e6ba9c3849256b81fa5fa395e891226a044f7c Reviewed-on: https://gerrit.libreoffice.org/76029 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-19tdf#125609 toolkit: don't use XTabController::getControlsJustin Luth1-8/+7
Calling XTabController::getControls was supposed to give performance improvements (coded in OOo), but it pulls cached information which is not up to date if this listener for elementInserted events is handled before the formController's listener. It is missing the most recently created control - and thus it never sees the last control in the form, and fails to create the radio group. Additionally, when all of the controls are not yet created, this function seems to be designed to catch that and immediately return. With the "optimization" the missing controls were never noticed, and so unnecessary processing continued - a performance detriment while the form is being built. My impresssion is that the local getControl() function is not terribly inefficient, so the performance impact seems minimal, especially since it now only makes the call once and caches the result itself. Since not-yet-peered controls cause the function to again terminate early (as it was designed to do), this may have unintended side effects, in case anything was designed in the past 10+ years expecting the old behaviour, so I have no intention of back-porting this. Change-Id: Ica8ddab69043a30b23d008cd8db5df1c13b94ad2 Reviewed-on: https://gerrit.libreoffice.org/75163 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-21 12:30:58 +0000