summaryrefslogtreecommitdiff
path: root/svl
AgeCommit message (Collapse)Author
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann
This is a prerequisite for making conversion from OUStringLiteral to OUString more efficient at least for C++20 (by replacing its internals with a constexpr- generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount, conditionally for C++20 for now). For a configure-wise bare-bones build on Linux, size reported by `du -bs instdir` grew by 118792 bytes from 1155636636 to 1155755428. In most places just a u"..." string literal prefix had to be added. In some places char const a[] = "..."; variables have been changed to char16_t, and a few places required even further changes to code (which prompted the addition of include/o3tl/string_view.hxx helper function o3tl::equalsIgnoreAsciiCase and the additional OUString::createFromAscii overload). For all uses of macros expanding to string literals, the relevant uses have been rewritten as u"" MACRO instead of changing the macro definitions. It should be possible to change at least some of those macro definitions (and drop the u"" from their call sites) in follow-up commits. Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-27remove some unused includes and update pchesCaolán McNamara
Change-Id: I786548bef39fa711aabcff32b592b3fdc4a6f9fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101486 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-27expand out StringSet typedefNoel Grandin
Change-Id: If7791d51d055ad918b54a52bee3f13a79c5468f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101435 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-19update pchesCaolán McNamara
Change-Id: I6a300169d33bdc36e4c7e720a7afc336a86eea68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100962 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-14loplugin:simplifybool moreNoel Grandin
look for expressions like !(a && !b) which can be expanded out Change-Id: I72515a9638762b050f9a258c08da39ebfa2ef8e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100579 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-13Fix variable name bAcceptEnmptyAndrea Gelmini
Change-Id: Ie3fe919a7b8296440cd2a670f218147da98f7822 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100653 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net> Tested-by: Jenkins
2020-08-13use OUStringLiteral in SfxItemPropertyMapEntryNoel Grandin
Change-Id: I4f05b6a35010e661ea77f3e4b83302d2ec74d227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100405 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-13loplugin:stringstatic also look for local staticsNoel Grandin
Add some API to O*StringLiteral, to make it easier to use in some places that were using O*String Change-Id: I1fb93bd47ac2065c9220d509aad3f4320326d99e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100270 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-12expand out DELETEZNoel Grandin
Change-Id: Ia69fb105c6cc661ac94a360d47655b3faa9d6bb8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100618 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-12SvTreeListBox can move into toolkit headers nowCaolán McNamara
Change-Id: I6b3b6ef1530a192f4b6bf87aa9688687063683ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100591 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-11loplugin:flattenNoel Grandin
Change-Id: I6560756eb63856a22b43e3e65a7b7843cd2d5376 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100447 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-06Resolves: tdf#135249 Duration input 0:123 or 0:0:123 or 0:123:59 is validEike Rathke
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 Kelemen
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 McNamara
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 Vajna
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 Grandin
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 Grandin
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 McNamara
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 Behrens
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>
2020-07-09cid#1465237 silence Dereference after null checkCaolán McNamara
Change-Id: I7014da07d88861e4f08fb9e1006dccb6fc2ad245 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98406 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-06Resolves: tdf#131562 decimal separator may not be surrounded by blanksEike Rathke
1 . 1 .2 1 . 2 1. 2 . 2 . 2 are not numbers. But .2 is. Change-Id: Ie2e0775852e13eee733d0fed3399cbd3d065d9fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97895 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-07-06Resolves: tdf#134490 do not skip all trailing '-' or '/' of the start stringEike Rathke
Skip *one* of them under the condition that a month name was actually recognized. A horrible implementation of commit b00fc9462d26083b6d09f72ea44abb1e11546b63 CommitDate: Wed Sep 15 11:54:10 2010 +0200 sc-date-fix.diff: Parse 'june-2007' as June 1 2007 in en-US locales Change-Id: I0800c4f0b33aa1413bde558d710fe467e4380262 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97903 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-07-02Resolves: tdf#134455 Let TIMEVALUE() use lax time recognitionEike Rathke
... to accept minutes or seconds >59 Prepare SvNumInputOptions as enum class in case further options would be needed for anything else. Change-Id: Ie9ae62adf68f9948e23f55ac32c09a6b992a36e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97784 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-07-02Upcoming improved loplugin:staticanonymous -> redundantstatic: svlStephan Bergmann
Change-Id: Iedcd2e149690350f0ef131eda5cf61ecfade5c91 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97695 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-01Fix typosAndrea Gelmini
Change-Id: I4f1c0d90fcb7726ceadd72c9cb9f96a57cade67a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97602 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-07-01tdf#132454 some more improvementsNoel Grandin
Defer moving around the vector by tagging the last bit in the pointer. This takes the undo operation from 10s to 8s on my machine. Also re-organise the fields a little to improve packing. Also add some design notes Change-Id: I38fa9156705c00bb9f64e2fc59ea862eba522942 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97424 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-26optimize SvtBroadcaster::Normalize() even a bit more (tdf#132454)Luboš Luňák
Optimize also maDestructedListeners (often just one item). Optimize also small vectors if there's just one item unsorted. Keep the index of the first unsorted item in maListeners, so that it's cheap to find out where the unsorted part starts. This now improves tdf#132454 to 20s. Change-Id: I21a69b440c27a2e31e74fd13b9263f54af12e320 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97198 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-25optimize SvtBroadcaster::Normalize() a bit more (tdf#132454)Luboš Luňák
A common case is just one unsorted item at the end, in that case it's even more efficient to simply insert it in the right place. This further improves the tdf#132454 undo operation 36s->27s. Change-Id: I29db80fb8292e827b655000cddc462cf87cb485d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97088 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2020-06-24optimize SvtBroadcaster::Normalize() (tdf#132454)Luboš Luňák
New items are only appended, so it's wasteful to std::sort() the whole container, just sort the unsorted part (often just one item) and then merge. Change-Id: I20b73730700c279e8f844c0b7a392a8f372a22da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97019 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-24use more std::container::insert instead of std::copyNoel Grandin
which is both more compact code, and more efficient, since the insert method can do smarter resizing Change-Id: I17f226660f87cdf002edccc29b4af8fd59a25f91 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96948 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-15tdf#103414 Add/Delete decimal for 100th secondLaurent BP
Use Add/Delete decimal to change precision of time and duration Apply only to 100th second Change-Id: I2ff1b01db7ee67645511fcf7ea6bf65055e92a8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94765 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-06-12fix ASAN in SharedStringPoolNoel Grandin
regression from commit 3581f1d71ae0d431ba28c0f3b7b263ff6212ce7b optimize SharedStringPool::purge() and fix tests which results in us potentially de-referencing an already de-allocated OUString object in the first loop in purge(). So switch to a different strategy, which only needs one data structure, instead of two. Change-Id: Iaac6beda48459643afdb7b14ce7d39d68a93339c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95226 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-11Drop configurability of libnumbertext useTor Lillqvist
It was fairly pointless to be able to --disable-libnumbertext. Besides, disabling it broke the ordinal page (etc) numbering feature: "1st", "2nd", "3rd", etc showed up as "Ordinal-number 1", "Ordinal-number 2", "Ordinal-number 3" etc. Change-Id: I645169054a8fdc8dac89cd48b6c369fd61749467 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96119 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-06-05Upcoming loplugin:elidestringvar: svlStephan Bergmann
Change-Id: I124dd9be0ca8ede61323dd77b737253c5af99ceb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95570 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-03fix ubsan in SharedStringPoolNoel Grandin
with a slightly dodgy fix. regression from commit 3581f1d71ae0d431ba28c0f3b7b263ff6212ce7b optimize SharedStringPool::purge() and fix tests It's not ideal - we no longer have a way of purging uppercase keys that are longer in use. But that doesn't cost much memory, because we are sharing those strings. We could potentially identify them with extra book-keeping in either intern() or purge(), but since this class is performance-sensitive, best just to sacrifice some space in the map. Change-Id: I85a469448f5b36b1b6889da60280edd56bbcb083 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95432 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-03loplugin:simplifypointertobool improveNoel Grandin
to look for the x.get() != null pattern, which can be simplified to x I'll do the x.get() == nullptr pattern in a separate patch, to reduce the chances of a mistake Change-Id: I45e0d178e75359857cdf50d712039cb526016555 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95354 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-02optimize SharedStringPool::purge() and fix testsNoel Grandin
which were checking the wrong thing - we don't care about the input strings to intern(), we care about which SharedString objects are still alive. Change-Id: Ia35a173a02a24efb335268dcae4078a956d11098 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95177 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-05-30loplugin:simplifybool extend to expression like !(a < b || c > d)Noel Grandin
mostly to catch stuff from the flatten work, but I think this looks good in general Change-Id: I7be5b7bcf1f3d9f980c748ba20793965cef957e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92493 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-28Make loplugin:simplifypointertobool handle parenthesized expressionsStephan Bergmann
...as discussed as an open TODO in the commit message of fe6cce01c88d045a1fcf09acf049c34c22299b02 "Fix loplugin:simplifypointertobool for libstdc++ std::shared_ptr". The necessary changes across the code base have been done fully automatically with the rewriting plugin on Linux. (All those changes apparently involve uses of macro arguments wrapped in parentheses in the macro body, but always in conditionally-converted-to-bool contexts. In other contexts, such automatic rewriting would add the "bool" to the macro body, which would be wrong in general, but we apparently get away with that sloppy coding for now.) The parenExprs_ stack that fe6cce01c88d045a1fcf09acf049c34c22299b02 had introduced to treat such (then-undetected, it had turned out) parenthesized cases now turns out to not be needed after all. Change-Id: I2021f61c2e2805be7e18b38edf8744d186cac3cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95010 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-26Fix typoAndrea Gelmini
Change-Id: I44b332e840a5e3084c0c16fe05f0918e42217c13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94821 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-05-25Remapping NatNum-DBNum in Korean for compatibility tdf#130193DaeHyun Sung
Remapping NatNum-DBNum in Korean for compatibility tdf#130193 Unlike Japanese and Chinese[Simplified, Traditional] environment on Excel, In Korean Situation, Excel exist DBNum1~4. I checked DBNum1~4 series on Excel 2016 in Korean Environment. DBNum1 1234567890 一十二億三千四百五十六万七千八百九十 DBNum2 1234567890 壹拾貳億參阡四百伍拾六萬七阡八百九拾 DBNum3 1234567890 十２億３千４百５十６万７千８百９十 DBNum4 1234567890 일십이억삼천사백오십육만칠천팔백구십 Also, I checked Korean Number to Strings on LibreOffice. [natnum1] 1234567890 一二三四五六七八九〇 [natnum2] 1234567890 壹貳參四伍六七八九零 [natnum3] 1234567890 １２３４５６７８９０ [natnum4] 1234567890 一十二億三千四百五十六万七千八百九十 [natnum5] 1234567890 壹拾貳億參阡四佰伍拾六萬七阡八佰九拾 [natnum6] 1234567890 １십２억３천４백５십６만７천８백９십 [natnum7] 1234567890 十二億三千四百五十六万七千八百九十 [natnum8] 1234567890 拾貳億參阡四佰伍拾六萬七阡八佰九拾 [natnum9] 1234567890 일이삼사오육칠팔구영 [natnum10] 1234567890 일십이억삼천사백오십육만칠천팔백구십 [natnum11] 1234567890 십이억삼천사백오십육만칠천팔백구십 I also checked Korean billion units test. [natnum1] 123456789012 一二三四五六七八九〇一二 [natnum2] 123456789012 壹貳參四五六七八九零壹貳 [natnum3] 123456789012 １２３４５６７８９０１２ [natnum4] 123456789012 一千二百三十四億五千六百七十八万九千一十二 [natnum5] 123456789012 壹仟貳佰參拾四億五仟六佰七拾八萬九仟壹拾貳 [natnum6] 123456789012 １천２백３십４억５천６백７십８만９천１십２ [natnum7] 123456789012 千二百三十四億五千六百七十八万九千十二 [natnum8] 123456789012 仟貳佰參拾四億五仟六佰七拾八萬九仟拾貳 [natnum9] 123456789012 일이삼사오육칠팔구영일이 [natnum10] 123456789012 일천이백삼십사억오천육백칠십팔만구천일십이 [natnum11] 123456789012 천이백삼십사억오천육백칠십팔만구천십이 As a result, 1. from DBNum to NatNum (import): - DBNum1 -> NatNum4 (Korean Hanja text 한자숫자) - DBNum2 -> NatNum5 (Korean Upper Hanja text 갖은자) - DBNum3 -> NatNum6 (fullwidth Arabic digits with Korean hanja unit of Numbering) - DBNum4 -> NatNum10 (Korean Hangul text) I found the Bug for NatNum6 (I'll change Korean Hangul to Hanja for compatibility) 2. From NatNum to DBNum - NatNum1 -> DBNum1 - NatNum2 -> DBNum2 - NatNum3 -> DBNum3 - NatNum4 -> DBNum1 - NatNum5 -> DBNum2 - NatNum6 -> DBNum3 - NatNum7 -> DBNum1 - NatNum8 -> DBNum2 - NatNum9 -> DBNum4 - NatNum10 -> DBNum4 - NatNum11 -> DBNum4 By the way, I change test cases for Korean. It is included in svl/qa/unit/svl.cxx It solves the issue tdf#130140 Also, It related the issue tdf#130077 Change-Id: Idb7f3defc5f19e3edc4c179b0a081d2abe8ee3a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94747 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-05-25tdf#130193: Asian Excel-Calc number format interopNaruhiko Ogasawara
remap NatNum - DBNum in Japanese/Chinese to improve Excel interoprability from DBNum to NatNum (import) in ja/zh: - DBNum1 -> NatNum4 (modern long Kanji text) - DBNum2 -> NatNum5 (traditional long Kanji text) - DBNum3 -> NatNum3 (fullwidth Arabic digits) from NatNum to DBNum (export) in ja: - NatNum1 -> DBNum1 - NatNum2 -> DBNum2 - NatNum3 -> DBNum3 - NatNum4 -> DBNum1 - NatNum5 -> DBNum2 - NatNum6 -> DBNum3 - NatNum7 -> DBNum1 - NatNum8 -> DBNum2 - NatNum9 -> (DBNum0, as Arabic) in zh, nothing change about export. It also partially solves the issue tdf#130140 (about Japanese, not Korean) To do this, more data-drivened MapDBNumToNatNum() and MapNatNumToDBNum() in svl/source/numbers/zformat.cxx By mapping "NatNum - DBNum" to a table using map and array, it makes the specification for each language more understandable The new test cases are also included in svl/qa/unit/svl.cxx Change-Id: I34a70d970ef2e46c1b3db5db1c397ab89c056191 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94376 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-05-25tdf#133342 Add user defined percent stringLaurent BP
With Add/Delete decimal place, insert percent char and string text between number and '%' Change-Id: I4a97e4361228020803810692d7977e5806baf180 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94757 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-05-24inline some use-once typedefsNoel Grandin
Change-Id: Idddba2f3fd05265b08dbc88edb6152d34a166052 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94730 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-15Handle conversion of locale modifiers not of the same originating localeEike Rathke
This popped up when attempting to replace the zh-CN keyword 'General' with '常规' for tdf#88233, which led to CppunitTest_sc_subsequent_export_test failing for ScExportTest::testNatNumInNumberFormatXLSX with - Expected: [DBNum2][$-804]General;[RED][DBNum2][$-804]General - Actual : [$-1F000804]ge\ner"al";[RED][$-1F000804]ge\ner"al" The reason was that from the English format string loaded from .xlsx [DBNum2][$-804]General;[RED][DBNum2][$-804]General the resulting zh-CN format was [DBNum2]General;[RED][DBNum2][$-804]General like before, which when reparsed in a zh-CN locale now without the 'General' keyword first led to [DBNum2]GEnERal;[RED][DBNum2][$-804]GEnERal with GE and ER calendar keywords, which then is exported correctly as [$-1F000804]ge\ner"al";[RED][$-1F000804]ge\ner"al" So when detecting the "format belongs to another locale" condition also switch the target locale of the ongoing conversion, which results in the then correct [DBNum2]常规;[RED][DBNum2][$-804]常规 exported as [DBNum2][$-804]General;[RED][DBNum2][$-804]General again. Such could had happened with any format code using a [$-...] locale modifier if keywords differ between originating and target locale, but cases seem to be not that widespread. Change-Id: Ib4d444a4085ace251d03e87498eb0f4871eadc8d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94313 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-05-10new loplugin:simplifypointertoboolNoel Grandin
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-09fix leak in svl unit testNoel Grandin
Change-Id: I8dc11da4e1de5c2e2831ac85dff0daeac0e0ce95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93744 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-05remove unused nSearchFamily and nMask membersCaolán McNamara
and so SetSearchMask which doesn't have any effect anymore Change-Id: I0b7f402ce0317971d5196fc448fe2945a6a292f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93393 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-05-05if we create a new style remove any old style with the same nameCaolán McNamara
surely the current searchmask should have no effect on the remove seeing as a new style is going to be created unilaterally Change-Id: I4a8d05be26a3a2711ae6f377f034a9155100e831 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93496 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-05-05don't need to save and restore the search mask if it doesn't get changedCaolán McNamara
Change-Id: I19ee6a916017cb49092a2b74bc2bfd9b99b8c72d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93489 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
generated by cgit (git 2.34.1) at 2025-01-18 06:45:05 +0000