summaryrefslogtreecommitdiff
path: root/sal/qa/rtl
AgeCommit message (Collapse)Author
2022-03-29Add back the opportunity to leave O[U]StringLiteral's buffer uninitializedStephan Bergmann
...once we have a C++20 baseline, which would render uses of the consteval O[U]StringLiteral ctors ill-formed if we accidentally failed to write to all of buffer's elements. This had been broken (and the TODO comments had become misleading) with 21584b304b21bfe6b99b6f29018c6b754ea28fc0 "make OUString(OUStringLiteral) constructor constexpr" and bca539e889d40e06cb3275442622cb075b2484a2 "make OString(OStringLiteral) constructor constexpr". Also add corresponding test code. Change-Id: I2bc680282c717d403a681ff4b9396580c8382de1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132275 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-24-Werror,-WformatStephan Bergmann
Change-Id: Ifb282ae907495ab21f3a91b1cae1c34443cb3626 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132018 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-09Drop misguided test added in 82a1d32d3d3ac1b4b0a6d4cfaca791c77d9b3c03Mike Kaganski
The documented precondition is that index must not be greater than the length of string. Just assert that, and fix the found misuse. The added test is for in-place replacement, just in case. Change-Id: I3c545a6f0bf913fe93e2bef83ce733359c193065 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131232 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2022-03-09Simplify getTokenMike Kaganski
It should not attempt to dereference pointers when nIndex is negative. Properly handle too large nIndex. Also it is not necessary to parse the string when nToken is negative. Related to commit be281db569bafaac379feb604c39e220f51b18c4 Author Rüdiger Timm <rt@openoffice.org> Date Mon Sep 20 07:43:20 2004 +0000 INTEGRATION: CWS ause011 (1.18.22); FILE MERGED 2004/08/18 11:47:54 sb 1.18.22.1: #i33153# Made getToken more robust. Change-Id: I6fc77a5b70308ccca08cb2132bd78d024bd7e3e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131221 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-03-08Fix --with-latest-c++ buildStephan Bergmann
> In file included from workdir/UnpackedTarball/cppunit/include/cppunit/TestAssert.h:8, > from workdir/UnpackedTarball/cppunit/include/cppunit/TestCase.h:6, > from workdir/UnpackedTarball/cppunit/include/cppunit/TestCaller.h:5, > from workdir/UnpackedTarball/cppunit/include/cppunit/extensions/HelperMacros.h:9, > from sal/qa/rtl/oustring/rtl_ustr.cxx:25: > workdir/UnpackedTarball/cppunit/include/cppunit/tools/StringHelper.h: In instantiation of ‘typename std::enable_if<(! std::is_enum<_Tp>::value), std::__cxx11::basic_string<char> >::type CppUnit::StringHelper::toString(const T&) [with T = char16_t; typename std::enable_if<(! std::is_enum<_Tp>::value), std::__cxx11::basic_string<char> >::type = std::__cxx11::basic_string<char>]’: > workdir/UnpackedTarball/cppunit/include/cppunit/TestAssert.h:74:50: required from ‘static std::string CppUnit::assertion_traits<T>::toString(const T&) [with T = char16_t; std::string = std::__cxx11::basic_string<char>]’ > workdir/UnpackedTarball/cppunit/include/cppunit/TestAssert.h:168:58: required from ‘void CppUnit::assertEquals(const T&, const T&, SourceLine, const std::string&) [with T = char16_t; std::string = std::__cxx11::basic_string<char>]’ > sal/qa/rtl/oustring/rtl_ustr.cxx:696:17: required from here > workdir/UnpackedTarball/cppunit/include/cppunit/tools/StringHelper.h:25:9: error: use of deleted function ‘std::basic_ostream<char, _Traits>& std::operator<<(basic_ostream<char, _Traits>&, char16_t) [with _Traits = char_traits<char>]’ > 25 | ost << x; > | ~~~~^~~~ > In file included from include/rtl/ustring.hxx:34, > from sal/qa/rtl/oustring/rtl_ustr.cxx:22: > ~/gcc/trunk/inst/include/c++/12.0.1/ostream:558:5: note: declared here > 558 | operator<<(basic_ostream<char, _Traits>&, char16_t) = delete; > | ^~~~~~~~ Change-Id: I70ae970c10650d0e6efa5ced3a354090642d5387 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131164 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-07Add unit tests for searching empty substring / zero characterMike Kaganski
Related to commit 713c83c0fc4a0d9950cfa0b598d7c5f4bae15755 Add checks to avoid finding empty substring / zero character This activates tests in sal/qa/rtl/oustring/rtl_ustr.cxx Change-Id: Iab176e6583dc383a7a3413b0e19cc8f0d09b2824 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131087 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-03-04Drop commented out wrong testsMike Kaganski
Change-Id: Ief086996f94978d2ffd6879a6c3e5b0b2312dffe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130962 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-03-04Enable tests in rtl_str.cxxMike Kaganski
And disable the tests that try to use nullptr where it's not accepted. Change-Id: I1cd031e371485fdd57e7691565376253a01049c3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130938 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-02-25Make an -fsanitize=undefined workaround conditionalStephan Bergmann
...that had been introduced with b5cb4935c268f12e63b61e035b455b0a59e67aa2 "Work around undef conversion of large double to float" but should no longer be necessary with <https://github.com/llvm/llvm-project/commit/9e52c43090f8cd980167bbd2719878ae36bcf6b5> "Treat the range of representable values of floating-point types as [-inf, +inf] not as [-max, +max]" added towards Clang 9. Thanks to Mike Kaganski for pointing me at this old code and at Richard Smith's comment at <https://cplusplusmusings.wordpress.com/2013/03/26/testing-libc-with-fsanitizeundefined/>. Change-Id: I8ecf115fcf6b1ebf621cb4567f8d31ac9b10ef1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130531 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-17Use Dragonbox to implement doubleTo*String*Mike Kaganski
This header-only library is accurate in decimal representation of doubles; provides API that allows to create custom representation - so it's possible to use custom decimal separators and grouping. This allows to unify all corner cases: integers, numbers close to DBL_MAX, up-rounding to the next decade. Note that Dragonbox creates the shortest decimal representation of the number, that is unambiguously convertible back to the same number; thus it may hide trailing digits that are unneeded for such conversion. The functional changes are minimal, and beneficial: 1. Rounding numbers close to DBL_MAX now takes into account the bEraseTrailingDecZeros argument, as it should, allowing to have "1.8E+308" for rounding DBL_MAX to 2 decimals without trailing zeroes, instead of previous "1.80E+308". 2. Incorrect rounding is fixed in some cases, e.g. 9.9999999999999929 rounded to 10 previously using rtl_math_DecimalPlaces_Max. 3. Representing the number in the shortest way may change display of some printed numbers. E.g., 5th greatest double is represented as "1.797693134862315E+308" instead of a bit longer, but giving the same double on roundtrip, "1.7976931348623149E+308". This would generally look better for some numbers similar to the famous 0.1, where users would likely expect more "round" representation where it's unambiguous (but we still truncate to 15 significant decimals anyway - so there's no point in pretending to provide exact digits for actual binary representation). These are reflected in the unit tests affected by the change. Change-Id: I05e20274a30eec499593ee3e9ec070e1269232a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129948 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-02-17Bump Linux Clang baseline to 8.0.1Stephan Bergmann
...as discussed in the mail sub-thread starting at <https://lists.freedesktop.org/archives/libreoffice/2022-February/088476.html> "Also bump Linux Clang baseline to 12.0.1 (was: Bump --enable-compiler-plugins Clang baseline?)", and clean up newly-obsolete __clang_major__ checks Change-Id: Idacb9148b019c07e138277df3a085ba71c64a8e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130028 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-11-11Drop the OUString vs. OUStringLiteral comparison operator overloadsStephan Bergmann
...which can be subsumed by their OUString vs. OUString counterparts now that conversion from OUStringLiteral to OUString is cheap since e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString". (The only place that needed adaption was the dubious use of temporary OUStringLiteral instances in sal/qa/rtl/strings/test_oustring_stringliterals.cxx, which now caused "error: conversion function from 'rtlunittest::OUStringLiteral<6>' to 'const rtlunittest::OUString' invokes a deleted function".) Change-Id: I4f0f96efa2d5331ed5cbc9a29bdfdf3c0f4148a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125020 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-22Optimize assignment from OUStringLiteral to OUStringStephan Bergmann
...by making the OUString's pData point to the OUStringLiteral, instead of copying the contained characters. This is one of the improvements that had not been done as part of e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString": "To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc." (Simply dropping the OUStringLiteral overload was not possible in this case, though, as that would have lead to ambiguities among the various OUString and std::u16string_view overloads.) The now-deleted OUStringLiteral rvalue reference overload means that some existing assignments from ternary-operator OUStringLiteral<N> to OUString no longer compile and had to be replaced with uses of std::u16string_view. Those had not already been replaced in e6dfaf9f44f9939abc338c83b3024108431d0f69 because they happened to use OUStringLiteral instances of identical length N in both arms of the ternary operator, so did not already start to fail to compile back then. Change-Id: I328e25b8324d045774e811d20a639f40d6a9a960 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124040 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-03A more lightweight O[U]StringConcatenationStephan Bergmann
...compared to a full-blown O[U]String, for temporary objects holding an O[U]StringConcat result that can then be used as a std::[u16]string_view. It's instructive to see how some invocations of operator ==, operator !=, and O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit materialization of an O[U]String temporary, and how that expensive operation has now been made explicit with the explicit O[U]StringConcatenation ctor. (The additional operator == and operator != overloads are necessary because the overloads taking two std::[u16]string_view parameters wouldn't even be found here with ADL. And the OUString-related ones would cause ambiguities in at least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with RTL_STRING_UNITTEST, so have simply been disabled for that special test-code case.) Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-02Some corner case unit testsMike Kaganski
Change-Id: I43474265a9b3e1d07394c5f7e429e081d67f2eda Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122935 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-01Add unit test to catch eae24a9488814e77254d175c11fc4a138c1dbd30Mike Kaganski
Change-Id: I18b98f4be3212199004a1bb8fd8725fe71254ec4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122870 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-30Add a test for a negative integerMike Kaganski
Change-Id: I368123ce4ffdfb0e5c47e80cf4fece0c6ddc5f9d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122854 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-08-18GCC bug 96878 is fixed in upcoming GCC 12Stephan Bergmann
However, restricting the workaround to GCC <= 11 then revealed that some old versions of Clang apparently had a similar issue, causing "error: use of class template 'OStringLiteral' requires template arguments; argument deduction not allowed here", and thus also need the workaround. I saw the non-workaround code fail with a build of Clang 6.0.0 and succeed with a build of Clang 7.0.0. Change-Id: I6e4cf6c8c3a11618a578401574e5679e6b65d7f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120657 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-09Do not support +/-NaN with an explicit signStephan Bergmann
The code accepting "NaN" had been introduced with 92dafe9862d693ce9d79269627c3e6832422874e "dba33h: #i112652#: rtl/math.h: string<->double conversion and XMLSchema-2: [...] rtl_math_stringToDouble and rtl_math_uStringToDouble support XMLSchema-2 values in addition to deprecated previously supported values." The "XMLSchema-2" mentioned in that commit and in the corresponding <https://bz.apache.org/ooo/show_bug.cgi?id=112652> "ORB: report builder not handle correctly NULL values" presumably references <https://www.w3.org/TR/xmlschema-2/> "XML Schema Part 2: Datatypes Second Edition", where section "3.2.5 double" only supports "NaN" without a "+" or a "-" sign in the lexical representation. So stop accepting those. (I came across this in the context of 2b2b6405161025678f91a5625e50d0b414597368 "Reliably generate positive or negative NaN again", wondering whether this code should be updated too. But then decided that it is probably best not to allow that non-standard signed NaN notation for this case, and just keep producing for the "NaN" representation whatever std::numeric_limits<double>::quiet_NaN produces.) Change-Id: I035e78ca36240317f72f117d2b456fc474d8c08a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118647 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-07-08Reliably generate positive or negative NaN againStephan Bergmann
...after e5c80bb69a30dfb0a3daf6061ab127d92f8142d6 "Purge out setNan from math.cxx" had dropped the use of rtl::math::setNan and sign bit fiddling, and relied on the implicit assumption that std::numeric_limits<double>::quiet_NaN would produce a positive NaN (but which does not seem to be guaranteed by the C++ standard) and on the expressed hope that multiplying such a positive NaN by -1 would generate a negative NaN (but which does not seem to be guaranteed by IEEE 754: while it mandates that a NaN's payload is preserved across such an operation, the result's sign bit appears to be unspecified) Change-Id: I12215c888a1cb8de6b3f046a836c550cb21b5a85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118604 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-14Improve loplugin:stringviewStephan Bergmann
Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for operator call arguments. (The "rather than copy, pass subView()" diagnostic is already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly for operator call arguments.) (And many call sites don't even require an explicit [u16]string_view, esp. with the recent ad48b2b02f83eed41fb1eb8d16de7e804156fcf1 "Optimized OString operator += overloads". Just some test code in sal/qa/ that explicitly tests the O[U]String functionality had to be excluded.) Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-19use more string_view in OString APINoel Grandin
some parts of the OString seem to have fallen behind its more popular sibling OUString. Change-Id: Ie6d64c3005b2df5da49ba79d0c38282dd5057a23 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114252 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-03-25const OUString -> const OUStringLiteralMike Kaganski
Mostly automated rewrite Change-Id: Ie020a083f898bc126b8fb039d4ecb2e687172da1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112965 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-02-10Fix loplugin:stringliteralvarStephan Bergmann
...detection of OUString( const sal_Unicode * value, sal_Int32 length ) ctor. (On platforms where sal_Int32 is a typedef for int, an argument that already is of type int will not be wrapped in an ImplicitCastExpr to the sal_Int32 typedef.) Change-Id: Ifc5456a62d42c1acad76ea949549dc24bd67201a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110654 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-08Improve loplugin:cppunitassertequal for CPPUNIT_ASSERT(a && b)Stephan Bergmann
...by re-enabling the code temporarily #if'ed-out in a528392e71bc70136021be4e3d83732fccbb885e "Fixed/improved loplugin:cppunitassertequals" (and which then triggers lots of other lopglugin:cppunitassertequal CPPUNIT_ASSERT -> CPPUNIT_ASSERT_EQUAL warnings). For two css::uno::Reference equality comparisons in cppu/qa/test_any.cxx, it was more straightforward to rewrite them with an explicit call to operator == (which silences loplugin:cppunitassertequal) than to adapt them to CPPUNIT_ASSERT_EQUAL's requirement for arguments of identical types. In sc/qa/unit/ucalc_pivottable.cxx, ScDPItemData needs toString, which has been implemented trivially for now, but might want to combine that with the DEBUG_PIVOT_TABLE-only ScDPItemData::Dump. Change-Id: Iae6d09cf69bd4e52fe4411bba9e50c48e696291c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110546 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-28add string_view variants of methods to O[U]StringBufferNoel
and update the stringview loplugin to detect cases where we can use these new methods. Change-Id: I998efe02e35c8efcb3abfb4d7186165bbe6dfb2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110046 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-27Improve loplugin:stringliteralvarStephan Bergmann
...to also consider O[U]String ctors taking pointer and length Change-Id: Iea5041634bfbf5054a1317701e30b56f72e940fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110025 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-15OUString::matchAsciiL() can be used instead of the fresh startsWithAsciiL()Tor Lillqvist
Revert the addition of the latter. Change-Id: I93636a901cde401b0b7d923e052887f57dd58212 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109315 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-01-14Introduce startsWithAsciiL() to match endsWithAsciiL()Tor Lillqvist
Will be used in an upcoming change. Unit test included. Change-Id: I777a755cab543ea277b84fb5ad021d0b91725764 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109264 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-01-10fix coverity parse errorsCaolán McNamara
Change-Id: I4884bfb67a061b865e8cf38b2fea6de0cb1bc3d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109057 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-26New loplugin:stringliteralvarStephan Bergmann
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for details. (Turned some affected variables in included files into inline variables, to avoid GCC warnings about unused variables.) Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-23Use char16_t string literalsStephan Bergmann
Change-Id: I0a8b577957ac1d4cad5fc1163f244012a8391a77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108216 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-20Remove the OUString vs. std::u16string_view comparison operators againStephan Bergmann
...that were introduced in e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString" to avoid ambiguities, but which is no longer an issue since 46c5de832868d2812448b2caace3eeaa9237b9f6 "make *String(string_view) constructors explicit" Change-Id: I0a7a3fe23412f77fa85fb7e90f04e22f9abd9230 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108044 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-14Add empty OUStringBuffer::toString testStephan Bergmann
...motivated by <https://gerrit.libreoffice.org/c/core/+/107643> "Don't crash on an empty OUStringBuffer::toString" Change-Id: I144f0814f585f56df3fcdc818fd8c5e18ad08115 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107672 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-08Improve a CPPUNIT_ASSERT messageStephan Bergmann
Change-Id: Ia40f249a115a8c4fe01fb384041b4542735166c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-03tdf#138360: sal_rtl: Add unittestXisco Fauli
Change-Id: Iac6c4bf09f55446128d7fb7a35b483ca41bc4f00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107080 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-11-28Unit tests for DBL_MAX to string conversion, tdf#136272Eike Rathke
Change-Id: Ied41d1e21fb6e40b54adac3c33fa0d096e25bada Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106783 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-11loplugin:stringviewNoel
Add new methods "subView" to O(U)String to return substring views of the underlying data. Add a clang plugin to warn when replacing existing calls to copy() would be better to use subView(). Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-28Extend loplugin:elidestringvar to OStringStephan Bergmann
(In VisitVarDecl, filtering out AbstractConditionalOperator avoids an unhelpful > ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:63:32: error: replace single use of literal 'rtl::OString' variable with a literal [loplugin:elidestringvar] > aXmlWriter.content(sPdfConformance); > ^~~~~~~~~~~~~~~ > ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:52:21: note: literal 'rtl::OString' variable defined here [loplugin:elidestringvar] > OString sPdfConformance = (mnPDF_A == 1) ? "A" : "B"; > ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ) Change-Id: I7d0410f04827d79b4b526752917c37d33cad2671 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104911 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-22OUStringLiteral/OStringLiteral coverity PARSE_ERROR workaroundCaolán McNamara
do more like commit 121771e37f7e2de41cd5643475861062bf25627b Date: Mon Sep 21 09:17:54 2020 +0200 Make some OUStringLiteral vars constexpr cause coverity can live with that Change-Id: I9efd7f848289c4865997a44c6780373068422227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-08Fix typos in commentsStephan Bergmann
Change-Id: I8a8108ae970613559a68d996dddcee485ddc052f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102235 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-05Make OUString(char16_t const[N]) ctor check for embedded NULsStephan Bergmann
...and fix the detected fallout. That ctor only started to get used recently with a1570b6052ae9c9349282027c9007b071589bce6 "Make the OUString ConstCharArrayDetector::TypeUtf16 overloads are actually used", but it turns out that that also gave rise to that ctor being picked in error. To better guard against such erroneous uses, make that ctor assert that the given array does not contain embedded NUL characters, see the new sal/qa/rtl/strings/nonconstarray.cxx tests. The one place where that assert would fire during `make check` is fixed now in SwWW8ImplReader::ImportDopTypography. That assert would also fire for tow OUStringLiteral-related tests in the recently added test::oustring::StringLiterals::checkEmbeddedNul, so drop those for how. They cna presumably be added back (with reversed logic values) when OUStringLiteral is changed similarly to how OStringLiteral was changed in 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Change-Id: I6056244003a20f77ba0d953538d25edcbd562211 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102063 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-09-03Fix typoStephan Bergmann
...introduced with b5ad72bbfca85946e352b56d9d2ee5eb71cd2132 "Replace VALID_CONVERSION macro with function". (VALID_CONVERSION of a lambda was trivially false, as neither OUString nor OUStringBuffer have a ctor taking a lambda, anyway.) Change-Id: I1d4f2de0e1b1973d8680f53e03dbbb3d939fcc03 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101982 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-02Turn OStringLiteral into a consteval'ed, static-refcound rtl_StringStephan Bergmann
...from which an OString can cheaply be instantiated. The one downside is that OStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a containers that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::string_view, without loss of efficiency compared to the original OStringLiteral, and without loss of expressivity (esp. with the newly introduced OString(std::string_view) ctor). The new OStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OStringLiteral is in all cases where an object that shall itself not be an OString (e.g., because it shall be a global static variable for which the OString ctor/dtor would be detrimental at library load/unload) must be converted to an OString instance in at least one place. Other string literal abstractions could use std::string_view (or just plain char const[N]), but interestingly OStringLiteral might be more efficient than constexpr std::string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. sal/qa/rtl/strings/test_ostring_concat.cxx documents some workarounds for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". Those places, as well as uses of OStringLiteral in incodemaker/source/javamaker/javaoptions.cxx and i18npool/source/breakiterator/breakiterator_unicode.cxx, which have been replaced with OString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). This change also revealed a bug in at least recent Clang 12 trunk CastExpr::getSubExprAsWritten (still to be reported to LLVM), triggered at least in some calls from loplugin code (for which it can be fixed for now in the existing compat::getSubStringAsWritten). A similar commit for OUStringLiteral is planned, too. Change-Id: Ib192f4ed4c44769512a16364cb55c25627bae6f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101814 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-30Goodbye O[U]StringView, welcome O[U]String::ConcatStephan Bergmann
O[U]StringView had an odd mixture of uses. For one, it was used like std::[u16]string_view, for which directly using the latter std types is clearly the better alternative. For another, it was used in concatenation sequences, when neither of the two leading terms were of our rtl string-related types. For that second use case introduce O[U]String::Concat (as std::[u16]string_view can obviously not be used, those not being one of our rtl string-related types). Also, O[U]StringLiteral is occasionally used for this, but the planned changes outlined in the 33ecd0d5c4fff9511a8436513936a3f7044a775a "Change OUStringLiteral from char[] to char16_t[]" commit message will make that no longer work, so O[U]String::Concat will be the preferred solution in such use cases going forward, too. O[U]StringView was also occasionally used to include O[U]StringBuffer values in concatenation sequences, for which a more obvious alternative is to make O[U]StringBuffer participate directly in the ToStringHelper/O[U]StringConcat machinery. Change-Id: I1f0e8d836796c9ae01c45f32c518be5f52976622 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101586 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
generated by cgit (git 2.34.1) at 2025-02-01 00:00:42 +0000