summaryrefslogtreecommitdiff
path: root/sal/rtl
AgeCommit message (Collapse)Author
2021-01-10Missing include guard in new sal/rtl/strtmpl.hxxStephan Bergmann
...as causing trouble in ASan/UBSan builds, > [CXX] jurt/source/pipe/staticsalhack.cxx > In file included from jurt/source/pipe/staticsalhack.cxx:20: > In file included from sal/rtl/ustring.cxx:51: > sal/rtl/strtmpl.hxx:38:28: error: redefinition of 'IMPL_RTL_USTRCODE' > template <typename C> auto IMPL_RTL_USTRCODE(C c) { return std::make_unsigned_t<C>(c); } > ^ > sal/rtl/strtmpl.hxx:38:28: note: previous definition is here > template <typename C> auto IMPL_RTL_USTRCODE(C c) { return std::make_unsigned_t<C>(c); } > ^ [...] Change-Id: Ied38a5f96bbb6d1c0d8ae956629ca6be64dc273f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109055 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-10Replace strtmpl.cxx with actual C++ templates in strtmpl.hxxMike Kaganski
This has at least better IDE support, with easier lookup for function implementations. Change-Id: I0e4cfe40df036efa796c057852bd5cb4421507f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108931 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-12-18Check intermediate for not to be rounded value, tdf#138360 follow-upEike Rathke
Change-Id: I98cc25267e7a10c34179bab50d19f49436e1c48c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107929 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-12-18Replace log2() call with parts.exponent-1023, tdf#138360 follow-upEike Rathke
... to save some cycles as we anyway need only the integer value of the exponent and even exactly this value for the number of possible decimals. Change-Id: I8d462f53cadde6a95d57d1342d8487fbfa001ae9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107928 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-12-10Avoid calling OString ctor with null pointerStephan Bergmann
...in preparation of potential future changes from using OString to using std::string_view, where OString has an undocumented feature of allowing construction from a null pointer. This is mostly the result of a manual audit of potentially problematic getenv calls across the code base. But there can be other problematic places too, like the xmlGetProp call in tools/source/xml/XmlWalker.cxx. To identify those, rtl_{string,uString}_newFromStr aborts now in non-production debug builds when a null pointer is passed(and all places that hit with a full `make check screenshot` have been addressed here). Once we are confident that all problematic places have been identified, we should drop support for the undocumented feature (see the TODO in sal/rtl/strtmpl.cxx). Change-Id: I595cc6d4f1cda74add2a3db171323f817d362b08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107430 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-08Tighten rtl_{string,uString}_newFromStr_WithLength implementationStephan Bergmann
While the documented interface was already narrow (or at least didn't suggest that the length argument could reasonably be negative), the implementation was somewhat broader: For one, it allowed the character pointer to be null even when the length was non-zero, which looks more like a call-site bug than like a useful feature. And for another, while it did assert that the length is non- negative, it nevertheless then checked "overly defensively" for <= 0 rather than == 0 down the road. Change-Id: I084148aaa4b9c4aea16729b0ce90b73ccbe73ebe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107425 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-03Better accuracy in rtl_math_approxValue(), tdf#138360 relatedEike Rathke
Similar to commit 5abb1890ffafe5a2212076208a1c6e226f1ffa4e for rtl_math_round() use the reciprocal value in an inverse operation for negative exponents to not use the inexact 1e-1 0.10000000000000001 and so on factors. Change-Id: I05b852e06f2c31d6e0ce622b07277a81a5690833 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107172 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-12-03Related: tdf#138360 Use approxFloor() in rtl_math_round()Eike Rathke
Ditch mostly but not always working correction value and use approxFloor() instead which yields better results. With this we now have one single place approxValue() in case more fine grained tuning is needed. Unfortunately all numeric spreadsheet function tests use ROUND() in a manner such that they mostly blindly do a ROUND(...;12) regardless of magnitude, sometimes effectively rounding to the 14th significant digit that may fail in cases like for 14.2040730851385 ^ where the constant (rounded) value is stored as is but the calculated value is 14.204073085138471 and the old round() yielded 14.204073085139 for both but the new round() more correctly results in 14.204073085139 and 14.204073085138 so the spreadsheet test case sources had to be changed to ROUND(...;11) in such places. Change-Id: I211bb868a4f4dc9e68f4c7dcc2a187b5e175416f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107135 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-12-02Typo in rounded digit string, tdf#138360 follow-upEike Rathke
Change-Id: Ic436d3e9f0c93cb36c5e4377519f2aeb6b7fbd5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107034 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-12-02Related: tdf#138360 Rounding integers to decimals is futileEike Rathke
Change-Id: Ica25747a26d6c2637c46808d1b73aeeed6e1df37 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107001 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-11-28Resolves: tdf#138360 better accuracy in rtl_math_round()Eike Rathke
Decimal negative exponents (powers) are imprecise 1e-1 0.10000000000000001 1e-2 0.01 1e-3 0.001 1e-4 0.0001 1e-5 1.0000000000000001e-05 1e-6 9.9999999999999995e-07 1e-7 9.9999999999999995e-08 1e-8 1e-08 1e-9 1.0000000000000001e-09 1e-10 1e-10 1e-11 9.9999999999999994e-12 1e-12 9.9999999999999998e-13 1e-13 1e-13 1e-14 1e-14 1e-15 1.0000000000000001e-15 1e-16 9.9999999999999998e-17 1e-17 1.0000000000000001e-17 1e-18 1.0000000000000001e-18 1e-19 9.9999999999999998e-20 1e-20 9.9999999999999995e-21 so use the positive exponents instead and swap multiplication and division when scaling and scaling back the value, which multiplies the rounded value with a precise integer instead of dividing it by an imprecise fraction. For a large (absolute) value check if it is roundable to the desired decimals at all with the binade's distance precision gap and if not then diminish the decimals parameter. This prevents possible inaccuracies due to overly scaling the value. Change-Id: I41a113078031a552cf98d72f8cb2b10bdc88dea4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106830 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-11-27Consistently use RTL_CONSTASCII_LENGTH(), tdf#136272 follow-upEike Rathke
The mix with SAL_N_ELEMENTS() was confusing and even wrong in one case. Change-Id: Ife73342b0efc01ed4e76e217d372fc32500c9b2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106764 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-11-27Fix commentEike Rathke
Change-Id: I2ae6e3cadc0f182c4798e5d33b0c7f07fbcbbff6
2020-11-27Resolves: tdf#136272 convert DBL_MAX to 1.7976931348623157e+308Eike Rathke
... and the 4 subsequent nextafters to appropriate strings. An interim workaround to not write the out-of-range string 1.79769313486232e+308 until we have a proper rounding. Change-Id: I5f98a7f0a8e0421fd024a8cc37cc6f3a198d02d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106717 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-11-25Related: tdf#136272 accept 1.79769313486232e+308 as DBL_MAXEike Rathke
This does not solve writing the badly rounded value, which still has to be fixed, but at least be able to read/convert it back as double max value. This is not even used in the bug scenario because the "fake" condition in that number format is discarded anyway because it was only written to satisfy ODF, but it helps in case a 1.7976931348623157e+308 value was entered/used on purpose. Change-Id: I413dd93d5a3c4df609fd42a3133d6d82c34afff0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106586 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-11-21Relax non-null requirement for some rtl_uString_* functionsStephan Bergmann
...that take a pointer and a length, and where it should be OK that the pointer is null if the length is zero. Those rtl_uString_* functions are targets of OUString member functions that take std::[u16]string_view arguments, and 19926ed35ebb623fc896942b1f232b83edf1fc1e "loplugin:stringview: Flag empty string converted to string view" (which changed some call sites to pass in default- constructed std::[u16]string_view, for which data() returns null) revealed that those rtl_uString_* functions were not prepared for such input. (The guardings of memcpy are necessary because memcpy still requires its pointer arguments to be non-null, even if the corresponding length is zero.) The new sal/qa/rtl/strings/test_strings_defaultstringview.cxx systematically tests all O[U]String[Buffer] member functions taking std::[u16]string_view arguments. It revealed one further issue in IMPL_RTL_STRNAME(compare_WithLength), where UBSan reported a nullptr-with-nonzero-offset > sal/rtl/strtmpl.cxx:149:9: runtime error: applying non-zero offset 18446744073709551614 to null pointer Also, rtl_uString_newReplaceFirstUtf16LUtf16L was found to lack a check for its `from` argument to be non-null. Change-Id: I6a7a712570f7d1e8d52097208c8a43a5a24797af Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106295 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-21tdf#123936 Formatting files in module sal with clang-formatPhilipp Hofer
Change-Id: I04a773e8fd565f57dc0eb887fb4714b6edbb35e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105699 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
2020-11-18Replace #if with if constexpr()Mike Kaganski
This allows to test the actual type, not something unrelated Change-Id: I82d0714f6355fc5ae7bd3205af3472a43f1f1051 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105998 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-11-16replace std::max(std::min()) with std::clampNoel
Change-Id: I890d19f5e2177294dc1175c90c98b964347f9e85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105751 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-18Limit nDecPlaces to a sensible value [-20, 20]Eike Rathke
Protect against callers using for example rtl_math_StringFormat_F with rtl_math_DecimalPlaces_Max in worst case.. Change-Id: I9f143df6ae67b22e7732547c0f7a53b498caf2b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104472 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-10-05loplugin:reducevarscope in salNoel
Change-Id: I2ce95de07b8e0952a1e778e65940b30597396aa6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103949 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-12Replace remaining uses of sal_CharJulien Nabet
+ remove sal_Char check on compilerplugins Change-Id: I0f7da14e620f0c3d031d038aa8345ba4080fb3e9 Change-Id: Ia6dba4f27b47bc9e0c89159182ad80a5aee17166 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102499 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-04Make many OUString functions take std::u16string_view parametersStephan Bergmann
...instead of having individual overloads for OUString, OUStringLiteral, and literal char16_t const[N]. (The variants taking OUString are still needed for !LIBO_INTERNAL_ONLY, though. The variants taking ASCII-only literal char const[N] are also left in place.) This nicely reduces the number of needed overloads. std::u16string_view allows to pass as arguments: * OUString * OUStringLiteral * OUStringChar (with the necessary conversion added now) * OUStringNumber * u"..." char16_t string literals * u"..."sv std::u16string_view literals * std::u16string, plain char16_t*, and more A notable exceptions is OUStringConcat, which now needs to be wrapped in OUString(...), see the handful of places that needed to be adapted. One caveat is the treatment of embedded NUL characters, as std::u16string_view(u"x\0y") constructs a view of size 1, while only u"x\0y"sv constructs a view of size 3 (which matches the old behavior of overloads for literal char16_t const[N] via the ConstCharArrayDetector<>::TypeUtf16 machinery). See the new checkEmbeddedNul in sal/qa/rtl/strings/test_oustring_stringliterals.cxx. The functions that have been changed are generally those that: * already take a string of determined length, so that using std::u16string_view, which is always constructed with a determined length, is no pessimization (e.g., there are operator == overloads taking plain pointers, which do not need to determine the string length upfront); * could not benefit from the fact that the passed-in argument is an OUString (e.g., the corresponding operator = overload can reuse the passed-in OUString's rtl_uString pData member); * do not run into overload resolution ambiguity issues, like the comparison operators would do. One inconsistency that showed up is that while the original replaceAll(OUString const &, OUString const &, sal_Int32 fromIndex = 0) overload takes an optional third fromIndex argument, the existing replaceAll overloads taking OUStringLiteral and literal char16_t const[N] arguments did not. Fixing that required a new (LIBO_INTERNAL_ONLY) rtl_uString_newReplaceAllFromIndexUtf16LUtf16L (with test code in sal/qa/rtl/strings/test_strings_replace.cxx). Another issue was posed by test code in sal/qa/rtl/strings/test_oustring_stringliterals.cxx that used the RTL_STRING_UNITTEST-only OUString(Except*CharArrayDetector) ctors to verify that certain function calls should not compile (and would compile under RTL_STRING_UNITTEST by taking those Except*CharArrayDetector converted to OUString as arguments). Those problematic "should fail to compile" tests have been converted into a new CompilerTest_sal_rtl_oustring. Change-Id: Id72e8c4cc338258cadad00ddc6ea5b9da2e1f780 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102020 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-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-07-02Upcoming improved loplugin:staticanonymous -> redundantstatic: salStephan Bergmann
Change-Id: I022f5ed37d25f2c8a8870033bab32ff59d4d8da6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97648 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-29loplugin:simplifybool in oox..sdNoel Grandin
Change-Id: I76cbd5d3e65f0b392d713a51607f5c88dae79593 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95101 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-17Just use __builtin_ffs on GCC and ClangStephan Bergmann
GCC appears to support it at least since <https://gcc.gnu.org/git/ ?p=gcc.git;a=commit;h=51e2940139d5e3e86590f6e6802ffc3f3010be5b> "Initial revision" in 1992, and Clang appears to support it since <https://github.com/ llvm/llvm-project/commit/d93abc3bb0acdd430839abdd67bd3920fee87bbc> "Implement ffs, parity, and popcount builtins" in Clang 2.4. (And if a build used a compiler that does not support it, there would be no guarantee that it would support strings.h function ffs from X/Open System Interfaces, either.) Introducing HAVE_GCC_BUILTIN_FFS in 334a9f16cd1d1f9694f885c759903a41aa3d4833 "tdf#113211: fix calculations with big integers" appears to be due to a misguided recommendation at <https://gerrit.libreoffice.org/c/core/+/43477/4# message-899806c724fbdcece0ea9438514a6a5db6a2e645>. Change-Id: Ib6ee6de548172b3aae25483d03efb86620133933 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92421 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-15loplugin:buriedassign in salNoel Grandin
Change-Id: I5a7bc9378ceacb9116c03e3a9fc01c5675c40908 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92243 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-02loplugin:flatten in salNoel Grandin
Change-Id: Icc30c79d599486203c8f763cd5ff43059f0bb910 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91556 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-14tdf#130975 replace `rtl::math::isNan` with `std::isnan`.Yukio Siraichi
Change-Id: I5d53e6369d35093445b2efd8936bbf8c6775ff47 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90451 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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-12tdf#130976 replace `rtl::math::isInf` with `std::inf`.Yukio Siraichi
Change-Id: Id0f0e07b324230d2d69cbf4ab07b0fff5b24474d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90377 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-03-12tdf#130977 replace `rtl::math::isFinite` with `std::isfinite`.Yukio Siraichi
- make all calls look like `std::isfinite`. - change the comments referring `rtl::math::isFinite`. Change-Id: I0cde9ceb9f20150467b454cddde5e62003cfde1a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90234 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-03-12Revert "loplugin:constfields in reportdesign,sal,sax"Noel Grandin
This reverts commit d4d37662b090cb237585156a47cd8e1f1cbe2656. Now that we know that making fields has negative side effects like disabling assignment operator generation. Change-Id: Idef4937b89a83d2efbfaf0ab87d059a0143c0164 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90364 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-27Related: tdf#130725: use strtod also in rtl::math::stringToDoubleMike Kaganski
Size of buffer on stack is 256 characters. Logging function usage in make check, of >1 100 000 invocations, the longest string was 80 characters, average being 4.6 characters. So heap allocation is unlikely in scenarios with intensive function usage. Several existing unit tests had to be fixed. Usually, the change is either minimal or getting closer to what Excel returns (for Calc tests). But in case of AMORDEGRC, I had to change rate value passed to the function from 0.3 to 0.31. It's because the closest double value for 0.3 is 0.29999999999999999, which is a bit less than 0.3; multiplied by 1.5, this gives 0.44999999999999996, and then rounding the result of multiplication of the latter by cost gave the result 1 less than before, when 0.3 was imported as 0.30000000000000004. Now the function returns a value 1 less than Excel for that set of arguments. I don't see how to fix that. Having rate slightly different gives consistent result between Calc and Excel. Change-Id: Icae5ce374fe0c31a1aa10cee815e65ef0014f382 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89422 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-01-28loplugin:unsignedcompare (--enable-cipher-openssl-backend)Stephan Bergmann
Change-Id: Iab5ab11059437a595596e8ba3ec7aa45cec15f0d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87617 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-25Change some #define to constexprStephan Bergmann
...plus loplugin:unnecessaryparen fallout in sw/source/uibase/docvw/edtwin.cxx. Each of the files contained at least one #define that would have caused warnings with upcoming loplugin:unsignedcompare. For consistency, I changed all #defines in those files (using a variable of a specific type if the original #define used a cast to that type, otherwise using 'auto'). Change-Id: I66f71b2d83394c9dc6952ae19df774cdd4d0b76a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87374 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-19sal_Char->char in remotebridges..saxNoel Grandin
Change-Id: I6d32942960a5e997f16eb1301c45495661cd4cea Reviewed-on: https://gerrit.libreoffice.org/85514 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-06Remove spurious #includeStephan Bergmann
...that had been added by accident with 55e596956e56b175ab17b682e7c8ac7daeb9289a "loplugin:external (clang-cl)" Change-Id: Ieff93c825632d68adb621d8f646ff8abb72b5452 Reviewed-on: https://gerrit.libreoffice.org/84599 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-05loplugin:external (clang-cl)Stephan Bergmann
...plus loplugin:consttobool and loplugin:fakebool fallout Change-Id: Ie3d8121815c080b13bea6d9deca1eb138ca56138 Reviewed-on: https://gerrit.libreoffice.org/84515 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-22Extend loplugin:external to warn about classesStephan Bergmann
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-17Extend loplugin:external to warn about enumsStephan Bergmann
To mitigate the dangers of silently breaking ADL when moving enums into unnamed namespaces (see the commit message of 206b5b2661be37efdff3c6aedb6f248c4636be79 "New loplugin:external"), note all functions that are affected. (The plan is to extend loplugin:external further to also warn about classes and class templates, and the code to identify affected functions already takes that into account, so some parts of that code are not actually relevant for enums.) But it appears that none of the functions that are actually affected by the changes in this commit relied on being found through ADL, so no adaptions were necessary for them. (clang::DeclContext::collectAllContexts is non-const, which recursively means that External's Visit... functions must take non-const Decl*. Which required compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support such Visit... functions with non-const Decl* parameters.) Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd Reviewed-on: https://gerrit.libreoffice.org/83001 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-12Silence -Werror=sign-compare (--enable-cipher-openssl-backend)Stephan Bergmann
as found by <https://ci.libreoffice.org/job/lo_tb_random_config_linux/2039/> Change-Id: Ie698b7905bd2f25e74791f91f586479d1fc473dc Reviewed-on: https://gerrit.libreoffice.org/82488 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-31tdf#125688 speed up load of change-tracking ODSNoel Grandin
by 10%, by avoiding an OUString construction in a hot path through XMLTextColumnContext_Impl::XMLTextColumnContext_Impl -> sax::Convert::convertNumber Also changed XMLTextAnimationStepPropertyHdl::importXML to take advantage of the modified convertNumber passing convention. Change-Id: I4e5503dbb094c88a09af8b6dc8c22b6c53f9eb75 Reviewed-on: https://gerrit.libreoffice.org/81726 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-21size some stringbuffer to prevent re-allocNoel Grandin
found by the simple expidient of putting asserts in the resize routine. Where an explicit const size is used, I started with 32 and kept doubling until that site did not need resizing anymore. Change-Id: I998787edc940d0a3ba23b5ac37131ab9ecd300f4 Reviewed-on: https://gerrit.libreoffice.org/81138 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-14loplugin:stringadd look for unnecessary temporariesNoel Grandin
which defeat the *StringConcat optimisation. Also make StringConcat conversions treat a nullptr as an empty string, to match the O*String(char*) constructors. Change-Id: If45f5b4b6a535c97bfeeacd9ec472a7603a52e5b Reviewed-on: https://gerrit.libreoffice.org/80724 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-17Better handling of non--UTF-8 filesystem pathnames in sal/osl/unx/Stephan Bergmann
The idea is to internally in sal/osl/unx/ use OString instead of OUString to represent pathnames, so that the OString carries the actual bytes that make up the pathname. At the boundary of translating between pathname OStrings and file URL OUStrings, translate sequences of bytes that are valid according to osl_getThreadTextEncoding() into UTF-8 and translate other bytes into individual (percent-encoded) bytes in the file URL. This change required duplicating some of the internal functionality in sal/osl/unx/ for both OString and OUString, and to make part of sal/rtl/uri.cxx accessible from sal/osl/unx/ via new sal/inc/uri_internal.hxx. Change-Id: Id1ebaebe9e7f2d21f350f6b1a07849edee54331f Reviewed-on: https://gerrit.libreoffice.org/78798 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-06Fixing "...."Andrea Gelmini
Change-Id: I3424e17cfdfb563fdc5882942031deafae8689fe Reviewed-on: https://gerrit.libreoffice.org/78678 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-09Resolves: tdf#126766 fix rounding correction at start of negative valuesEike Rathke
doubleToString() is entered with an inaccuracy afflicted fValue=-9999.9999999999927 for which the rounding into the next magnitude incremented the '-' character to '.' instead of appending a '1' (and '0' and then "000") thus yielded ".0000" instead of "-10000" This seems to have been always the case. Change-Id: I66170defa71fec40ca0b85f68affde8eff0d5ccb Reviewed-on: https://gerrit.libreoffice.org/77208 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2019-08-02Fix typosAndrea Gelmini
Change-Id: Ie183c445bf8a545f59aac7b0e29f72ab679a6cf3 Reviewed-on: https://gerrit.libreoffice.org/76852 Tested-by: Jenkins Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
generated by cgit (git 2.34.1) at 2024-07-19 08:58:35 +0000