summaryrefslogtreecommitdiff
path: root/svl
AgeCommit message (Collapse)AuthorFilesLines
2021-01-28simplify code, use more subView()Noel2-7/+7
Change-Id: I569c7f34acbdf8451cd5c9acf1abd334637072d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110051 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-28add string_view variants of methods to O[U]StringBufferNoel2-3/+3
and update the stringview loplugin to detect cases where we can use these new methods. Change-Id: I998efe02e35c8efcb3abfb4d7186165bbe6dfb2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110046 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-27Improve loplugin:stringliteralvarStephan Bergmann1-4/+4
...to also consider O[U]String ctors taking pointer and length Change-Id: Iea5041634bfbf5054a1317701e30b56f72e940fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110025 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-27tdf#92456 store hash with stringNoel Grandin1-10/+42
so it does not need re-computing when comparing keys. shave 5% off time for this bug. Change-Id: I48870567be00f0ea98cad69e9c48222cd64decf2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109992 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-25tdf#92456 improve VLOOKUP perfNoel Grandin1-4/+6
shave 5% of the time here - ref-counting triggered by copying svl::SharedString is significant, so return by const& instead of by value Change-Id: Ic702632da45d75dddab33d6ce1e6f1097ff70de9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109900 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-12tdf#42982: Improve UNO API error reportingBayram Çiçek1-1/+1
Change-Id: I78c6fed4e94f1ebfc772db4dec9955da7230bc3f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109071 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins
2021-01-10fix coverity parse errorsCaolán McNamara1-1/+1
Change-Id: I4884bfb67a061b865e8cf38b2fea6de0cb1bc3d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109057 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-01-05tdf#96505 : Get rid of cargo cult long integer literalsumutbayramoglu1-2/+2
Change-Id: I7b269fb5bafceba071ebe649a696ef61301c4018 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107366 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-01-03tighten up asserting in SfxPoolItem::operator==Noel Grandin4-6/+10
...subclasses, so we always call the SfxPoolItem::operatar== which will ensure that we are always comparing two objects that belong to the same class. And fix the fallout in SvxUnoNameItemTable. Change-Id: I5ec7fedaa914a328897b54c016ad13e505a15937 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108599 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-02Remove warning while buildingdante1-1/+1
Operator >>= from any does not guarantee initialization, so compiler warns you. Value defaluted at 0. Change-Id: Icecc765be73bb653f0167958e319a1417df6ac86 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108485 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann4-37/+40
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-26New loplugin:stringliteralvarStephan Bergmann1-1/+1
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for details. (Turned some affected variables in included files into inline variables, to avoid GCC warnings about unused variables.) Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-19make *String(string_view) constructors explicitNoel Grandin1-1/+1
to make it more obvious when we are constructing heap OUStrings code and potentially inadvertently throwing away performance. And fix a handful of places so revealed. Change-Id: I0cf390f78026f8a670aaab53424cd31510633051 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107923 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-19use more string_view in SfxItemPropertyMapNoel1-3/+3
Change-Id: I053dedcbf0b110a61752722d247d6ee5e9ba481d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107977 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-15update pchesCaolán McNamara1-2/+2
Change-Id: I280dea8fe5f346a5555f4bf479896877579d63e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107748 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-14warning C4189: 'pInst': local variable is initialized but not referencedStephan Bergmann1-2/+0
Change-Id: I8180087a9e9c3a6d6368d6d94d77ca18d303c1bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107724 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann3-4/+7
...for LIBO_INTERNAL_ONLY. These had been missed by 1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take std::u16string_view parameters" because they did not match the multi-overload pattern that was addressed there, but they nevertheless benefit from being changed just as well (witness e.g. the various resulting changes from copy() to subView()). This showed a conversion from OStringChar to std::string_view to be missing (while the corresponding conversion form OUStringChar to std::u16string_view was already present). The improvement to loplugin:stringadd became necessary to fix > [CPT] compilerplugins/clang/test/stringadd.cxx > error: 'error' diagnostics expected but not seen: > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd] > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd] > 2 errors generated. Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-07move various notebookbar widgets into vclCaolán McNamara1-2/+3
and we can drop their factories then Change-Id: I1e261886dd7700710ba628da4bbeeba65efa1531 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107134 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-04update pchesCaolán McNamara1-3/+4
Change-Id: I3e22c2000da03f6f3345353846213203993aa865 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107192 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-03tdf#96505: Get rid of cargo cult long integer literalsGökhan Özeloğlu1-1/+1
Change-Id: I7226f93a87e0b31634a3c0942f3f5ec8778161fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106843 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-12-01tdf#42949 Fix new IWYU warnings in directories s*Gabor Kelemen20-24/+14
Except recently checked sc, sd, svx, sw Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ice1b86628e4f22a39f307b9c5fa567b6ab9d5acb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106917 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-25DdeInitializeW, DdeGetLastError, etc. use UINT as status return typeStephan Bergmann1-1/+1
(As a follow-up, DdeConnection::GetError should probably also be changed from returning tools::Long to something like sal_uInt32.) Change-Id: I3eb4afe66e7a5f4e24a77c52e901163c2d8354e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106581 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-24loplugin:stringviewparam extend to comparison operatorsNoel6-21/+21
which means that some call sites have to change to use unicode string literals i.e. u"foo" instead of "foo" Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-19Clarify DdeData::GetExternalFormat return typeStephan Bergmann2-15/+12
The implementation (in svl/source/svdde/ddedata.cxx) returns any of: * {CF_TEXT=1, CF_BITMAP=2, CF_METFILEPICT=3} from the Windows API; * the return value of Windows API's RegisterClipboardFormatW, which is UINT from the Windows API (i.e., 32-bit unsigned int); * a enum SotClipboardFormatId value, whose underlying type is sal_uInt32. So the natural choice is sal_uInt32 here. (Windows API's UINT would also do, but cannot be used in include/svl/svdde.hxx, which is used on all platforms.) That in turn shows that DdeService's aFormats and HasCbFormat should also use sal_uInt32. (And then, simplify some of the std algorithms use in svl/source/svdde/ddesvr.cxx.) Change-Id: I593d0a7df78bfdd08ce2de04c3da2078d973e262 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106151 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-19svl/source/svdde/ddedata.cxx is only compiled on Windows anywayStephan Bergmann1-4/+0
(cf. svl/Library_svl.mk) Change-Id: Iff41c9c56c1e0ca52ea93268ddfa76b6630d2eb4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106124 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-17loplugin:stringviewparam extend to constructorsNoel1-6/+6
Change-Id: Ia573921566ec6079b843cbcc0401d9d0f5c62089 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105969 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-16tdf#123936 Formatting files in module svl with clang-formatPhilipp Hofer12-201/+129
Change-Id: Iaaac34428ef0e5b8f09f6cbcad16ea5bab145321 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105714 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-11-12New loplugin:stringviewparamStephan Bergmann1-1/+1
...to "Find functions that take rtl::O[U]String parameters that can be generalized to take std::[u16]string_view instead." (Which in turn can avoid costly O[U]String constructions, see e.g. loplugin:stringview and subView.) Some of those functions' call sites, passing plain char string literals, needed to be adapted when converting them. Change-Id: I644ab546d7a0ce9e470ab9b3196e3e60d1e812bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105622 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-11loplugin:stringviewNoel2-2/+2
Add new methods "subView" to O(U)String to return substring views of the underlying data. Add a clang plugin to warn when replacing existing calls to copy() would be better to use subView(). Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11make tools::Long 64-bit on Windows platformNoel Grandin2-8/+8
This is only for the 64-bit windows platform. I don't see the point in messing with the 32-bit platforms, they are (a) become more and more rare (b) unlikely to even have enough available process memory to load extremely large calc spreadsheets The primary problem we are addressing here is bringing Windows-64bit up to same capability as Linux-64bit when it comes to handling very large spreadsheets, which is caused by things like tools::Rectangle using "long", which means that all the work done to make Libreoffice on 64-bit Linux capable of loading large spreadsheets is useless on Windows, where long is 32-bit. The operator<< for tools::Rectangle needs to be inside the tools namespace because of an interaction with the cppunit printing template stuff that I don't understand. SalPoint changed to use sal_Int32, since it needs to be the same definition as the Windows POINT structure. Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-03remove pimpl in SfxBroadcaster/SfxListenerNoel Grandin2-82/+55
and provide an optimised copy constructor, we can avoid a bunch of work. Change-Id: I3a373fbbfab02455e6a65e9036b3629366174379 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105205 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-02move SwCondCollCondChg on top of SfxHintBjoern Michaelsen1-1/+0
... and get rid of ModifyNotifications along the way. Change-Id: I10fc9d24743d50cef771ff63dae004d31dce1846 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105195 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
2020-10-31remove pimpl from FSStorageNoel Grandin2-154/+40
Change-Id: If2db85b2fde3ffdd8aa033de74773327e70d3011 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105082 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-21new tools::Degree10 strong typedefNoel Grandin1-45/+14
partly to flush some use of "long" out the codebase, but also to make it obvious which units are being used for angle values. Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-19use tools::Long in svlNoel7-20/+23
Change-Id: Ic63d3c0ebd1e58d7bab5b0fd6313cabddc16eb98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104517 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-14Resolves: tdf#137453 Implicit conversion from sal_uInt64 to sal_Int32 is bad..Eike Rathke1-13/+14
Change-Id: I5681249808cf623d3b7df09988f285268ea8d85f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104255 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-10-08use sal_Int32 for style-sheet indexNoel Grandin3-47/+43
instead of a mix of unsigned and sal_uInt16. Change-Id: Ice56d58d22856daa6645577610368ba19a849176 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104076 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-06loplugin:const* make some params and methods constNoel1-1/+1
Change-Id: If7fbb25037343e18081a8ee7064840d75e9a45a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104010 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-04loplugin:reducevarscope in store..svtoolsNoel2-6/+3
Change-Id: Iaa6c6eac15cb73fc2a76ba1c5241297c94d297cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103839 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-03use more TOOLS_WARN_EXCEPTIONNoel1-2/+1
Change-Id: I8b5cde993c13e0b7c8c830b1ff698933a6b7cfd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103863 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-02Use the new single-instance="true" attribute in svlStephan Bergmann2-5/+3
Change-Id: Iedd4348f3ea896dc613e0062a1a9cb5904c8bbb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103844 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-01tdf#136728: Revert "tdf#136238 speed up deleting large cross page table"Xisco Fauli1-8/+4
This reverts commit da5c289a9cae5d914937f235694fd5b0cb92547f. Change-Id: Ic6a77ec2cd3b502fb4e94159a0424340850590df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103665 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-26Related: tdf#136985 SfxStringListItem::GetString() crash in empty caseCaolán McNamara1-3/+2
probably since... commit a573b8b21688d9681f4fa129ec37cf89954e9d1c Date: Sat May 21 16:14:56 2011 -0430 Replace List for std::vector in SfxStringListItem. Change-Id: I7060b5693ba08fa5f70cc5cb3ae1b7a4722a31a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103408 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-23Read MOSDocumentLockFile UTF-16 string data with same endiannessStephan Bergmann1-2/+10
...as MSODocumentLockFile::WriteEntryToStream has written it to (i.e., always as UTF-16LE, assuming that is actually the right format to use). The discrepancy between writing and reading the string data appears to be present ever since the code's introduction in 5db1e20b8b0942dac2d50f3cd34532bb61147020 "Introduce new lockfile handler for MSO like lockfiles". This caused CppunitTest_svl_lockfiles to fail on (big-endian) s390x Linux with > svl/qa/unit/lockfiles/test_lockfiles.cxx:578:(anonymous namespace)::LockfileTest::testWordLockFileRT > equality assertion failed > - Expected: LockFile Test > - Actual : 䰀漀挀欀䘀椀氀攀 吀攀猀琀 etc. Change-Id: I97267aa14a3a926e7fd7bb1d2ce7d2de05d52a64 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103238 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-23Convert attribute value to UTF-8 when passing it to libxml2Stephan Bergmann1-1/+2
Using toUtf8, requiring the OUString to actually contain well-formed data, but which is likely OK for this test-code--only function, and is also what similar dumpAsXml functions e.g. in editeng/source/items/textitem.cxx already use. This appears to have been broken ever since the code's introduction in 553f10c71a2cc92f5f5890e24948f5277e3d2758 "add dumpAsXml() to more pool items", and it would typically only have written the leading zero or one (depending on the architecture's endianness) characters. (I ran across it on big-endian s390x, where CppunitTest_sd_tiledrendering SdTiledRenderingTest::testTdf104405 failed because of > Entity: line 2: parser error : Input is not proper UTF-8, indicate encoding ! > Bytes: 0xCF 0x22 0x2F 0x3E > ation=""/><SfxPoolItem whichId="4017" typeName="13SvxBulletItem" presentation="% > ^ apparently reported from within libxml2.) Change-Id: I4b116d3be84098bd8b8a13b6937da70a1ee02c7f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103236 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-09-23tdf#128136: Build curl, nss, and xmlsec for iOS, tooTor Lillqvist1-2/+2
We must link nss statically, including the three dylibs that normally are loaded at run-time, because including bare dylibs in an iOS appp on the App Store is not OK. See https://developer.apple.com/forums/thread/125796 . For linking the softokn3 library statically, NSS already had code, behind NSS_STATIC_SOFTOKEN ifdefs. Introduce two more macros: NSS_STATIC_FREEBL for the freebl library and NSS_STATIC_PKCS11 for the nssckbi library. Turn off parallelism for the sub-make building nss. There seems to be race conditions or something when running simultaneous instances of the nsinstall.py script or the nsinstall program in nss (used when building nss for the build platform). When cross-compiling from macOS, use python3 to run the nsinstall.py script, as it is Python 3. Change-Id: Idd427b5ebf21f802b3feb0d5a3d259317ba8fc67 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103106 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103218 Tested-by: Jenkins
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann6-12/+17
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-10Remove some DBG_UTIL debug codeStephan Bergmann1-72/+2
...that had originally started to get introduced with 159a4c3c75e3a7aecbf1656f3254331892098ba7 "tdf#84881: WiP: Fill in more fields of the TimeStampReq" saying: "Temporarily, dump the TimeStampReq object to a file for inspection in a DBG_UTIL build." (I came across this when wondering why such PDFWRITER.cms.data and PDFWRITER.hash.data files kept popping up in my source/build trees.) Change-Id: I28beabe912beb112e1c71c8e3b559e161b22849b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102393 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Jenkins
2020-09-10tdf#136238 speed up deleting large cross page tableNoel Grandin1-4/+8
Goes from more than 30s to less than 1s on my pc. We were getting stuck inside the loop in sw::UndoManager::AddUndoAction, because the RemoveOldestUndoAction was continually doing nothing because it was hitting the if ( IsInListAction() { assert(!"SfxUndoManager::RemoveOldestUndoActions: cannot remove a not-yet-closed list action!"); return; } code. Which means that there is some bug here, but I'm not sure what. We are deep inside the delete logic at that point, and it doesn't seem unreasonable to opportunistically delete some of the UNDO list at that point. So the real fix is just the conversion from a while loop to an if-check. Change-Id: Ie2707009dd6574b996421f67d952ab9fdaaaf6aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102378 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-07Make the OUString ctors taking raw sal_Unicode pointer/non-const array explicitStephan Bergmann2-3/+3
...and in turn add OUString::operator = and OUString::operator += overloads that take a std::u16string_view. Without making the ctors explicit, the operator overloads would have caused ambiguities when called with raw sal_Unicode pointers/non-const arrays, as those can convert to both OUString and to std::u16string_view. But the std::u16string_view operator overloads will generally be useful when changing OUStringLiteral similarly to 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which point many existing uses of OUStringLiteral will be replaced with uses of std::u16string_view. Implementing this change turned up a need for an operator = overload for OUStringNumber, which has thus been added. No such need turned up for a corresponding operator += overload, but which can easily be added when the need arises. It also revealed that the operator == overloads between an OUString and a raw sal_Unicode pointer/non-const array were implemented rather inefficiently, creating a temporary OUString from the raw argument. Those have been improved. Preceding commits have already taken care of many dubious or simply unnecessary implicit uses of the now-explicit OUString ctors. This commit makes explicit the few remaining reasonable uses. (And in some cases needed to change variable initialization syntax from using parentheses to using curly braces, to avoid the most vexing parse issue. And needed to explicitly add OUString ctors from char16 const[2] string literal lvalues in a conditional expression in writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary because MSVC apparently still insists on doing array-to-pointer decay there.) All of this only affects LIBO_INTERNAL_ONLY. Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-25 22:28:38 +0000