summaryrefslogtreecommitdiff
path: root/svl
AgeCommit message (Collapse)AuthorFilesLines
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>
2020-09-04TabPage no longer needs to inherit from VclBuilderContainerCaolán McNamara1-1/+4
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 Bergmann1-1/+1
...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 Kaganski6-28/+27
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 Kaganski2-50/+30
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 Bergmann4-22/+22
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 McNamara1-1/+1
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 Grandin2-6/+4
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 McNamara1-3/+1
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 Grandin1-1/+1
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 Gelmini1-1/+1
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 Grandin2-20/+20
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 Grandin2-3/+3
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 Grandin1-2/+4
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 McNamara1-2/+2
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 Grandin1-13/+13
Change-Id: I6560756eb63856a22b43e3e65a7b7843cd2d5376 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100447 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-06Resolves: tdf#135249 Duration input 0:123 or 0:0:123 or 0:123:59 is validEike Rathke1-4/+9
Change-Id: Ie624b324822495192edc65d046945eb92356550b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100192 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-08-03tdf#42949 Fix IWYU warnings in include/[t-x]*/*hxxGabor Kelemen1-0/+1
Recheck after 7-0 branchoff Also drop the now unused file include/vcl/field.hxx Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I9e54c82f50d1e02a0f99858939cac999fc66f7de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99261 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-07-29replace and drop MiscCfgCaolán McNamara1-3/+2
Change-Id: I5ea9e3663fc5d30d725cf18757badb9b9802da18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99675 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-15comphelper: don't hardcode hash sizes in Hash::getLength()Miklos Vajna1-3/+3
Instead move the constants from filter to comphelper and reuse them. Change-Id: Ib7061e9028ccf6067b4e86f50145c1472c2b01d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98785 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-07-15svl/fsstorage: create instances with uno constructorsNoel Grandin3-58/+13
See tdf#74608 for motivation. Change-Id: If5eec92f2c7707bd0c44b80d352d78a84962ff74 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98702 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-14svl/passwordcontainer: create instances with uno constructorsNoel Grandin3-68/+11
See tdf#74608 for motivation. Change-Id: Ib543223f87e1773645ff6063e7f9f902ff408f33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98701 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-12update pchesCaolán McNamara1-1/+3
Change-Id: I75602277a5a26b012a12f2c4f4b7ff5bb663b0b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98474 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-10replace usage of blacklist with excludelist for IWYUThorsten Behrens1-1/+1
Background and motivation: https://tools.ietf.org/html/draft-knodel-terminology-02 Change-Id: I2f22d455d2a936a85750eaab1fda215ebb6d9d48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98182 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-17 00:38:55 +0000