summaryrefslogtreecommitdiff
path: root/svl
AgeCommit message (Collapse)Author
2024-06-05Revert "tdf#160706 speed up loading conditional formatting rule in XLS (II)"Henry Castro
This reverts commit 13d39423a8bb70c08052fb02ef41cf3ea6f731d1. Unfortunately, it breaks copy/pasting slide. Change-Id: I1831aac9e672cf66dea658979e98855529b94b07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168473 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-05-10drop requirement for rtl_random_getBytes to have "Pool" argCaolán McNamara
Seeing as since: commit e9531b792ddf0cfc2db11713b574c5fc7ae09e2c Date: Tue Feb 6 14:39:47 2024 +0100 sal: rtlRandomPool: require OS random device, abort if not present Both rtl_random_createPool() and rtl_random_getBytes() first try to get random data from the OS, via /dev/urandom or rand_s() (documented to call RtlGenRandom(), see [1]). we don't use the initial arg to rtl_random_getBytes anymore, drop the requirement to have one. Then simplify our usages of that, and addtionally deprecate rtl_random_createPool and rtl_random_destroyPool. Change-Id: I13dcc067714a8a741a4e8f2bfcf2006373f832c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167335 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2024-05-08Related: tdf#160056 1 entry is more common than no entriesCaolán McNamara
Change-Id: I78fe8969120f894cf5c0a71fb61611af2d203d18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166065 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit 7f2283c2986ff94766cc1d2c076fb34a2c88a31a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166302 Reviewed-by: Eike Rathke <erack@redhat.com> (cherry picked from commit 46bd13a55492adef4bf95133d7123494a62f549a)
2024-05-08Related: tdf#160056 various functions and objects that can be constCaolán McNamara
this formatter can be const Change-Id: I2cd83140585e0b7027bb1c165a8d59e51cbbaad0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164728 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> SvNumberformat::ImpGetFractionOfSecondString can be const Change-Id: If7a31f8b3667d9a6b8719553567211071bd2d631 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164774 Tested-by: Jenkins Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> ImpIsEntry can be const Change-Id: Id229344a68925a1bde84f2b4aad46cfc5f01b797 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164769 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> SvNumberformat::ImpGetLogicalOutput can be const Change-Id: I847e5de84f0636b5a169f383e319a6b8707cc31f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164773 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> SvNumberFormatter::GetUserDefColor can be const Change-Id: If499e28e5ac69018b35b475a73ecb2dc4b78dad6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164786 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> These methods can be const too Change-Id: Iaef46216dac6584f57b7933d658384f54d0a4544 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164772 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166125 Reviewed-by: Eike Rathke <erack@redhat.com> (cherry picked from commit e3e9d51c2d4bed475f9848c62c7b0e5c72d5e125)
2024-05-08Related: tdf#160056 various methods that don't need to be exportedCaolán McNamara
IsSpecialStandardFormat can be private, only used internally and rename to ImpIsSpecialStandardFormat Change-Id: Ie20c83906559f94e545f384807396ec8acf970f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164537 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> ResetDefaultSystemCurrency can be private only called by a friend from the same .so Change-Id: I5f63e83325b291b95b0132089dc331f3b7e79362 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164538 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> GetNonEndOfPathToken can be private Change-Id: Iebf8b84c205eee083ecf8b436520911ba132fe5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164703 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Related: tdf#160056 can be private and not exported Change-Id: I3da15340809603b991d3a41beb2af7a0ba375acc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165137 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Related: tdf#160056 ImpSubstituteEntry can be private and not exported Change-Id: I895db1f02338b6c2a1fec8bdfc15c2857fbee38f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165138 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166124 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 78b62dadcc119359e9fd5ceb670e2585d18d4c3a)
2024-05-07tdf#160706 speed up loading conditional formatting rule in XLS (II)Noel Grandin
Reduce the work we do in IndexedStyleSheets::Reindex takes my test document from 117s to 48s Change-Id: I2e23b05684d0f2e3a9dc05c0a0fc4e9bbea7008d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166180 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> (cherry picked from commit 5060893f0b69c094beae73ab1a0926e3feb249b2) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166900 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2024-04-29lok: save correct number format in multi-lang sessionSzymon Kłos
Number formats can have different keywords in different languages: D - Day(EN), T - Tag(DE). This can cause problem when we use format which will not be recognized by current number formatter, then we put unknown keyword as string in quotes. As the result we get for example: formatCode="&quot;TT.&quot;mm&quot;.JJJJ&quot;" The problem exists especially in multi-language setup in LOK when we use non-English languages: 1. open xlsx using FR 2. join with DE 3. modify number formats in both 4. leave spreadsheet with both so it will be saved Result: after we open it again we have some keywords as strings, user has to apply new number format to see the real value Signed-off-by: Szymon Kłos <szymon.klos@collabora.com> Change-Id: Ice04d890b38cd2d08d06f41fc7b3cc55f64fadbe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166719 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-04-15Related: tdf#160056 this can be staticCaolán McNamara
Change-Id: I1172854a1bf00e74adbe350c54e4e98ea38b0b35 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165072 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit 49189bb8823adc6a76d3f33b34c02d6a640df96a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165746 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> (cherry picked from commit ba5cbbccefb5d55e19ed928cf900f8afb8337e9d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166120 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2024-04-15IniLnge is set during ctor and never changes subsequentlyCaolán McNamara
so no lock is needed for it Change-Id: I00461d44f78e9776568492fccb7dee0e9869944e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164848 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit ee5b9597605176af0c80f9ea28caac9ba7980254) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165749 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166119 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2024-04-15Related: tdf#160056 this can be be a local functionCaolán McNamara
Change-Id: I0ffebd5a1f871b86507d0c1b3946b32993d76365 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165106 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit e8d01d2447b3350f1bd24e07580402c4c699756c) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165747 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2024-03-27tdf#160306: make sure that SvNumberFormatter agrees with ROUND outputMike Kaganski
After commit 9eb9083ff2fdaeb96399a0830a4394de4e29ef64 (Use Dragonbox to implement doubleTo*String*, 2022-02-18), the rounding that is used in SvNumberFormatter became strictly more correct; however, it now differed from what ROUND spreadsheet function returned, because the latter uses rtl_math_round, which calls rtl::math::approxFloor. To make the visual number representation consistent, this change uses rtl_math_round in SvNumberformat::ImpGetNumberOutput. Change-Id: I05b0bed7d3a6c73584a77adbae2835c95be249fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165142 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 805dd6bee49164d9a77de4ea9e0d53b416daca7a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165124 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-03-18cool#8443 let Insert Chart dialog to undo out of order on CancelMike Kaganski
Change-Id: I66d749362c9fb5f2c228f0f5d2c927cc0cf3f89f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164179 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164834 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-03-07tdf#159862: set SearchWildcard to false changes SearchRegularExpression valueJulien Nabet
Like this since 2016 with 3a0abd3019ec3ca29b8f1378cdb32ebf741e6306 add SvxSearchItem::GetWildcard() SetWildcard() Change-Id: Id988a6e58488af6b1f274a318e9d1f52c7a8b169 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163876 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins (cherry picked from commit d05e863c69b5611964a4a2eb242ee9566cfb659e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163836 Reviewed-by: Eike Rathke <erack@redhat.com>
2024-03-04scope of MutexGuard can be reducedCaolán McNamara
These are just locals, except for IniLnge which is set once in the ctor and is then immutable Change-Id: I0d8ac0c3ca729003a3575dea39b2746dfc53b4bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164173 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit bc08b1fbbd00c6e4b086f6d95249e684ace6ae25) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164189 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-03-01SvNumberFormatter::ImpConstruct is only used once by the single ctorCaolán McNamara
so fold it into the ctor Change-Id: If063143ef47a8ab293edf3896fb51079d0e0284f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164144 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit 657631791421eae2c88a89da27bd2c0dc1822175) there is only the one ctor, so drop misleading "preferred" comment that suggests there are alternatives to choose from Change-Id: Ica3367fae93f57f339bdc39b1cd91d47a2c9618e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164146 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit 023e59d0283614a568362b794bb94a9254401d7e) if we rearrange, we don't need to create maLanguageTag twice Change-Id: I2c8ad9999adc406dc850c59b48e49681099dc054 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164147 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit 9fcee419dd368823d842b9c9a032b2213ee24d34) use member init list Change-Id: I09dea90e3e3f3fd0a4047b989329a027f788f695 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164148 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit 8f7cb2b7474d877af61ab00f6635aec5cefa3d78) IniLnge is set during ctor and never changes subsequently Change-Id: Ie052e32976d9810555c8f1892dab47a7472cdc71 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164149 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit 1245614991654b9d3ddb15f644a689585fd4c9de) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164185 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-07check that rtl_random_getBytes() was successfulMichael Stahl
... everywhere it is used to generate material for encryption. Change-Id: Id3390376bb2f3a5fa1bbfd735850fce886ef7db2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162873 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit b85c2459ced6a41915dbaf567613fb5e244a0ada) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162890 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-29tdf#159381 TimeStamp(RFC3161) create problem by asn1 format error.Noel Grandin
DER rules say that BOOLEAN values are either FALSE (0x00) or TRUE (0xff) Change-Id: I59f57557fbc4d6447e0d8e994b04adda1ee8c1a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162597 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> (cherry picked from commit d2d8f8bf82558d9aa548fb9f13bed410e0baf79b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162614 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-01-15Resolves: tdf#159148 Accept int32 hours:minutes:seconds inputEike Rathke
... and detect overflow to result in text instead of 00:00 input loss. Change-Id: Ib2b9f16ab6c3c2963c5a2058c27366219f090096 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161977 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins (cherry picked from commit e69192b51fc00cbc38006230364af07983a9a827) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161993 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-12-26cid#1559882 Uninitialized scalar fieldCaolán McNamara
and cid#1559872 Uninitialized scalar field Change-Id: Iaea583d63cd1f0a1b68c60adb57c8c1db9a26a9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161292 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit f8163aba61c6c2037deb32c61e52a8c4bd38d07f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161314 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-12-22Remove DeleteItemOnIdlexArmin Le Grand (allotropia)
There are some CrashReports in 7.6 which have DeleteItemOnIdle on the stack, but there is nothing reproducable. So I took a look... I first thought it's a MCGR regression, due to classes on the stack. But the Item involved is just random, can happen with any Item. Then I thought it may have to do with ITEM refactorings, but it happens with DeleteItemOnIdle involved, so also not the case. I already saw DeleteItemOnIdle when doing these and qualified as 'hack' in the way. already It is only on Windows and DeleteItemOnIdle is involved. This again (took a deeper look now) is an old hack to keep an SfxPoolItem 'alive' for some 'time'. For that, it triggers an async reschedule which then deletes the Item when being called. If the Item will be used after that is pure coincidence - seems to work in most cases. It seems as if for Windows the timing slightly changed for some scenarios, so a reschedule is too early. This can happen with this hack anytime. DeleteItemOnIdle is used in scenarios where SfxPoolItem* is e.g. returned, but is *not* anchored, so e.g. not member of an SfxItemSet. Or in short: Lifetime is not safe. DeleteItemOnIdle exists since 1st import, but was changed to AsyncEvent ca. 4 months ago (see 57145acf9ec47c23e307b7a5c0029d21d937cc35), so that may have caused it. It is possible that these errors happen on Windows since then. Before something more complicated was used to delete it late, but surely also not really safe. Due to ITEM refactor I have the knowledge/tooling to solve this. It will not be a 1-5 lines fix, but it is a hack and in the way for further ITEM refactor anyways. What we have nowadays is a SfxPoolItemHolder -> it's like an SfxItemSet for a single Item. It safely holds/ controls the lifetime of an SfxPoolItem. It is already used in quite some places. It helps to solve many hacks, also the ones putting Items directly to the Pool - due to there never was an alternative for that. In principle the ItemPool/ItemSet/Item paradigm was never complete without SfxPoolItemHolder. Thus I started to fix that (and remove that hack for good, sooo many changes over the years, sigh), but as said is not straightforward. Will have to change retvals of involved stuff to SfxPoolItemHolder - it's just two pointers and designed to be copied (one is a Pool, needed to cleanup when destructing). CopyConstruct/destroy just counts the RefCnt up/down, so cheap. 1st version compiling, let's check on gerrit... Corrected one error in QueryState for securitypage, also added some security features/asserts. Change-Id: Ida49fd35ca88ead84b11d93e18b978cb9e395090 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161083 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> (cherry picked from commit 789a737ac92c4f2b0eb9820b99c43cc8253c8b29) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161158 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-12-21tdf#158375: disable DDE when DisableActiveContent is setSarper Akdemir
Change-Id: I167f6ea5d740b5a53cd02a9b865e65ff980a8877 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160922 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins (cherry picked from commit 21f8e08c60cde2599f45b9e02c2b7d0cead2f625) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161029 Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
2023-12-01move the SfxItemPoolCache to sc/Noel Grandin
and rename it to ScItemPoolCache, since its only use is to handle ScPatternAttr objects Change-Id: I68a2dd5f47fcf902f9df552e1a1767d5061d85d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160162 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-25tdf#158317 fix cleanup of SfxPoolItems in editengArmin Le Grand (allotropia)
It is not possible to use implCreateItemEntry/implCleanupItemEntry, that is tooling limited *by purpose* to svl/Item/ItemSet stuff. But what I can do is to do that SfxPoolItemHolder I already talked/thought about. It is a helper that can safely hold a SfxPoolItem in cases where an SfxItemSet is too expensive. Think about it as a SfxItemSet for a single item. That solves the problem why DirectPutItemInPool/DirectRemoveItemFromPool is used in general (each usage is a 'compromize'). Did that now, works well. Editengine is now free of DirectPutItemInPool/DirectRemoveItemFromPool. Replaced ::CursorMoved with checkAndDeleteEmptyAttribs since all these got static with no longer need to DirectRemoveItemFromPool. Corrected create/delete counters. Change-Id: Ia6e53f48ac2e479b461546515e68697039b5b628 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159931 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-11-23c++20: use std::erase(_if) instead of std::remove(_if)+erase (svl 2)Julien Nabet
Change-Id: I55c85a02e9dfc7d7cd2aaaec726fc5877a847264 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159849 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-23c++20: use std::erase(_if) instead of std::remove(_if)+erase (svl)Julien Nabet
Change-Id: I572a7c81130f15929536c3c334875e8401be9e60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159700 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-22Work with what we have in ArrayImpl: pointersArmin Le Grand (allotropia)
That allows to not create a local copy on the heap before being able to check if a change is really necessary Also added mfOrientation to Cell::operator==, it was missing. Maybe with C++20 we should more use the default generated op== (or op<=>) that may turn out to be more safe. For class Cell at least all members (and sub-members of Style) are simple and simple comparable. Change-Id: Idea2ef2abe68c4bb14aa776a8393ba5da92abd5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159798 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-21Cleanup some ScPatternAttr specific stuffArmin Le Grand (allotropia)
Removed some special stuff in the ItemSet/Item tooling regarding ScPatternAttr. There are still quite a view (grep for isExceptionalSCItem), but all these are identified and isolated. Only for that Item (of over 500) are these exceptions, so that raelly does not fit into the Item schemata in any way. Not even the pool default of ScPatternAttr is without trouble. It is the only and last Item that needs to be 'pooled' in the sense to avoid copies on any price. That is OK, but should not be done in the ItemSet schemata. In short: It should not be an Item at all. It should be changed and renamed to something describing it's role (CellAttributes..?) and get helped/assisted by something called CellAttributeHelper at SC's model or Pool. It should not even be derived from SetItem, it could just contain an shared_ptr of SfxItemSet (allows more and better optimizations - think about Clone() and op==). In parallel, all these hacks in the ItemSet/Item stuff could be removed, making that faster and easier. Also quite some usages of DirectPutItemInPool could be cleaned-up, this only exists since there *is* no defined place to hold that data (coud be CellAttributeHelper in the future). Putting Items directly to the pool (and in most cases never remove them again) is just nonsense and another hint that all this does not fit to the Item/ItemSet schema at all. This is now - after hard isolation of problems and have all working - doable. It may be one of the next things to do, but there are other candidates, too. Doing this would mostly only help SC... Found another hack that uses DirectPutItemInPool and *never* removes any Item again, see comments framelinkarray.cxx And another one: PoolItemTest::testPool() explicitely tests DirectPutItemInPool stuff - which makes no sense long-term, but for now keep it and make it work by marking the slots used as _bNeedsPoolRegistration == true Have now overhauled the framelinkarray stuff to work without DirectPutItemInPool and Cell not being a SfxPoolItem. That will be much less complex and use much less calls/checks. Since this is the data structure created for every calc repaint that should get faster, too. Also for now and memory loss security I added code to DirectPutItemInPool to behave the same as with the unchanged implCreateItemEntry: register Items so that the garbage collection still is used. This will/can be removed when all usages of DirectPutItemInPool is cleaned up. Directly registering in DirectPutItemInPoolImpl is more tricky than thought, but a good thing to do. Looking at that I saw that tryRegisterSfxPoolItem is not used anymore, so rearranged some stuff. Change-Id: If07762b0a25e2739027f81872441772dc82a25d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159685 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-11-19Extended loplugin:ostr: svlStephan Bergmann
Change-Id: Ia74b15213a05da36f48932811d70d231ec7ee164 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159673 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19Fix performance regression with ScPatternAttr/SCArmin Le Grand (allotropia)
Due to the paradigm item change the test make CppunitTest_sc_tablesheetobj with CPPUNIT_TEST_NAME sc_apitest::ScTableSheetObj::testSheetCellRangeProperties got much slower. Unfortunately it did not break, so got unnoted. I took a look now. First I intended to add some hashing in an std::unordered_set using that hash values at ScPatternAttr, but that is not even possible due to other data in that item that needs to be compared. I had the impression that it was 'somehow' hashed before, but after debugging the version before that change I noted that also the list of existing items was linearly compared to the new entry, using the operator==. Thus the problem was not due to not hashing, but due to the ScPatternAttr::operator==. That uses the hash (not changed), but no longer finds equal entries. This is because the hash code is made up from the SfxPoolItemPtrs in the SfxItemSet, so when all are equal we can be sure the SfxItemSet content is equal. To use this the other way around is *not* correct: Even with not all ptrs equal the SfxItemSets can still be equal, simply by one SfxItemSet using another, but identical incarnation of an item. Thuis means that ScPatternAttr::operator== does not detect all cases of equality. This worked in most cases before since most items were 'pooled' and thus much effort was used to ensure their uniqueness, but even before the paradigm item change an item type could be flagged as non-poolable. In that case, this already could fail but with no too bad consequences (just one more copy of an ScPatternAttr would stay). So I fixed that mainly in adapting and optimizing ScPatternAttr::operator==. The results are (same machine, same compiler, dbg version, metioned test): Version before item paradigm change: user 0m50,778s Version after item paradigm change: user 20m13,944s Version with memcmp: user 0m48,845s Version with hash: user 0m48,710s Since that hash does nothing else than to buffer the comparison of those item pointers I just tried to use memcmp instead, as is already used in other places (same file, ScPatternAttr::FastEqualPatternSets, also SfxItemSet::operator==). As can be seen above it makes practically no difference (memcomp even slightly faster). Since that hash is only used in ScPatternAttr::operator== and is same speed (memcomp linearly compares 56 SfxPoolItem ptrs) I decided to remove it. It needs quite some spaces to be reset and re-calculated which are not needed anymore. The calculation is based on dividing the number of items by 4, so we are good with 56, but if someone has/ will adapt the items used by ScPatternAttr it is easy to forget to adapt this, and not easy to change the alghorithm when it's not a multiple of 4. I also optimized/overhauled SfxItemSet::operator== (or better: the SfxItemSet::Equals used by it). It is now better readable, too. I also adapted ScAttrArray::AddCondFormat to not always incarnate/ delete ScPatternAttr instances, only when needed. This also helps a bit and could be done in more places. All in all it is really necessary to cleanup SC's usage of ScPatternAttr - there are quite some possibilities to make that cleaner and faster. In principle it's a huge 'compromize' to use item functionailty to have a possibly 'cheap' maximum shared SfxItemSet at a Cell. Decided to make SfxItemSet::operator== even faster for the case of unequal ranges by iterating over ranges of local SfxItemSet and incremented offset. Still accesses to 2nd SfxItemSet will be the expensive ones using the iterated WhichID. Added two more things to SfxItemSet::operator==: We can return early when both have no items set. For the unequal-ranges compare I added an early-exit when Count() items were compared. Looked at the errors that indeed do trigger the assert in ScPatternAttr::operator== and hint to incarnations of ScPatternAttr that do not use the needed range ATTR_PATTERN_START, ATTR_PATTERN_END. Hunted down to come from ScViewFunc::ApplyAttributes and there from some Dialogs, so seems some SC dialogs do not work with the correct range schema for that item. I tried code in ScViewFunc::ApplyAttributes to fix it, that works. I also tried to hunt that down to the Dialogs that use the wrong schema (TotalCount @SfxItemSet is 61 BTW). While it would be possible to do so, it's no guarentee to have this fixed. Thus I looked at ScPatternAttr::ScPatternAttr and added correciton code when one with the wrong range schema gets created, this is luckily not often needed and transfers the existing items with low costs. Maybe we should add a warning there if used, so at least new implementations of stuff or old ones (the Dialogs) can be corrected? Change-Id: I31da73ae30786bd6c5a08a5e3b7df8fe279af261 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159592 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-11-15tdf#157518: add password strength meter to setmasterpassworddlgSarper Akdemir
Moves PasswordStrength bits that provide utility functions from cui to svl, merging them with PasswordHelper there. Adds password strength bar for the set master password dialog. (accessible via Tools -> Options -> LibreOffice -> Security -> Passwords for Web Connections) Change-Id: I8dc1090a041f8388c2e139beb1d0d9a0beb8acb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159370 Tested-by: Jenkins Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
2023-11-14cid#1550044 make it more clear that null is returned hereCaolán McNamara
Change-Id: Ie61d6e5f77d3473e4e867bda7be9805ca1e355ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159410 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-11-11Move user agent initialization to InitCurl_easyMike Kaganski
Places that didn't initialize it previously, would benefit automatically Change-Id: I2f1ff25fc58d9378462072bc92d7b37be2370fc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159299 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-11-09Fix typoAndrea Gelmini
Change-Id: I7051d0df2f21bbd5ad22404bd7b72c15aba5b861 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159188 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-09Fix typoAndrea Gelmini
Change-Id: I9423e9a6e796b8b0754d2f1c3d17ca99d325726c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159189 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-08Avoid initialization-order-fiasco in DBG_UTIL codeStephan Bergmann
...as reported by <https://ci.libreoffice.org/job/lo_ubsan/2973/> during e.g. Gallery_backgrounds, when initializing the global variable > const Cell OBJ_CELL_NONE; at svx/source/dialog/framelinkarray.cxx:281, > ==519895==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x7fb3dc3e5570 at pc 0x7fb3daee1c56 bp 0x7ffe54584480 sp 0x7ffe54584478 > READ of size 8 at 0x7fb3dc3e5570 thread T0 > #0 0x7fb3daee1c55 in std::_Hashtable<SfxPoolItem const*, SfxPoolItem const*, std::allocator<SfxPoolItem const*>, std::__detail::_Identity, std::equal_to<SfxPoolItem const*>, std::hash<SfxPoolItem const*>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, true, true> >::bucket_count() const /opt/rh/gcc-toolset-12/root/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/hashtable.h:673:16 > #1 0x7fb3daee1648 in std::__cxx1998::unordered_set<SfxPoolItem const*, std::hash<SfxPoolItem const*>, std::equal_to<SfxPoolItem const*>, std::allocator<SfxPoolItem const*> >::bucket_count() const /opt/rh/gcc-toolset-12/root/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/unordered_set.h:755:21 > #2 0x7fb3daeb1088 in std::__debug::unordered_set<SfxPoolItem const*, std::hash<SfxPoolItem const*>, std::equal_to<SfxPoolItem const*>, std::allocator<SfxPoolItem const*> >::insert(SfxPoolItem const*&&) /opt/rh/gcc-toolset-12/root/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/unordered_set:369:35 > #3 0x7fb3db01987c in SfxPoolItem::SfxPoolItem(unsigned short) /svl/source/items/poolitem.cxx:506:28 > #4 0x7fb3cb2fddb4 in svx::frame::(anonymous namespace)::Cell::Cell() /svx/source/dialog/framelinkarray.cxx:204:5 > #5 0x7fb3cafa3b6f in __cxx_global_var_init.1 /svx/source/dialog/framelinkarray.cxx:281:12 > #6 0x7fb3cafa3ba9 in _GLOBAL__sub_I_framelinkarray.cxx /svx/source/dialog/framelinkarray.cxx > #7 0x7fb3e6821f19 in call_init.part.0 /usr/src/debug/glibc-2.28-225.el8_8.6.x86_64/elf/dl-init.c:72:3 > #8 0x7fb3e6822019 in call_init /usr/src/debug/glibc-2.28-225.el8_8.6.x86_64/elf/dl-init.c:118:11 > #9 0x7fb3e6822019 in _dl_init /usr/src/debug/glibc-2.28-225.el8_8.6.x86_64/elf/dl-init.c:119:5 > #10 0x7fb3e6836cb9 (/lib64/ld-linux-x86-64.so.2+0x1dcb9) > > 0x7fb3dc3e5570 is located 48 bytes inside of global variable 'incarnatedSfxPoolItems' defined in '/home/tdf/lode/jenkins/workspace/lo_ubsan/svl/source/items/poolitem.cxx:473:47' (0x7fb3dc3e5540) of size 96 > registered at: > #0 0x43c078 in __asan_register_globals.part.0 /home/tdf/lode/packages/llvm-llvmorg-12.0.1.src/compiler-rt/lib/asan/asan_globals.cpp:360:3 > #1 0x7fb3db01e7cb in asan.module_ctor (/instdir/program/libsvllo.so+0xb3c7cb) Change-Id: I490fb232e0944f18c49b734c621e1bf0c318baff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159120 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-07ITEM: Get away from classic 'poolable' Item flagArmin Le Grand (allotropia)
To understand this, some look back in history will be needed to see why it is as it is today. In some (reworked) comments 'poolable' is described as flag to hold Items in the ItemPool, also always having only one incarnation of each possible Item. This is not the original intention, but a side-effect. The reason is what the binary format in the office did: To save a document, the Objects & the Pool were saved, *not* individual Items *together* with the objects. The Pool was completely (binary) saved (and loaded) in one run. Temporary IDs were used to represent at the objects in file which Items were referenced. This *required* to have only one incarnation per item to have a minimal binary file size, thus this high effort was put into this. At doc load, the pool was loaded, all Items were set to RefCount 5000, the references from the objects were restored and then for each Item the RefCount was lowered by 5000 again and - if being zero - deleted. Items for UI were marked 'non-poolable' to *not* safe them with the document, so poolable was a flag to decide if that Info/Item was to be saved with the document - or more direct: if it is Model Data. Items are small, so if we prefer runtime it is okay to no longer being strict with this, anyways does not happen often and has only marginal memory effects - compared to runtime effects/savings. Other problems which this caused: One example is that objects in the UNDO stack were still in the pool, so e.g. deleted pictures were saved with the document despite no longer being used (!). That is the reason we have an UndoItemPool and a method MigrateItemPool to move stuff to that Pool when objects go to the UNDO stack - all of this is also no longer needed. Cleaning this up means to ideally have all items in the SfxItemSet, no longer at the Pool. The Pool should be reduced to a 'Default-Item- Holder' and a 'Slot-to-whichId-mapper'. This needs thorough cleanups/removals, but will be worth it because that massive simplification(s) will increase safety an runtime and make migrating to the goal of completely type-based ItemSet stuff easier for the future. Hopefully only view code in the office working with items will have to be changed for this. In this 1st step I already found that some 'compromizes' will be needed: - There are still Items that have to be at the pool to make the Surrogate-stuff working. This gives back all Items in a Pool of a type and is used in ca. 80 cases. Each one looks at these Items *without* context (e.g. a SfxItemSet at an Object would be a context), so if e.g. a dialog is open that temporarily uses Items of that type you would also get these - without knowing about it... To make that work there is still a mechanism to have Items at the Pool, but now just *registering* (and un-reg) them without any sort/search/ remove needs. Also only for Items that need that, so I evaluated the GetItemSurrogates calls and added some asserts when GetItemSurrogates tries to access an unregistered item type which needs to be added. - Another caveat is that there are about 250 places that directly put Items to the Pool (not all remove these, that is done at pool deletion, so some kind of silent 'garbage-collection' is in place). To have an overview I renamed the accessing methods to separate them from the same functionality at the SfxItemSet, which had the same names. An implementation does still add these directly to the pool, there is no way to cleanup those usages for now. In principle all these should be changed to hold the data at an SfxItemSet. I am still hunting problems. But you can build the office, all apps work (including chart) and you can do speed comparisons already. There are test throwing errors, so I hunt these now. It is hard to give an estimation about how much more changes/corrections will be needed. Completed adaptions to new registered Items at Pool, that reduces the failing tests. Still many that I need to hunt. Added stuff to work around that 'compromize' in ScDocumentPool: It overloads ::PutImpl of the pool to implement special handling for a single Item in SC, the ScPatternAttr. In former code that method was used from SfxItemSet and ::PutImpl at the pool directly, so it was only used in one place. I am not sure if it was used from the SfxItemSet functionality, but better offer it for now. To not waste too much runtime the callbacks depend on the boolean 'NewItemCallback' at the SfxPoolItem, it gets set for that single Item in SC and only then the callbacks trigger. I hope to get rid of those again, e.g. newItem_UseDirect is only needed since we have no 'real' StaticPoolDefaults currently - another thing that needs to be cleaned up in a next step. Since usages of impl(Create|Cleanup)ItemEntry and Direct(Put|Remove)ItemInPoolImpl got more and more similar I decided to unify that: move impl(Create|Cleanup)ItemEntry to tooling, make it globally available in svl and use it also directly for Direct(Put|Remove)ItemInPoolImpl. This slightly increases the failing tests again, but only since in Direct(Put|Remove)ItemInPoolImpl that fallback (e.g. tryToGetEqualItem) was used before, thus this is the same class of errors (SfxPoolItem ptr-compare) as the others which I will need to find anyways. Also fixed some missing stuff. Have now idenified and redirected all SfxPoolItem ptr-compares to be able to debug these - one cause for the remaining errors is probably that before with bPoolable those often were sufficient, but are no longer. Used the [loplugin:itemcompare] and a local clang build to do so, see https://gerrit.libreoffice.org/c/core/+/157172 Stabilized Direct(Put|Remove)ItemInPoolImpl forwards, added parameter to implCreateItemEntry to signal that it gets called from DirectPool stuff - currently needed. Hopefully when getting rid of that DirectPool stuff we can remove that again Added two more debug functionalities: - Added a SerialNumber to allow targeted debugging for deterministic cases - Added registering & listing of still-allocated SfxPoolItems at office shutdown Found PtrComp error in thints.cxx - POC, thanks to areSfxPoolItemPtrsEqual. Will hopefully help more with other tests Found some wrong asserts/warnings where I was too careful and not finding something/succeeding is OK, fixes some UnitTests for SC For SC I now just tried to replace all areSfxPoolItemPtrsEqual with the full-ptr-content compare SfxPoolItem::areSame. I also needed to experiment/adapt the newItem_Callback solution but got it working. Did that replacement now for SW too, found some places where the direct ptr compare is OK. Continued for the rest of occurrences, now all 160 places evaluated. Also done some cleanups. Massive cleanups of stuff no longer needed with this paradigm change. Also decided to keep tryToGetEqualItem/ITEM_CLASSIC_MODE for now. It is used for *one* Item (ScPatternAttr/ATTR_PATTERN) in SC that already needs many exceptions. Also useful for testing if errors come up on this change to test if it is related to this. Added forwarding of target Pool for ::Clone in SvxSetItem and SvxSetItem, simplified SfxStateCache::SetState_Impl and returned to simple ptr compares in SfxPoolItem::areSame to not do the test in areSfxPoolItemPtrsEqual. Debugged through UITest_calc_tests9 and found that in tdf133629 where BoxStyle is applied to fully selected empty calc the Item- reuse fallback has to be used not only for ATTR_PATTERN, see comment @implCreateItemEntry. Maybe more... Problem with test_tdf156611_insert_hyperlink_like_excel. Found that in ScEditShell::GetFirstURLFieldFromCell the correct SvxURLField is found and returned as ptr, but it's usage crashes. That is due to the SfxItemSet aEditSet used there gets destroyed at function return what again deletes the SvxFieldItem that is holding the SvxURLField that gets returned. This shows a more general problem: There is no 'SfxPoolItemHolder' that safely holds a single SfxPoolItem - like a SfxItemSet for a single Item (if Items would be shared_ptrs, that would be a safe return value). That will be needed in the future, but for now use another solution: Since I see no reason why EE_FEATURE_FIELD should not be shareable I wil change this for ow in the SfxItemInfo for EditCharAttribField. That way the Item returned will be shared (RefCnt > 1) and thus not be deleted. I changed the return value for GetURLField() and GetFirstURLFieldFromCell() in ScEditShell: At least for GetFirstURLFieldFromCell the return type/value was not safe: The SvxFieldItem accessed there and held in the local temporary SfxItemSet may be deleted with it, so return value can be corrupted/deleted. To avoid that, return a Clone of SvxFieldData as a unique_ptr. With all that UnitTest debugging and hunting and to get the paradigm change working to no longer rely on shared/pooled items I lost a little bit focus on speed, so I made an optimization round for the two central methods implCreateItemEntry/implCleanupItemEntry to get back to the speed improvements that I detected when starting this change. It was mainly lost due to that 'strange' chained pool stuff we have, so I added to detect the target pool (the one at which the WhichID is registered) directly and only once. Next thing to cleanup will/should be the pool and it's concept, all this is not needed and really costs runtime. Since implCreateItemEntry/implCleanupItemEntry are executed millions of times, each cycle counts here. Had an error in the last changes: pool::*_Impl methods use index instead of WhichID - most of them. Another bad trap, I really need to cleanup pool stuff next. Change-Id: I6295f332325b33268ec396ed46f8d0a1026e2d69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157559 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-11-07curl: mitigate migration to OpenSSL on LinuxMichael Stahl
The problem is that curl 8.3.0 removed the NSS backend, so we now have no other choice than to use the bundled OpenSSL on Linux. Currently any curl https connection fails with: CurlSession.cxx:963: curl_easy_perform failed: (60) SSL certificate problem: unable to get local issuer certificate Apparently this requires manually telling curl which CA certificates to trust; there is a configure flag --with-ca-bundle but that is useless as it tries to load the file relative to whatever is the current working directory, and also did i mention that there are at least 3 different locations where a Linux system may store its system trusted CA certificates because ALL ABOUT CHOICE. So add a new header with an init function to try out various file locations listed in this nice blog article and call it from way too many places that independently use curl. https://www.happyassassin.net/posts/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/ TODO: perhaps bundle a cacert.pem as a fallback in case the system chose to innovate by putting its certificates in yet another unexpected place (regression from commit c2930ebff82c4f7ffe8377ab82627131f8544226) Change-Id: Ibf1cc0069bc2ae011ecead9a4c2b455e94b01241 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158915 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-11-06tdf#146619 Recheck include/t* with IWYUGabor Kelemen
Change-Id: I005257e458351285b1b35ffe49c8b42834a6db68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156990 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-11-01tdf#156449 Preserve '0' or '?' in exponentLaurent Balland
Exponent in scientific number may use '?' as blank like in format "0.00E+?0" This change: - adds interpreatation of '0' and '?' in exponent - adds "blank-exponent-digits" attribute to scientific number for import and export to ODF - prevents using exponent with only '?'. There must be at least one '0' in exponent - adds QA test of such format and test import/export/import to ODF and OOXML - corrects one basic test Change-Id: If52edc632a161f842270bb2fd77af535e2b978d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154986 Tested-by: Jenkins Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
2023-10-23Extended loplugin:ostr: Rewrite some O[U]StringLiteral -> O[U]StringStephan Bergmann
...in include files. This is a mix of automatic rewriting in include files and manual fixups (mostly addressing loplugin:redundantfcast) in source files that include those. Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-20Extended loplugin:ostr: Automatic rewrite O[U]StringLiteral: svlStephan Bergmann
Change-Id: I31d46c2b75888474136ecd630fd3f817db189fb4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158223 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-15Repurpose loplugin:stringstatic for O[U]String vars that can be constexprStephan Bergmann
...now that warning about O[U]String vars that could be O[U]StringLiteral is no longer useful Change-Id: I389e72038171f28482049b41f6224257dd11f452 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157992 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-11Drop o3tl::span, can use C++20 std::span directly nowStephan Bergmann
Change-Id: Ic21ff7bf48f07f7277979d52e99d2c5c268de83f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157825 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-11tdf#157686 UI freezes after setting new master passwordNoel Grandin
regression from commit 49dd32a88d90097a1c50dc64dc42dc35645780b8 author Noel Grandin <noel.grandin@collabora.co.uk> osl::Mutex->std::mutex in PasswordContainer Change-Id: Ie6270f6ed47ee892181f7b9e51ed8ef75533f4e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157809 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-10-07loplugin:ostr: automatic rewriteStephan Bergmann
Change-Id: I2d09b2b83e1b50493ec88d0b2c323a83c0c86395 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157647 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2023-09-29cid#1545230 Unchecked return valueCaolán McNamara
Change-Id: If25dcbb9784c041b61fe9aaea213035a4769962b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157397 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-09-29ITEM: Correct handling of Items in swArmin Le Grand (allotropia)
...that use internally an sw::BroadcastingModify*. This caused an error/crash with the testfile ooo58307-1.sxw, thanks to Caolan to find it. For BG info please see comments in the changed sw/source/core/attr/swatrset.cxx Change-Id: Ia91fff19ffb39873c7e2bd5ff8806b95fc5ac7ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157383 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-09-11ITEM: Diverse further changes/cleanups/preparationArmin Le Grand (allotropia)
Added a counter for SfxItemSet usages, similar to the already added one for SfxPoolItems to allow quick info about evtl. problems/drawbacks of changes. Replaced enum SfxItemKind in favour of settable boolean flags directly at SfxPoolItem. These are organized as bitfield, do not need more space as the enum and allow to be set separately and multiple ones at the same time. Flags for PoolDefault/StaticDefault/DeleteOnIdle use this now and are quickly accessible booleans. It is not a problem that theoretically the flags for PoolDefault/StaticDefault could now both be set - this is internal to SfxItem stuff and not accessible from normal code, so can be managed. Added for debug build a bitfield boolean m_bDeleted that will be set in the SfxPoolItem destructor. Of course it's usability will depend on the freed space not yet being re-used, but will hopefully help in the debugger to detect reasons for failure (would have helped at least me before). Added for replacement of virtual method IsVoidItem() another bitfield bool m_bIsVoidItem that is set in the constructors of SfxVoidItem. Also had to add some constructors to do that which were defaulted before. This is mainly because the base class SfxPoolItem does *not* have a copy-constructor that copies the members (flags/RefCnt/WhichID) and we should keep that 'indirect reset' when Cloning. isVoidItem() is now a simple boolean member access - the bitfield does the needed masking. This spares one entry in the virtual function table of SfxPoolItem which is derived more than 500 times. Used the results of the experiment at https://gerrit.libreoffice.org/c/core/+/156774 to change some accesses to IsVoidItem() to use SfxItemState instead. This is for preparation of splitting up the two usages of SfxVoidItems, see commit text in the experiment. If this shows problems in the future those six places documented there may have to be changed back to use the new isVoidItem(), but should also check the ptr this time to be non-zero. Removed SFX_ITEMS_SPECIAL that is no more used anywhere. Change-Id: Ib687ca2362d72a4651c75aee0c67029088f68947 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156805 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-09-09Fix typoAndrea Gelmini
Change-Id: I89d3a3074929ba867975ae57d350b7e4211ed67c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156757 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-09-09Fix typoAndrea Gelmini
Change-Id: I88d79ca31981a49736af571067831c703cf65d3a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156755 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
generated by cgit (git 2.34.1) at 2025-01-07 18:46:32 +0000