summaryrefslogtreecommitdiff
path: root/include/rtl/ustring.hxx
AgeCommit message (Collapse)Author
2021-02-02tdf#130978 Added comment to all published APImsrijita18
Change-Id: I744788bde9778f85ccd9d7667e19d16842900a29 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110248 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>
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-19make *String(string_view) constructors explicitNoel Grandin
to make it more obvious when we are constructing heap OUStrings code and potentially inadvertently throwing away performance. And fix a handful of places so revealed. Change-Id: I0cf390f78026f8a670aaab53424cd31510633051 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107923 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann
...for LIBO_INTERNAL_ONLY. These had been missed by 1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take std::u16string_view parameters" because they did not match the multi-overload pattern that was addressed there, but they nevertheless benefit from being changed just as well (witness e.g. the various resulting changes from copy() to subView()). This showed a conversion from OStringChar to std::string_view to be missing (while the corresponding conversion form OUStringChar to std::u16string_view was already present). The improvement to loplugin:stringadd became necessary to fix > [CPT] compilerplugins/clang/test/stringadd.cxx > error: 'error' diagnostics expected but not seen: > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd] > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd] > 2 errors generated. Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-11-11disable O(U)String::concat for internal codeNoel Grandin
in favour of the more widely used, and better optimised, operator+ Change-Id: I6a1b37e0f3d253af1f7a0892443f59b620efea63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105523 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-22Simplify those assertLayout checksStephan Bergmann
...recently introduced with 52a49f9e480ca03e231cfda82640a928393131c9 "static_assert that O[U]StringLiteral are layout compatible with rtl_[u]String" Change-Id: Ie89e92aa4230329aa582c4211c2001117d2287b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103138 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-21static_assert that O[U]StringLiteral are layout compatible with rtl_[u]StringStephan Bergmann
...as was suggested by Mike Kaganski in a comment at <https://gerrit.libreoffice.org/c/core/+/102222/10# message-aa8bcf42f04686766440e2848c7d1f76f474f2f8> "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString". Doing so revealed that at least lopglugin:unusedmember needs to handle InjectedClassNameType as an alternative to RecordType in at least one place. (More places across compilerplugins might benefit from handling InjectedClassNameType too, but which did not lead to assertion failures for now and should be addressed in follow-up issues.) Change-Id: Icdb8b069324b5ce5f3c7c6b92989379ccb67fc8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103125 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@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-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-07Make the OUString ctors taking raw sal_Unicode pointer/non-const array explicitStephan Bergmann
...and in turn add OUString::operator = and OUString::operator += overloads that take a std::u16string_view. Without making the ctors explicit, the operator overloads would have caused ambiguities when called with raw sal_Unicode pointers/non-const arrays, as those can convert to both OUString and to std::u16string_view. But the std::u16string_view operator overloads will generally be useful when changing OUStringLiteral similarly to 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which point many existing uses of OUStringLiteral will be replaced with uses of std::u16string_view. Implementing this change turned up a need for an operator = overload for OUStringNumber, which has thus been added. No such need turned up for a corresponding operator += overload, but which can easily be added when the need arises. It also revealed that the operator == overloads between an OUString and a raw sal_Unicode pointer/non-const array were implemented rather inefficiently, creating a temporary OUString from the raw argument. Those have been improved. Preceding commits have already taken care of many dubious or simply unnecessary implicit uses of the now-explicit OUString ctors. This commit makes explicit the few remaining reasonable uses. (And in some cases needed to change variable initialization syntax from using parentheses to using curly braces, to avoid the most vexing parse issue. And needed to explicitly add OUString ctors from char16 const[2] string literal lvalues in a conditional expression in writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary because MSVC apparently still insists on doing array-to-pointer decay there.) All of this only affects LIBO_INTERNAL_ONLY. Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098 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-01Adapt documentation commentStephan Bergmann
...to 33ecd0d5c4fff9511a8436513936a3f7044a775a "Change OUStringLiteral from char[] to char16_t[]" Change-Id: I661e1b1ce59461f30a9c1d75a1e4acb71fa113f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101770 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-31Fix typos in commentsStephan Bergmann
...introduced with 2e21240f23ac2191a3535d697a7308b29303c67c "Goodbye O[U]StringView, welcome O[U]String::Concat". Thanks to Mike for spotting them! Change-Id: Ic401c564eac03a34184204f09cb8d0cb6be4e6e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101689 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-29Make the OUString ConstCharArrayDetector::TypeUtf16 overloads are actually usedStephan Bergmann
0c8fa58a2d73702770687ed15b98822d09f96ac3 "Support ConstCharArrayDetector also for UTF-16 arrays" had introduced those LIBO_INTERNAL_ONLY ctor and operator == overloads, but they never got called because the existing 'sal_Unicode const *' overloads always won. (The other function overloads introduced with 0c8fa58a2d73702770687ed15b98822d09f96ac3 should be unproblematic, as they do not have any 'sal_Unicode const *' overload counterparts.) Also fix the resulting loplugin:elidestringvar and loplugin:stringconstant fallout. For one, those plugins look at the actual ctor overloads being used, so had missed those cases that accidentally had used an unexpected overload. And for another, the heuristic the plugins used to detect the ConstCharArrayDetector overloads turned out to be too simplistic now and would have started to cause false positives. Change-Id: I4426890979fb832d53f391c7e1b62bc1ad501a65 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101582 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>
2020-08-26Except[Const]CharArrayDetector is only used by RTL_STRING_UNITTESTStephan Bergmann
...which in turn should be a LIBO_INTERNAL_ONLY feature, so confine all relevant declarations accordingly Change-Id: I7545eadad6f097d0ee905583b1610631c92f1858 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101373 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-26Missing 'const'Stephan Bergmann
Apparently typos in 0c8fa58a2d73702770687ed15b98822d09f96ac3 "Support ConstCharArrayDetector also for UTF-16 arrays" that went unnoticed as for a const OUString s, s == u"..." could still pick the bool operator ==(OUString const &, sal_Unicode const *) overload. Change-Id: I61344ef2912fffca3cccf375e2e4c2be9beca604 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101377 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-05Disable -Wstringop-overflow in --enable-optimized builds with GCCStephan Bergmann
This reverts commit e287fde52fb9de5bdf1d00c8a3fbfcca7db9892c "Silence bogus -Wstringop-overflow with GCC trunk towards GCC 10", as that workaround, which happened to work for some revisions of GCC trunk towards GCC 10, no longer works for GCC 10 release candidates, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92893#c9> "[10 Regression] Unhelpful -Wstringop-overflow warning for a trailing one-element array". (Using -Wstringop-overflow=1 instead of the -Wstringop-overflow=2 default would have still caused bogus warnings, requiring -Wno-stringop-overflow.) Change-Id: I9b7342748c18da32f509b4a0e0653aede8447657 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93499 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-29Silence bogus -Wstringop-overflow with GCC trunk towards GCC 10Stephan Bergmann
...see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92893> "Unhelpful -Wstringop-overflow warning" Change-Id: I14b2e5e19b57df6f57a9252f27ee4b3feb8ba18c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85161 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-30Fix typoAndrea Gelmini
Change-Id: I8d7ed542dc331d3861fcfe2fec7250b5a4bbb166 Reviewed-on: https://gerrit.libreoffice.org/84094 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-29Enable O[U]String move ctor/assignment for WinMike Kaganski
Change-Id: If7ad38a7a802732e84db9352a475644327769d62 Reviewed-on: https://gerrit.libreoffice.org/84043 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-10-17Rename OUStringLiteral1 to OUStringCharStephan Bergmann
It started out as a wrapper around character literals, but has by now become a wrapper around arbitrary single characters. Besides updating the documentation, this change is a mechanical for i in $(git grep -Fl OUStringLiteral1); do sed -i -e s/OUStringLiteral1/OUStringChar/g "$i"; done Change-Id: I1b9eaa4b3fbc9025ce4a4bffea3db1c16188b76f Reviewed-on: https://gerrit.libreoffice.org/80892 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-14New loplugin:getstrStephan Bergmann
...to find matches of ... << s.getStr() (for the rtl string classes) that can be written as just ... << s Some notes: * The OUStringToOString(..., RTL_TEXTENCODING_UTF8) is left explicit in desktop/source/app/crashreport.cxx (even though that would also be done internally by the "<< OUString" operator) to clarify that these values are written out as UTF-8 (and not as what that operator << happens to use, which just also happens to be UTF-8). * OUSTRING_TO_CSTR (include/oox/helper/helper.hxx) is no longer used now. * Just don't bother to use osl_getThreadTextEncoding() in the SAL_WARN in lingucomponent/source/hyphenator/hyphen/hyphenimp.cxx. * The toUtf8() in the SAL_DEBUG in pyuno/source/module/pyuno_module.cxx can just go, too. Change-Id: I4602f0379ef816bff310f1e51b57c56b7e3f0136 Reviewed-on: https://gerrit.libreoffice.org/80762 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-12Use size_t for string lengthsStephan Bergmann
Change-Id: I5c31197b3b61f630b41e9ee4df08aade21a71f68 Reviewed-on: https://gerrit.libreoffice.org/80708 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-12Simplify some O(U)String methodsMike Kaganski
Change-Id: I020b7fef3c30cf6d5b161c33dab5bee6d2a6f91b Reviewed-on: https://gerrit.libreoffice.org/80713 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-10-11Revert "Use constexpr if in const char array ctors"Mike Kaganski
This reverts commit fbbbc7e3f9a62a80d41bcf9621cc098fd45b94c7. See discussion at https://gerrit.libreoffice.org/80637. Change-Id: Ie3e5c73a0bd727e226ffb84e813c5b90e0e288d4 Reviewed-on: https://gerrit.libreoffice.org/80664 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-10-11Use constexpr if in const char array ctorsMike Kaganski
Change-Id: I84237b0b20d5a5aefd7268f16a6254c83c320382 Reviewed-on: https://gerrit.libreoffice.org/80637 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-09-26Simplify external implementations of O(U)String::numberMike Kaganski
Change-Id: I2e1b217d43806dd0f64239978211d5b17fcf311c Reviewed-on: https://gerrit.libreoffice.org/79518 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-09-24support O(U)String::number() for fast string concatenationLuboš Luňák
When I did the fast string concatenation, I didn't add any support for number(), which simply returned a O(U)String, and so it did the extra allocation/deallocation, although that could be avoided. In order to support this, number() now returns a special temporary return type, similarly to O(U)StringConcat, which allows delaying the concatenation the same way. Also similarly, the change of the return type in some cases requires explicit cast to the actual string type. Usage of OString::getStr() is so extensive in the codebase that I actually added it to the helper class, after that it's only relatively few cases. Change-Id: Iba6e158010e1e458089698c426803052b6f46031 Reviewed-on: https://gerrit.libreoffice.org/78873 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-08-30new loplugin:noexceptmoveNoel Grandin
idea from mike kaganski look for places where we can mark move operators as noexcept, which makes some STL operations more efficient Change-Id: Id732b89d1fcadd5ceb0ea2b9d159fed06136330f Reviewed-on: https://gerrit.libreoffice.org/78251 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-19Fix typosAndrea Gelmini
Change-Id: I1b566ef38eaef3d6b20555e20b8353976fbdca5d Reviewed-on: https://gerrit.libreoffice.org/75927 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-03-22Fix some doxygen-generated documentation.Christophe JAILLET
Doxygen is misled by the "127." at the beginning of a sentence and converts it to "<ol><li>..." So it is erroneously rendered as: all ASCII characters are in the allowed range between 0 and 1. The ASCII string must be NULL-terminated. Change-Id: If36de7d4df668b5f9e9f6c7ea139552798e349d2 Reviewed-on: https://gerrit.libreoffice.org/69360 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2019-01-10o3tl::string_view -> std::string_view (in embedserv)Stephan Bergmann
Change-Id: I32bba8f45ff3b77084aa2d416126f96c051022f4 Reviewed-on: https://gerrit.libreoffice.org/66073 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-10Revert "tdf#42949 Fix IWYU warnings in include/rtl/*"Miklos Vajna
This partilally reverts commit 55ca35ab99fb1164cb2095384ed0937a533d9d3c, the removal of <utility> was not correct, std::move() still requires it. Change-Id: I1f905e332874b0aa72f537e37251f822258577d6 Reviewed-on: https://gerrit.libreoffice.org/66033 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-10o3tl::string_view -> std::string_view (in configmgr)Stephan Bergmann
Change-Id: I64131f59ce859a252baa9c84291d262bcb04fffd Reviewed-on: https://gerrit.libreoffice.org/66012 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-08Clean up LIBO_INTERNAL_ONLY uses of SAL_WARN_UNUSED_RESULTStephan Bergmann
Change-Id: I98b2d90c8345f07010f6defd82557188d5cd35c7 Reviewed-on: https://gerrit.libreoffice.org/64808 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_CXX14_CONSTEXPR is always true nowStephan Bergmann
...but for safety, leave the configure.ac check in for some longer. o3tl::array_view::max_size (include/o3tl/array_view.hxx) and o3tl::basic_string_view::max_size (include/o3tl/string_view.hxx) started to produce loplugin:staticmethods warnings, which I silenced by /not/ making the functions static. Those classes are meant to be temporary drop-in replacements for standard classes (std::span slated for C++20, prev. std::array_view; and std::basic_string_view, resp.), so should have the same behavior as their standard counterparts (and making the functions static would likely cause loplugin:staticaccess warnings at call sites). Change-Id: If21674dbf02886f453ca447544e37b184df5a25e Reviewed-on: https://gerrit.libreoffice.org/64768 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-08-22new loplugin:conststringfieldNoel Grandin
Look for const string fields which can be static, and mostly convert them to OUStringLiteral And add a getLength() method to OUStringLiteral to make the transition easier. Remove dead code in XclExpRoot::GenerateDefaultEncryptionData, default password is never empty. Change-Id: Iae75514d9dbb87289fd5b016222f640abe755091 Reviewed-on: https://gerrit.libreoffice.org/59204 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-08-08tdf#42949 Fix IWYU warnings in include/rtl/*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Iae997959a0ec2c9edb1c795533692ec4e579449f Reviewed-on: https://gerrit.libreoffice.org/57313 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-08-01add operator+=(OUStringBuffer) method to OUStringNoel Grandin
to reduce needless object creation and copying some more And fix what looks like a bug in CSS hex color parsing at line 609 in sw/../parcss1.cxx that has been there since commit 7b0b5cdfeed656b279bc32cd929630d5fc25878b "initial import" Change-Id: Ibad42b23721a56493bd1edcd7165e6104494a5c3 Reviewed-on: https://gerrit.libreoffice.org/58357 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-01-12More loplugin:cstylecast: salStephan Bergmann
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable loplugin:cstylecast for some more cases" plus solenv/clang-format/reformat-formatted-files Change-Id: I7d89b011464ba5d2dd12e04d5fc9f65cb4daebde
2017-11-11Avoid using O[U]StringConcat lvalues containing dangling refs to temporariesStephan Bergmann
...in code accidentally using auto like > auto const aURL = uri->getUriReference() + "/" > + INetURLObject::encode( > m_sEmbeddedName, INetURLObject::PART_FPATH, > INetURLObject::EncodeMechanism::All); > > uno::Reference<uno::XInterface> xDataSource(xDatabaseContext->getByName(aURL), uno::UNO_QUERY); in <https://gerrit.libreoffice.org/#/c/44569/1> "Properly construct vnd.sun.star.pkg URL" did (causing hard to debug test failures there). So make functions taking O[U]StringConcat take those by rvalue reference. Unfortunately, that also needed adaption of various functions that just forward their arguments. And some code in sc/qa/unit/ucalc_formula.cxx used CPPUNIT_ASSERT_EQUAL on OUStringConcat arguments in cases where that happened to actually compile (because the structure of the two OUStringConcats was identical), which needed adaption too (but which would arguably better use CPPUNIT_ASSERT_EQUAL_MESSAGE, anyway). Change-Id: I8994d932aaedb2a491c7c81c167e93379d4fb6e3 Reviewed-on: https://gerrit.libreoffice.org/44608 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-10-23loplugin:includeform: UNO API include filesStephan Bergmann
Change these back to consistently use the "..." form to include other UNO API include files, for the benefit of external users of this API. Change-Id: I9c9188e895eb3495e20a71ad44abfa2f6061fa94
2017-10-23overload std::hash for OUString and OStringNoel Grandin
no need to explicitly specify it anymore Change-Id: I6ad9259cce77201fdd75152533f5151aae83e9ec Reviewed-on: https://gerrit.libreoffice.org/43567 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-08-23tdf#111964: only trim XML whitespaceMike Kaganski
OUString::trim() uses rtl_uString_newTrim, which relies upon rtl_ImplIsWhitespace. The latter treats as whitespaces not only characters with values less than or equal to 32, but also Unicode General Punctuation area Space and some Control characters. Thus, using OUString::trim() is incorrect when the goal is to trim XML whitespace, which is defined as one of 0x09, 0x0A, 0x0D, 0x20. The comments for OUString::trim() and rtl_uString_newTrim are corrected to describe which characters are considered whitespace. A unit test included. Change-Id: I45a132be923a52dcd5a4c35aeecb53d423b49fec Reviewed-on: https://gerrit.libreoffice.org/41444 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
generated by cgit (git 2.34.1) at 2025-05-02 18:23:23 +0000