summaryrefslogtreecommitdiff
path: root/svl
AgeCommit message (Collapse)Author
2022-08-28tdf#150452: Revert "tdf#130795 use concurrent hashmap in SharedStringPool"Xisco Fauli
This commit reverts 3749d9af3745c0eaff7239e379578e4e2af89e9d which removes the dependency on the external library cuckoo Without using cuckoo the same file in tdf#130795 takes real 0m4,892s user 0m5,298s sys 0m0,449s With it, it takes real 0m4,914s user 0m5,276s sys 0m0,444s pretty much the same time Change-Id: I4cc9000ac5bf26de22bb9835283ae8d5b3230196 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138435 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138446
2022-06-27Resolves: tdf#147265 Return correct default if currency format is duplicateEike Rathke
For the default currency format SvNumberFormatter::GetCurrencyFormatStrings() returned always the last added position, regardless whether that format was added or not, which it isn't if the format code is a duplicate. Let addToCurrencyFormatsList() return the position of the existing format if the duplicate was rejected and use that for default. Change-Id: I148d7379de75cae402b063f7b2f92947e345176f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136187 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins (cherry picked from commit 36cf12d449c892e6bbacb7da5f4b008f7762232b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136166 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-06-27Resolves: tdf#149484 Handle <number:boolean-style> with <number:text>Eike Rathke
Backport as the current handling when writing such format (even if it doesn't display the text literals) is utterly broken and results in <number:boolean-style style:name="N111"> <number:text>--</number:text> </number:boolean-style> so an implementation correctly reading such (e.g. now upcoming LibreOffice 7.4) would create a format "--" and display that for any value, true or false. This is a combination of 3 commits. Related: tdf#149484 Display BOOLEAN literal string text additions xChange-Id: Ifbaf0b18178091c3a340a7c4bc66f78397aadc18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135506 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins (cherry picked from commit 2932dc7aa0c1239d39e060e6b7627317f1305549) Resolves: tdf#149484 Read and handle <number:text> in <number:boolean-style> xChange-Id: I1be5f2be908eb88aa4ef7436ea7c09f35b076acf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135507 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins (cherry picked from commit 025231224b8b076e280235cd2b943addd2fb0755) Related: tdf#149484 Write proper <number:boolean-style> with <number:text> xChange-Id: I46b7987dde25840ae0b6e5871b14e3806c6e4ac8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135508 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins (cherry picked from commit 33a8c4bd0e8533ab42894280e7e04c13a47aefa9) Change-Id: I1be5f2be908eb88aa4ef7436ea7c09f35b076acf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135586 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2022-05-25svl: spurious GCC12 -Werror=maybe-uninitializedMichael Stahl
In file included from svl/source/misc/sharedstringpool.cxx:11: In constructor ‘svl::SharedString::SharedString(rtl_uString*, rtl_uString*)’, inlined from ‘svl::SharedString svl::SharedStringPool::intern(const rtl::OUString&)’ at svl/source/misc/sharedstringpool.cxx:129:51: include/svl/sharedstring.hxx:56:20: error: ‘pResultUpper’ may be used uninitialized [-Werror=maybe-uninitialized] 56 | mpData(pData), mpDataIgnoreCase(pDataIgnoreCase) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ svl/source/misc/sharedstringpool.cxx: In member function ‘svl::SharedString svl::SharedStringPool::intern(const rtl::OUString&)’: svl/source/misc/sharedstringpool.cxx:93:33: note: ‘pResultUpper’ was declared here 93 | rtl_uString *pResultLower, *pResultUpper; | ^~~~~~~~~~~~ Change-Id: I2171855844c76ad3b2a72c1eca737691ca96fc46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134736 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 694db7d3e7be0caf81dd52dba1a865db206ac145) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134629 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-05-25svl: fix testSignDocument_PEM_PDF with "dbm:" NSS DBMichael Stahl
CentOS 7 system NSS defaults to legacy "dbm:" DB. test_desktop_lib.cxx:2943:Assertion Test name: DesktopLOKTest::testSignDocument_PEM_PDF assertion failed - Expression: bResult NSS_CMSSignerInfo_Sign() (called from NSS_CMSEncoder_Finish()) internally calls PK11_FindKeyByAnyCert() and that fails likely for same reasons as documented in previous commit. The workaround here is a bit more involved, it turns out there's another path with NSSCMSSignerID_SubjectKeyID where the caller can pass in a SECKEYPrivateKey, let's try to do that as a fallback if a manual call to find the key fails. Change-Id: I298ee72f178220bcf644093917dba8143b092c92 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133577 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 5592ee094ca9f09bfcc16537d931518d4e6b2231) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134291 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-05-13svl: fix crash if user cancels/closes master password dialogMichael Stahl
(regression from d7ba5614d90381d68f880ca7e7c5ef8bbb1b1c43) Change-Id: I8bb9a967aefa2e88f05c23456a0dd1a090e1a5fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133932 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit bbb8617ece6d946957c2eb96287081029bce530f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133863 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-04-10Resolves: tdf#148052 accept a ". Month " name for matching DMY formatEike Rathke
... even if the locale doesn't define such DM order or LongDateDaySeparator. Change-Id: I4bef720dff3582de9b60313824a84b570c153e98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132741 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins (cherry picked from commit 7a16002ede5fd31ae8f3358136ad49de40465ac1) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132703 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-04-06add Initialization Vectors to password storageCaolán McNamara
old ones default to the current all zero case and continue to work as before Change-Id: I6fe3b02fafcce1b5e7133e77e76a5118177d77af Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131974 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 192fa1e3bfc6269f2ebb91716471485a56074aea) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132186 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2022-03-25make hash encoding match decodingCaolán McNamara
Seeing as old versions of the hash may be in the users config, add a StorageVersion field to the office config Passwords section which defaults to 0 to indicate the old hash is in use. Try the old varient when StorageVersion is 0. When a new encoded master password it set write StorageVersion of 1 to indicate a new hash is in use and use the new style when StorageVersion is 1. Change-Id: I3174c37a5891bfc849984e0ec5c2c392b9c6e7b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132041 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-14tdf#145868 sd replace: if search changes, restart find/replaceJustin Luth
REPLACE is really a replaceAndFind instead of a findAndReplace. Thus, when you changed your search parameter and did a replace, it replaced the previously searched for item, and then found the first instance of the new search parameter. That of course is just wrong. So make sure to verify that the previous search matches the current search competely. However, that doesn't mean that the entire searchItem matches, since we don't want to restart the search just because the replace parameter changed. In my testing, this wasn't an issue for REPLACE_ALL. So the only time we need to worry about the last search result is in a replace once situation. P.S. This commit exposed that mpSearchItem can point to a destructed SvxSearchItem, so this patches unit test will crash if the other 7.4 commit is missing. Change-Id: I7be14d64534018718145c6ac5f8629ff5f2e5611 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129385 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129630
2022-01-31fix loading file with very large number of stylesNoel Grandin
where nCurrentPosition was wrapping around Change-Id: I839215f3138d58884f03509b6341147ef28edb4c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129108 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> (cherry picked from commit 7f3682ecb8a40fe85b6525be9e73d49d76bb308b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129075
2021-12-15tdf#145381 handle closing brackets in URLs correctlyArmin Le Grand (Allotropia)
The task presents an URL that ends with a closing bracket. If pasted to LO, the closing bracket got interpreted as not being part of the URL due to the heuristical interpretation of URLs in urihelper. Adapted this to handle matching brackets, so that an closing and ending bracket will be added to the uri text when there is a matching pair. Added unit test to testFindFirstURLInText with simplified uri example. Change-Id: I58dd460a37d0066ff46845832eabd2a790e4ccd1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126832 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 76f29376183be48c076ada06159581ea981de3d1) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126872 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-12-06make it clearer that ScHint is modifiedLuboš Luňák
It's somewhat confusing that an accessor is provided to give a reference to internal data and then the object is modified indirectly using the reference. It appears to be only for performance reasons, so I thought that inlining the ctor and ctor could help the compiler to optimize this, but apparently it can't move this outside of the loop, so at least make it clearer. Change-Id: I72cf15d1446daa559ac4079b9478e53694d7d198 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126394 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126447
2021-11-23make a bunch of svl::SharedString functions inlineLuboš Luňák
They are tiny and they are used in performance-critical parts of Calc. Change-Id: If227b11ac7929dd1369545a590d8ef1a977185f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125698 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-20tdf#133835 speedup calc autofilter (1)Noel Grandin
avoid a copy in INetURLHistory::QueryUrl, saves 10% Change-Id: I662a4e48f198e61f1cef52b1e920613bce9c9766 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125563 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-11-19loplugin:stringliteraldefine in svlNoel Grandin
Change-Id: I49a8062c30bdce5b0d9bd27e421d85ba61d5592e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125544 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-11-18tdf#140086 svl: restore PasswordContainer to single-instanceMichael Stahl
(regression from 7256ff08bc46840bb85fa255ace6541dca91329e) Change-Id: Ib640dea001fc787279761ca72bbc3db46d0102c2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125485 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins
2021-11-18rtl::Static->thread-safe static in svlNoel Grandin
Change-Id: Idadc4dc77eb681a8b8923ffacf37ddbe1d8245e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125425 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-11-15svl: use std::rotate() in SfxUndoManager::ImplUndo()Miklos Vajna
Instead of manually moving out, moving a range and then moving in. Change-Id: Iaff461e1fcee3936c8ddc02bf471a804e7881aef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125219 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-11-12sw, out of order undo: allow multiple actions from other viewsMiklos Vajna
Previously we assumed that the action to be executed is always exactly the top of the undo stack minus 1 element. Extend this, so that in case an other view appends two or more elements to the undo stack, we still find our undo action. Obviously only do this if all those undo actions are independent from us. This requires replacing the swap in svl/ with a move-out + move a range down + move in construct. Change-Id: Ic12d32d6eb5e77618d99eddb4fa096802f32d655 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125076 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-11-11sw, out of order undo: allow a subset of a non-empty redo listMiklos Vajna
Specifically, we used to not allow out of order undo at all if the redo list was non-empty. This relaxes that condition a bit. Out of order undo is OK with a non-empty redo list, in case all undo actions in the redo list are either 1) owned by the current view or 2) independent from the undo action to be executed I.e. if view1 has lots of type undo actions and an view2 adds a single type undo action on top of it, then allow view 1 to execute multiple of its typing undo actions, not just a single one. Change-Id: I2f5d9404a9994ed74b65233d2a315976c27b28b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125023 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-11-10sw: allow undo of typing in 2 views independent from each otherMiklos Vajna
Undoing out of order is dangerous by default, so limit this to a very specific case as a start, that allows growing in follow-up commits. For now, allow out of order undo if: 1) redo stack is empty 2) we're in LOK mode (different views represent different users) 3) we undo a single action (count is 1) 4) the top undo action doesn't belong to the current view 5) the top and the previous undo actions are independent Which only requires that SwUndoInsert::UndoImpl() is independent for two different paragraphs, which seems to be the case. Independent undo actions opt in for this, currently the only such allowed undo action is SwUndoInsert ("typing"), which adds characters to a single text node. Even those are only considered independent if they operate on different text nodes. On the positive side, this allows out of order undo in the frequent case where two users collaborate on a long document and they just type some new content into the document at different paragraphs. Change-Id: Ibb4551e8f7046b4947491b8bf751eaa0cbb2d060 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124949 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-11-07Resolves: tdf#145386 Use "Default" for LANGUAGE_PROCESS_OR_USER_DEFAULTEike Rathke
There's no, specifically not in Writer, handling of the LCID 0x0400 LANGUAGE_PROCESS_OR_USER_DEFAULT language/locale concept other than the number formatter mapping it to LANGUAGE_SYSTEM. Use the LANGUAGE_SYSTEM "Default" string in UI (status bar, status menu, language list) but keep the LCID, and don't append the resolved locale string as it is also displayed both in the Font Western and CJK listboxes. This ends up as two list entries, like * Default - English (UK) first entry * Default last entry of which the second would be selected. Change-Id: I8d9e4171bee6bbe9d1c9dcfb7a5fa8fc92ea1a2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124449 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-10-31Prepare for removal of non-const operator[] from Sequence in svlMike Kaganski
Change-Id: I6b71a075de5d5ac002dc48cd2bb21ff5bf5dd072 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124395 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-29Fix misuses of NULL across Windows-only codeStephan Bergmann
...which defines NULL as a plain 0 integer literal instead of the GNU __null extension, so clang-cl's -Wnull-conversion cannot kick in. These findings are from an experimental build done with clang-cl and a modified > --- a/clang/lib/Headers/stddef.h > +++ b/clang/lib/Headers/stddef.h > @@ -83,6 +83,10 @@ typedef __WCHAR_TYPE__ wchar_t; > # if !defined(__MINGW32__) && !defined(_MSC_VER) > # define NULL __null > # else > -# define NULL 0 > +# if __cplusplus >= 201103L > +# define NULL nullptr > +# else > +# define NULL 0 > +# endif > # endif > #else > # define NULL ((void*)0) However, that build also ran into lots of places where 3rd-party code in external/ and Windows system headers caused issues when NULL is nullptr (which I worked around with various hacky patches for that build), so this is unfortunately not something that can easily be enabled generally. Change-Id: I10674464498a9bc63578d9e6cc32ddde23ab4f30 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124419 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-26tdf#131025 swtable: don't apply number format to non-number textJustin Luth
Applying a numbering style to text causes export to save that out as a number (valued as zero). That is not good because the ODF spec says that a number overrides a string. So don't accept a numbering format on non-number text. Why is this change good? -the cell previously had no direct formatting (by definition). -the cell's previous old format was text (tested). -any numbering format applied obviously isn't correct (by definition). -any previous formatting has already been overwritten with numformat. -the default numbering is appropriate for text. -empty cells still get the numbering format (tested). -odd human-designed formats are accepted as intentional (tested). What are the concerns? -the scope of this change is HUGE, way beyond this bug. -on both my dev box and patch box I saw occassional crashes. -the bug was "fixed" by a different import commit that ensured different languages were treated consistently. So this patch is no longer critical, just nice to have to avoid exporting out-of-spec content. Change-Id: Id3dc5f803c3cf4875bc0cab52d1019a18679da77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123904 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Eike Rathke <erack@redhat.com>
2021-10-25Restore behaviour SvNumberFormatterServiceObj keep LANGUAGE_SYSTEM unresolvedEike Rathke
Semantics were temporarily changed with commit bba6a4ed92a0feb288a9dedd648d623bee02a3ce CommitDate: Mon Oct 25 11:18:31 2021 +0200 Get rid of fuzziness in MsLangId::Conversion::convertIsoNamesToLanguage() Change-Id: I8bbf77998bea81c5691ba518c7ae25093b0df421 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124141 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-10-25Get rid of fuzziness in MsLangId::Conversion::convertIsoNamesToLanguage()Eike Rathke
With on-the-fly LanguageTag the fuzzy fallbacks for a few languages aren't needed anymore. Proper fallbacks should be obtained when needed, like when configuring default locales, or configured values used after. Change-Id: I8b85b8099e085508435036ac846db6c3e516dc23 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124127 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-10-25Fix stack-use-after-scopeStephan Bergmann
...during CppunitTest_svl_qa_cppunit, after df42cb6552b20372f62b5a361709670db80e4ed4 "Optimize assignment from OUStringLiteral to OUString", > ==918==ERROR: AddressSanitizer: stack-use-after-scope on address 0x2b2e203b5900 at pc 0x2b2e1b9004f8 bp 0x7ffc06726270 sp 0x7ffc06726268 > READ of size 4 at 0x2b2e203b5900 thread T0 > #0 0x2b2e1b9004f7 in void rtl::str::release<_rtl_uString>(_rtl_uString*) /sal/rtl/strtmpl.hxx:1064:9 > #1 0x2b2e1b8d916c in rtl_uString_release /sal/rtl/ustring.cxx:1785:12 > #2 0x2b2e36263ec5 in rtl::OUString::~OUString() /include/rtl/ustring.hxx:493:9 > #3 0x2b2e3622c5ff in (anonymous namespace)::Test::testTdf103060() /svl/qa/unit/svl.cxx:553:1 [...] > [2304, 2320) 'EXPECTED_G3' (line 550) <== Memory access at offset 2304 is inside this variable (<https://ci.libreoffice.org/job/lo_ubsan/2176/>). (aa2064c5c5f23f6f4b7bc44e12345b37f66995bc "Improve loplugin:stringliteralvar" had failed to introduce those OUStringLiteral variables as static.) Change-Id: I59168979fcc4b055d17d1d4f315577eef1027505 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124134 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-16Simplify vector initialization in svlJulien Nabet
Change-Id: I8ff1eb008f3173791c7c1020db08d29451998f42 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123699 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-15Remove non-const Sequence::begin()/end() in internal codeMike Kaganski
... to avoid hidden cost of multiple COW checks, because they call getArray() internally. This obsoletes [loplugin:sequenceloop]. Also rename toNonConstRange to asNonConstRange, to reflect that the result is a view of the sequence, not an independent object. TODO: also drop non-const operator[], but introduce operator[] in SequenceRange. Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-14Avoid COW overhead using css::uno::SequenceMike Kaganski
The scenarios are: 1. Calling sequence's begin() and end() in pairs to pass to algorithms (both calls use getArray(), which does the COW checks) 2. In addition to #1, calling end() again when checking result of find algorithms, and/or begin() to calculate result's distance 3. Using non-const sequences in range-based for loops, which internally do #1 4. Assigning sequence to another sequence variable, and then modifying one of them In many cases, the sequences could be made const, or treated as const for the purposes of the algorithms (using std::as_const, std::cbegin, and std::cend). Where algorithm modifies the sequence, it was changed to only call getArray() once. For that, css::uno::toNonConstRange was introduced, which returns a struct (sublclass of std::pair) with two iterators [begin, end], that are calculated using one call to begin() and one call to getLength(). To handle #4, css::uno::Sequence::swap was introduced, that swaps the internal pointer to uno_Sequence. So when a local Sequence variable should be assigned to another variable, and the latter will be modified further, it's now possible to use swap instead, so the two sequences are kept independent. The modified places were found by temporarily removing non-const end(). Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-12Revert "Use placement new to avoid one of the allocation calls..."Stephan Bergmann
This reverts commit 503ab1ca9ae11978d9717557546c01ff598aaf88, plus follow-up 17915ab5202a4d7456e9bc031c3f6a72bc861844 "fix ubsan alloc-dealloc-mismatch". It failed to properly destroy the object assembly, and caused e.g. CppunitTest_svl_items to fail with > ==850754==ERROR: AddressSanitizer: new-delete-type-mismatch on 0x6060000024e0 in thread T0: > object passed to delete has wrong type: > size of the allocated type: 64 bytes; > size of the deallocated type: 56 bytes. > #0 in operator delete(void*, unsigned long) at /home/sbergman/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:164:3 (workdir/LinkTarget/Executable/cppunittester +0x330ae2) > #1 in SfxItemSet::~SfxItemSet() at svl/source/items/itemset.cxx:202:1 (instdir/program/libsvllo.so +0x110ccf6) > #2 in std::default_delete<SfxItemSet>::operator()(SfxItemSet*) const at /home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/unique_ptr.h:85:2 (instdir/program/libsvllo.so +0x1142a28) > #3 in std::_Sp_counted_deleter<SfxItemSet*, std::default_delete<SfxItemSet>, std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() at /home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/shared_ptr_base.h:442:9 (instdir/program/libsvllo.so +0x12696e4) > #4 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() at /home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/shared_ptr_base.h:168:6 (instdir/program/libsvllo.so +0xe500b5) [...] > 0x6060000024e0 is located 0 bytes inside of 64-byte region [0x6060000024e0,0x606000002520) > allocated by thread T0 here: > #0 in operator new(unsigned long) at /home/sbergman/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:95:3 (workdir/LinkTarget/Executable/cppunittester +0x32fe7d) > #1 in SfxItemSet::Clone(bool, SfxItemPool*) const at svl/source/items/itemset.cxx:1270:34 (instdir/program/libsvllo.so +0x1127854) > #2 in (anonymous namespace)::Node::setItemSet(SfxItemSet const&) at svl/source/items/stylepool.cxx:65:107 (instdir/program/libsvllo.so +0x1212179) > #3 in StylePoolImpl::insertItemSet(SfxItemSet const&, rtl::OUString const*) at svl/source/items/stylepool.cxx:417:19 (instdir/program/libsvllo.so +0x12103e1) > #4 in StylePool::insertItemSet(SfxItemSet const&, rtl::OUString const*) at svl/source/items/stylepool.cxx:456:17 (instdir/program/libsvllo.so +0x1212ffb) [...] in Clang ASan builds done with -fsized-deallocation. Change-Id: I3ccba7e7d9712ecabf38a0149252d3cd70cdb446 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123446 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-11In O[U]StringBuffer, make string_view params replacements for OUString onesStephan Bergmann
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That way, loplugin:bufferadd and loplugin:stringviewparam found many further opportunities for simplification (all addressed here). Some notes: * There is no longer an implicit conversion from O[U]String to O[U]StringBuffer (as that goes via user-defined conversions through string_view now), which was most noticeable in copy initializations like OStringBuffer buf = someStr; that had to be changed to direct initialization, OStringBuffer buf(someStr); But then again, it wasn't too many places that were affected and I think we can live with that. * I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to get them in line with their counterparts taking O[U]String. * I added an OUStringBuffer::lastIndexOf string_view overload that was missing (relative to OUStringBuffer::indexOf). * loplugin:stringconstant needed some addition to keep the compilerplugins/clang/test/stringconstant.cxx checks related to OStringBuffer::append and OStringBuffer::insert working. * loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related code that had been introduced in 1250aecd71fabde4dba990bfceb61bbe8e06b8ea "loplugin:stringviewparam extend to new.." Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-10loplugin:moveparam in svlNoel Grandin
Change-Id: Icd45c7f693c866e7eafcf6aeb052a4d190dce38c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123337 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-08loplugin:moveparam in svlNoel Grandin
Change-Id: I58c1ef97fd6cba281c90cc7ed9917e04b7f265ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123187 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-05drop 'using namespace std' in s* + toolkitJulien Nabet
Change-Id: Ibd0b983d46a5683df64b4de79cd444427705e9e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123118 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-05fix ubsan alloc-dealloc-mismatchNoel Grandin
after commit 503ab1ca9ae11978d9717557546c01ff598aaf88 Author: Noel Grandin <noelgrandin@gmail.com> Date: Sat Oct 2 16:28:56 2021 +0200 Use placement new to avoid one of the allocation calls... Change-Id: I2eb85c5c1be5d2eaf757d717f03873415e49c9a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123083 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-04Fix typosAndrea Gelmini
Change-Id: Id88532da843e659d337f3529333a17a0c00c8328 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123050 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-03Use placement new to avoid one of the allocation calls...Noel Grandin
...when cloning a SfxItemSet. Change-Id: I344fee3863006066eade16db9df37599fc210be3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123001 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-03A more lightweight O[U]StringConcatenationStephan Bergmann
...compared to a full-blown O[U]String, for temporary objects holding an O[U]StringConcat result that can then be used as a std::[u16]string_view. It's instructive to see how some invocations of operator ==, operator !=, and O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit materialization of an O[U]String temporary, and how that expensive operation has now been made explicit with the explicit O[U]StringConcatenation ctor. (The additional operator == and operator != overloads are necessary because the overloads taking two std::[u16]string_view parameters wouldn't even be found here with ADL. And the OUString-related ones would cause ambiguities in at least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with RTL_STRING_UNITTEST, so have simply been disabled for that special test-code case.) Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-30loplugin:constmethod handle more casesNoel Grandin
remove some of the naming limitations, and handle pointer parameters better. I only let the plugin run up till vcl/ Change-Id: Ice916e0157031ab531c47f10778f406b07966251 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122892 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-30tdf#144697: svl_qa_cppunit: Add unittestXisco Fauli
Change-Id: I7a62f7c5c8e6fceebcb9671fa28ec98dd7a312a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122878 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-09-30loplugin:constparams improve handling of pointer paramsNoel Grandin
Change-Id: I4c0002e72703eded435bfe4985f5b0121bf8524b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122843 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-30Resolves: tdf#144697 Format out-of-bounds date(+time) as #FMT errorEike Rathke
i.e. < -32768-01-01 or > 32767-12-31 They couldn't be input or stored as proleptic Gregorian in file formats anyway. Additionally in i18npool handle the absolute year values casting conversion int32 <-> int16 where era 0 BCE year 32768 is fielded as -32768 but still is a valid year for our proleptic Gregorian, so it isn't displayed as --32768. Change-Id: Ifdd482f07e04c2a4296fd0556bbef7f1d3e15676 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122835 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-09-28drop 'using namespace std' hereRoman Kuznetsov
Change-Id: Ifbbd6e985fb66893dc872522ed5418453ca8e2d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122651 Tested-by: Jenkins Reviewed-by: Roman Kuznetsov <antilibreoffice@gmail.com>
2021-09-23Sort ZF_STANDARD_NEWEXTENDED_DATE_... into ZF_STANDARD_DATE categoryEike Rathke
The legacy of binary file format compatible internal indices is gone so categories can as well be enlargened. It doesn't really matter, just a "nicer to see" sequence. Change-Id: Id20e08e8564a281859164d44e2e863e46689b2b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122540 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-09-23Reorder the internal ZF_STANDARD_DATETIME offsets to a more logical sequenceEike Rathke
These once were to be strictly kept for the binary file format but nowadays only serve as a position / key index offset within the numberformat map. Change-Id: I7c61852cc26463b1d4d67a6152501d521440abe1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122530 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-09-23Add not-quite-ISO date+time with space and milliseconds and locale's separatorEike Rathke
NF_DATETIME_ISO_YYYYMMDD_HHMMSS000 YYYY-MM-DD HH:MM:SS.000 Users may expect to see that if they enter such, instead of the real ISO 8601 "T" format. Change-Id: Iad81750d1c74eedd8d4360163b29ecac98ef6824 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122502 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-09-21Add ISO 8601 date+time with milliseconds formatEike Rathke
NF_DATETIME_ISO_YYYYMMDDTHHMMSS000 YYYY-MM-DD"T"HH:MM:SS,000 using either ',' or '.' separator, '.' if Time100SecSep is '.' ',' else A prerequisite for tdf#88359 to not lose data when importing such, especially without "Detect special numbers" on. Change-Id: I02ab682636e6ddbcc4537183a3625ea61662f016 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122400 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
generated by cgit (git 2.34.1) at 2025-03-11 00:28:24 +0000