summaryrefslogtreecommitdiff
path: root/svl
AgeCommit message (Collapse)Author
2020-12-14warning C4189: 'pInst': local variable is initialized but not referencedStephan Bergmann
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 Bergmann
...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 McNamara
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 McNamara
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ğlu
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 Kelemen
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 Bergmann
(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 operatorsNoel
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 Bergmann
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 Bergmann
(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 constructorsNoel
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 Hofer
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 Bergmann
...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:stringviewNoel
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 Grandin
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 Grandin
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 Michaelsen
... 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 Grandin
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 Grandin
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 svlNoel
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 Rathke
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 Grandin
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 constNoel
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..svtoolsNoel
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_EXCEPTIONNoel
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 Bergmann
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 Fauli
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 McNamara
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 Bergmann
...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 Bergmann
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 Lillqvist
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 Bergmann
...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 Bergmann
...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 Grandin
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 Bergmann
...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>
2020-09-04TabPage no longer needs to inherit from VclBuilderContainerCaolán McNamara
Change-Id: Iaab26ade1109daf732e58a2f3741cc43243e374c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102023 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-04Make many OUString functions take std::u16string_view parametersStephan Bergmann
...instead of having individual overloads for OUString, OUStringLiteral, and literal char16_t const[N]. (The variants taking OUString are still needed for !LIBO_INTERNAL_ONLY, though. The variants taking ASCII-only literal char const[N] are also left in place.) This nicely reduces the number of needed overloads. std::u16string_view allows to pass as arguments: * OUString * OUStringLiteral * OUStringChar (with the necessary conversion added now) * OUStringNumber * u"..." char16_t string literals * u"..."sv std::u16string_view literals * std::u16string, plain char16_t*, and more A notable exceptions is OUStringConcat, which now needs to be wrapped in OUString(...), see the handful of places that needed to be adapted. One caveat is the treatment of embedded NUL characters, as std::u16string_view(u"x\0y") constructs a view of size 1, while only u"x\0y"sv constructs a view of size 3 (which matches the old behavior of overloads for literal char16_t const[N] via the ConstCharArrayDetector<>::TypeUtf16 machinery). See the new checkEmbeddedNul in sal/qa/rtl/strings/test_oustring_stringliterals.cxx. The functions that have been changed are generally those that: * already take a string of determined length, so that using std::u16string_view, which is always constructed with a determined length, is no pessimization (e.g., there are operator == overloads taking plain pointers, which do not need to determine the string length upfront); * could not benefit from the fact that the passed-in argument is an OUString (e.g., the corresponding operator = overload can reuse the passed-in OUString's rtl_uString pData member); * do not run into overload resolution ambiguity issues, like the comparison operators would do. One inconsistency that showed up is that while the original replaceAll(OUString const &, OUString const &, sal_Int32 fromIndex = 0) overload takes an optional third fromIndex argument, the existing replaceAll overloads taking OUStringLiteral and literal char16_t const[N] arguments did not. Fixing that required a new (LIBO_INTERNAL_ONLY) rtl_uString_newReplaceAllFromIndexUtf16LUtf16L (with test code in sal/qa/rtl/strings/test_strings_replace.cxx). Another issue was posed by test code in sal/qa/rtl/strings/test_oustring_stringliterals.cxx that used the RTL_STRING_UNITTEST-only OUString(Except*CharArrayDetector) ctors to verify that certain function calls should not compile (and would compile under RTL_STRING_UNITTEST by taking those Except*CharArrayDetector converted to OUString as arguments). Those problematic "should fail to compile" tests have been converted into a new CompilerTest_sal_rtl_oustring. Change-Id: Id72e8c4cc338258cadad00ddc6ea5b9da2e1f780 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102020 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-03Make ImpSvNumberformatScan::GetColor constMike Kaganski
Change-Id: Idbcce18029944ab884cdde03e21190cbb574a00f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102005 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2020-09-03Simplify standard color initializationMike Kaganski
Change-Id: Ife1c8365298fec713713739073b91d601b459e6e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101990 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann
This is a prerequisite for making conversion from OUStringLiteral to OUString more efficient at least for C++20 (by replacing its internals with a constexpr- generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount, conditionally for C++20 for now). For a configure-wise bare-bones build on Linux, size reported by `du -bs instdir` grew by 118792 bytes from 1155636636 to 1155755428. In most places just a u"..." string literal prefix had to be added. In some places char const a[] = "..."; variables have been changed to char16_t, and a few places required even further changes to code (which prompted the addition of include/o3tl/string_view.hxx helper function o3tl::equalsIgnoreAsciiCase and the additional OUString::createFromAscii overload). For all uses of macros expanding to string literals, the relevant uses have been rewritten as u"" MACRO instead of changing the macro definitions. It should be possible to change at least some of those macro definitions (and drop the u"" from their call sites) in follow-up commits. Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-27remove some unused includes and update pchesCaolán McNamara
Change-Id: I786548bef39fa711aabcff32b592b3fdc4a6f9fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101486 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-27expand out StringSet typedefNoel Grandin
Change-Id: If7791d51d055ad918b54a52bee3f13a79c5468f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101435 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-19update pchesCaolán McNamara
Change-Id: I6a300169d33bdc36e4c7e720a7afc336a86eea68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100962 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-14loplugin:simplifybool moreNoel Grandin
look for expressions like !(a && !b) which can be expanded out Change-Id: I72515a9638762b050f9a258c08da39ebfa2ef8e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100579 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-13Fix variable name bAcceptEnmptyAndrea Gelmini
Change-Id: Ie3fe919a7b8296440cd2a670f218147da98f7822 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100653 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net> Tested-by: Jenkins
2020-08-13use OUStringLiteral in SfxItemPropertyMapEntryNoel Grandin
Change-Id: I4f05b6a35010e661ea77f3e4b83302d2ec74d227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100405 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-13loplugin:stringstatic also look for local staticsNoel Grandin
Add some API to O*StringLiteral, to make it easier to use in some places that were using O*String Change-Id: I1fb93bd47ac2065c9220d509aad3f4320326d99e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100270 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-12expand out DELETEZNoel Grandin
Change-Id: Ia69fb105c6cc661ac94a360d47655b3faa9d6bb8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100618 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-12SvTreeListBox can move into toolkit headers nowCaolán McNamara
Change-Id: I6b3b6ef1530a192f4b6bf87aa9688687063683ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100591 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-11loplugin:flattenNoel Grandin
Change-Id: I6560756eb63856a22b43e3e65a7b7843cd2d5376 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100447 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2025-02-11 18:14:31 +0000