summaryrefslogtreecommitdiff
path: root/svl
AgeCommit message (Collapse)Author
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>
2020-05-05we want to invalidate the current iteratorCaolán McNamara
if there isn't one we shouldn't need to create one to invalidate it Change-Id: Ia936f71c18c45d8e08f013ffa143c196109495ed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93471 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-05-05pass SfxStyleFamily explicitly to SfxStyleSheetBasePool::ChangeParentCaolán McNamara
Change-Id: I7bc570899170b7a21e4d54e58d7a8ada0f79b918 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93469 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: Ic7da569f9133d31783c238d7ca4a4cc1ae0244f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93468 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-05-05make the family and mask explicit in SfxStyleSheetBasePool::FirstCaolán McNamara
Change-Id: I36655b65ca00e5f7b8779a28d4a1778c8e35dc4e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93461 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-05-05drop SfxStyleSheetBasePool::CountCaolán McNamara
and use CreateIterator to make it explicit what is being counted Change-Id: I8d76aef601533960a23c056b83a48c4f130bbe75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93446 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-04-22tdf#42949 Simplify use of rtl::math::approxEqual in include/basegfx/Gabor Kelemen
Turns out we can save about 500Mb of preprocessor input if we use rtl_math_approxEqual from rtl/math.h instead of its C++ wrapper rtl::math::approxEqual from rtl/math.hxx and manage the fallout accordingly. Before: bin/includebloat.awk | head sum total bytes included (excluding system headers): 19017296671 After: $ bin/includebloat.awk | head sum total bytes included (excluding system headers): 18535432672 Change-Id: I1691171f3a309405a7099882ad9989d147f59118 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92508 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-04-22uiobject.hxx only needs forward declaresCaolán McNamara
and update pches accordingly Change-Id: I411712532fd85961bffe6678416fcdc1d9c7f53d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92617 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-04-18Move implementation of CELL("format";...) to SvNumberFormatter, tdf#132106 prepEike Rathke
In preparation of further detailed handling. Change-Id: I9e4d916de031b742d0af1025b945b7608fed8266 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92462 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-04-16loplugin:buriedassign in starmath..svlNoel Grandin
Change-Id: I979faf4c476a7de91a0b6e06dd8717cee25525f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92313 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-25Remove unused using declarations in oox...xmlsecurityGabor Kelemen
Found by: run-clang-tidy-10 -checks=-*,misc-unused-using-decls Change-Id: I3e95791e223ef01e140a6217e29a9efae428a784 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90876 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-23Fix typosAndrea Gelmini
Change-Id: Iba46fbe8559211403118a23cd198a2217b333a81 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90900 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2020-03-14tdf#130974 replace `rtl::math::isSignBitSet` with `std::signbit`.Yukio Siraichi
Change-Id: I91235eee8c6a9d4a59c1933527b49141f64cd91b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90478 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-03-13Revert "loplugin:constfields in svl"Noel Grandin
This reverts commit 5181253946ca1877cc42050452aa6d733d6da3f1. Change-Id: I30e30aae45c33824c0df823a9fad710faa81ea3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90453 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-12comparison operators should be constNoel Grandin
Change-Id: Ifa76e004128223460945d58d1c59c4e23db0f108 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90370 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-27tdf#130725: use strtod by David M. Gay to make sure we get the nearestMike Kaganski
... representation of given decimal. Use dtoa.c from https://www.netlib.org/fp/dtoa.c to build a custom static library that doesn't use current locale (unlike strtod from stdlib.h). This is the implementation used by e.g. python and nss (search for "dtoa.c" under UnpackedTarball). To avoid name clash with the standard strtod, rename the function to strtod_nolocale. Size of buffer on stack in ImpSvNumberInputScan::StringToDouble is 256 characters. Logging function usage in make check, of ~124 600 invocations, the longest string was 14 characters, average being 2.1 characters. So heap allocation is unlikely in scenarios with intensive function usage. After std::from_chars is available in baseline compilers, external library can be dropped, and call to strtod_nolocale replaced with the standard function. The artifact at https://dev-www.libreoffice.org/src/dtoa-20180411.tgz is created with mkdir dtoa && mkdir dtoa/src && wget https://www.netlib.org/fp/dtoa.c -O dtoa/src/dtoa.c && \ printf 'd8bab255476f39ea495c8c8ed164f9077da926e6ca7afb9ad3c56d337c4484fe dtoa/src/dtoa.c' | sha256sum -c && \ tar -c --owner=0 --group=0 --mode=go=r,u=rw --mtime='Wed, 11 Apr 2018 15:59:39 GMT' dtoa/src/dtoa.c | gzip -n > dtoa-20180411.tgz && \ printf '0082d0684f7db6f62361b76c4b7faba19e0c7ce5cb8e36c4b65fea8281e711b4 dtoa-20180411.tgz' | sha256sum -c (where the date "Wed, 11 Apr 2018 15:59:39 GMT" is from `wget -S https://www.netlib.org/fp/dtoa.c` "Last-Modified: Wed, 11 Apr 2018 15:59:39 GMT" header). Change-Id: Ia61b7678e257c4bc1ff193f3f856d611aa5c1a21 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88854 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-02-25Fix currency symbol selection in Calc on mobileTomaž Vajngerl
In LOK we use one language identifier for both - UI language and the locale used. This is a problem when we determine that we a language for UI is not available and fall-back to the default "en-US" langauge, which also changes the locale. This introduces a separate variable that stores the language tag for the locale independently to the language. Another problem is that in some cases we don't reset the staticly initialized data, when the new document is loaded, which is on the other hand used to define which currency symbol is used as SYSTEM locale. That can in some cases select the wrong currency symbol even when we changed the locale to something else. This fix introduces a reset function, which is triggered on every document load. Change-Id: I55c7f467600a832895f94346f8bf11a6ef6a1e49 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89320 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89343 Tested-by: Jenkins
2020-02-22Resolves: tdf#130563 Add predefined 4-digit year date+time formatEike Rathke
Add a predefined NF_DATETIME_SYS_DDMMYYYY_HHMM format code with formatindex="50" to all locale data files, which shifts all reserved area internally generated built-in formats up by one. Reserved area was filled already so that boundary has to be increased as well. Add some flexibility for future additions by setting the new boundary to 65, free first format index to be used by additional locale data formats is 66 now. Adapt all locales to the new boundary. The existing predefined NF_DATETIME_SYSTEM_SHORT_HHMM format code with formatindex="46" mostly was and is used with 2-digit years (stemming back from the old binary format and Excel compatibility), some locales that don't use 2-digit years at all already defined it to 4-digit years. Keep those but move the default="true" attribute (if so) to the new "50" format. Modify populating the format list such that resulting duplicates will be suppressed there as well. Also try to match the new format in ODF import if a long year was requested with date+time. Finally set the new format as default for all *_IT locales. In future changing the default date+time format to 4-digit year is just a matter of moving the default="true" attribute to the new format. Change-Id: Ib16aa9fda0e71b2d03f78e3dd013785de03cd288 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89265 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-02-17Drop needless junit and python make conditionalsJan-Marek Glogowski
JunitTest and PythonTest modules check for these themself. Change-Id: Ia453bc99571738b01cc8f161f346cb6c37b2e429 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88832 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-02-16tdf#129878: replace error string for number format errors in CalcMohamed Sameh
Change-Id: I9a7c98b656c1f9270de5b13f7022d5930a665a4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88760 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-02-07tdf#130501: Fix off-by-one error in URIHelper::resolveIdnaHostStephan Bergmann
Change-Id: Ibc231308d0fc93085933ae7d80dc8c4b2699fe02 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88204 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-04show Korean Dangi Calendar format tdf#125446DaeHyun Sung
show Korean Dangi Calendar format Ref1: MSDN - Calendar IDs 5 : CAL_KOREA https://docs.microsoft.com/en-us/windows/desktop/Intl/calendar-identifiers Ref2: stackoverflow https://stackoverflow.com/questions/54134729/what-does-the-130000-in-excel-locale-code-130000-mean Change-Id: Ia1f367bfd5c13f29054064d89be847bbf249c0d0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87689 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-02-01make update_pch also consider files in <module>/src/**/incLuboš Luňák
With --enable-pch=full there's not much difference between a "public" header in <module>/inc and a private one in <module>/src/somewhere/inc . And since the script searches recursively, this apparently helps to find even more headers for lower pch levels. Change-Id: I8483d0aa5b4fea5a59107c20a8aa5f1ef694af0a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87799 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-01-31clang-tidy modernize-concat-nested-namespaceNoel Grandin
Change-Id: Iab35a8b85b3ba1df791c774f40b037f9420a071a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86708 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-29cid#1458019 silence Out-of-bounds writeCaolán McNamara
and cid#1458017 silence Out-of-bounds write Change-Id: I5411322bca523e5dc55b8df2e7d9261981f504da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87703 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-01-29cid#1458020 Untrusted loop boundCaolán McNamara
cid#1458018 Untrusted loop bound cid#1242844 Untrusted loop bound Change-Id: I9062240290708f4b51b0ce42a30897b50d1a2677 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87702 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-01-28tdf#88205: Adapt uses of css::uno::Sequence to use initializer_list ctorOnur Yilmaz
Change-Id: Ie5a381fc5e5b73490ab8b2036ef2a1164e475e8f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87557 Tested-by: Jenkins Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
2020-01-28New loplugin:unsignedcompareStephan Bergmann
"Find explicit casts from signed to unsigned integer in comparison against unsigned integer, where the cast is presumably used to avoid warnings about signed vs. unsigned comparisons, and could thus be replaced with o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx) o3tl::make_unsigned requires its argument to be non-negative, and there is a chance that some original code like static_cast<sal_uInt32>(n) >= c used the explicit cast to actually force a (potentially negative) value of sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the cast to avoid a false "signed vs. unsigned comparison" warning in a case where n is known to be non-negative. It appears that restricting this plugin to non- equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=) is a useful heuristic to avoid such false positives. The only remainging false positive I found was 0288c8ffecff4956a52b9147d441979941e8b87f "Rephrase cast from sal_Int32 to sal_uInt32". But which of course does not mean that there were no further false positivies that I missed. So this commit may accidentally introduce some false hits of the assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan --enable-dbgutil) `make check && make screenshot`. It is by design that o3tl::make_unsigned only accepts signed integer parameter types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in include/oox/helper/helper.hxx is used with both signed and unsigned types, so needs a little oox::detail::make_unsigned helper function for now. (The ultimate fix being to get rid of the macro in the first place.) Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-28remove some unused local varsNoel Grandin
found by my new aggressive unused var plugin. these are unused return values from function calls Change-Id: I3359c583f535828f192cb833762dfedc008d82f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87439 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-25loplugin:makeshared in svl..svxNoel Grandin
Change-Id: I067ea2f3cb651fdc5c3d1a09b0c55583618b9d1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87355 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-15tdf#88205 Adapt uses of css::uno::Sequence to use initializer_list ctorMesut Çifci
Change-Id: Ice7c0ecc8ee05a5c3b0af458ceeee8191bdde322 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86752 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-08Fix typoAndrea Gelmini
Change-Id: I01c4bfadfabce128f1e28b0c871da1722b865b6f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86377 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-01-08Drop duplicating range checkMike Kaganski
This is checked several lines below, with much stricter range. Change-Id: I3bfaf71f9e40dd1af089ed1ac238bc2939d0fc3a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86392 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-12-23sal_Char->char in svtools..svlNoel Grandin
Change-Id: Ideb61209e8795865bce6e0b1d667b34f8a8db4d9 Reviewed-on: https://gerrit.libreoffice.org/85713 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-17Elide use of rtl_Instance (which is obsoleted by C++11 thread-safe statics)Stephan Bergmann
Change-Id: Ic7b78dffb2f8d1908f3263d88c5912aec2ebce8b Reviewed-on: https://gerrit.libreoffice.org/85263 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-12use covariant return type for SfxPoolItem::CloneCaolán McNamara
and can then remove some casting Change-Id: Id821c32ca2cbcdb7f57ef7a5fa1960042e630ffc Reviewed-on: https://gerrit.libreoffice.org/85022 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-12-11Fix typosAndrea Gelmini
Change-Id: I89ff5493c70d6e64ee6ab65b1b789a0db543c0aa Reviewed-on: https://gerrit.libreoffice.org/84917 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-12-07Fix more new dependencies on boost_headersStephan Bergmann
Same as 97b3e455802cfc08568ec5e8379c509efe3e47b1 "Fix some new dependencies on boost_headers" Change-Id: I0f10374650847f4c50a8cff530c15e65906865ad Reviewed-on: https://gerrit.libreoffice.org/84672 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-03Adapt CPPUNIT_ASSERT to C++20 deleted ostream << for sal_Unicode (aka char16_t)Stephan Bergmann
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r3.html> "char8_t backward compatibility remediation", as implemented now by <https://gcc.gnu.org/ git/?p=gcc.git;a=commit;h=0c5b35933e5b150df0ab487efb2f11ef5685f713> "libstdc++: P1423R3 char8_t remediation (2/4)" for -std=c++2a, deletes operator << overloads that would print an integer rather than a (presumably expected) character. But for simplicity (and to avoid issues with non-printing characters), keep printing an integer here. Change-Id: I751b99ee32d418eb488131ffa130d6f7d6d38dc7 Reviewed-on: https://gerrit.libreoffice.org/84348 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-03Adapt to C++20 deleted ostream << for sal_Unicode* (aka char16_t*)Stephan Bergmann
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r3.html> "char8_t backward compatibility remediation", as implemented now by <https://gcc.gnu.org/ git/?p=gcc.git;a=commit;h=0c5b35933e5b150df0ab487efb2f11ef5685f713> "libstdc++: P1423R3 char8_t remediation (2/4)" for -std=c++2a, deletes operator << overloads that would print a pointer rather than a (presumably expected) string. But here it should be fine to print pointers, esp. as there are null pointers involved. Change-Id: I62fad4cb9eaaa612989f035f686086ef29093d70 Reviewed-on: https://gerrit.libreoffice.org/84351 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2024-06-10 14:55:21 +0000