summaryrefslogtreecommitdiff
path: root/include/rtl/string.hxx
AgeCommit message (Collapse)Author
2020-12-20Make OStringLiteral ctor non-explicitStephan Bergmann
a5bdf3c606b562a2af3dd4e4162b734abb1cb24c "Make O[U]StringLiteral ctor explicit" made both the OStringLiteral and the OUStringLiteral ctor explicit, and 87707670c993794ab12b0fad0f048f11429269c2 "Make OUStringLiteral more useful" made (only) the OUStringLiteral ctor non-explicit again. There appears to be no good reason to keep the OStringLiteral ctor explict, and the current sitation lead to OUStringLiteral v = u"..."; being valid while OStringLiteral v = "..."; was not (and needed to be written as OStringLieral v("..."); instead). Change-Id: Ide26917efabb6eca31c19f64652ee87460e6dd1a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108056 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-10Catch inadvertent uses of OString(char) ctorStephan Bergmann
...similar to cbe944e323edb20f958bb46ea644de659b75382e "Catch inadvertent uses of OUString(sal_Unicode) ctor". The existing few places did mean to use that ctor after all, but this clean-up should come in handy when single-character instances of OString are replaced with OStringChar, which already rejects non- char arguments. Change-Id: I9dbd85b85c3be653c5e8084aed39689f8c6c3bb8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107557 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-21No need to make the OString(std::string_view) ctor explicitStephan Bergmann
<https://gerrit.libreoffice.org/c/core/+/101829> "Make std::u16string_view -> OUString construction explicit" (which has meanwhile been abandoned) had intended to make the OUString(std::u16string_view) ctor explicit, mostly not for the rationale given in the commit message there (it being "a rather expensive operation"), but rather to avoid anticipated ambiguity issues when introducing e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString"---but which has ultimately been added in a form that did not give rise to such ambiguity issues after all. 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String" had added the OString(std::string_view) ctor as explicit to match the corresponding explicit OUString(std::u16string_view) from the above <https://gerrit.libreoffice.org/c/core/+/101829>. But as that has now been abandoned, there is no good reason to keep this ctor explicit, either. Change-Id: I05742de5f3992ad5995149631bf8d55c8d448387 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103124 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-07Avoid dangling pData when constructing OUString from temporary OUStringLiteralStephan Bergmann
...afer 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String" Change-Id: I8afab29e9b7477c8a6c519b61d1fd6b3c21589e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102174 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-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-13loplugin:stringstatic also look for local staticsNoel Grandin
Add some API to O*StringLiteral, to make it easier to use in some places that were using O*String Change-Id: I1fb93bd47ac2065c9220d509aad3f4320326d99e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100270 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-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-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-24Fix typoAndrea Gelmini
Change-Id: I19d5ba10f5a9103bf96c19f8b3326e0bcc0a8686 Reviewed-on: https://gerrit.libreoffice.org/81463 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-10-24Introduce OStringCharStephan Bergmann
...similar to OUStringChar, to be used in string concatenation expressions. And enable the corresponding loplugin:stringadd check, and fix its findings. Change-Id: I35ebb2253ba82bda6c98ae6ebd2ad4f27cf9abf9 Reviewed-on: https://gerrit.libreoffice.org/81456 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-18Fix typoAndrea Gelmini
Change-Id: I9843620c378d7c6dbb5696255eb123e0bca9b4bf Reviewed-on: https://gerrit.libreoffice.org/75821 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
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-11-19Fix typosAndrea Gelmini
Change-Id: I0c966f517e337caa340526b48fa62b9910ce0a3e Reviewed-on: https://gerrit.libreoffice.org/63504 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2018-11-17Adapt to C++2a char_tStephan Bergmann
u8 literals incompatibly change their type (as implemented by recent Clang trunk) Change-Id: Ia4f7b91f5d86656a056303d2754981ab2093a739 Reviewed-on: https://gerrit.libreoffice.org/63494 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-05-23Fix typosAndrea Gelmini
Change-Id: Ibe94c7379a9389a0506c33666bf2bfb033f96f08 Reviewed-on: https://gerrit.libreoffice.org/54670 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jens Carl <j.carl43@gmx.de>
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-06-16Remove HAVE_CXX11_REF_QUALIFIER, always true nowStephan Bergmann
...after 579497164f6bddfeb14bb6b0f4b9cd3322af1803 "Bump GCC baseline to 4.8.1" Make this a fatal configuration error for now. The check should be removed completely after LO 6.0 branch-off. Change-Id: I70cf65d6b0eb7158008f28449794c66c1b775916 Reviewed-on: https://gerrit.libreoffice.org/38869 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-05-26create SAL_RETURNS_NONNULL annotationNoel Grandin
and apply it to some methods in OString and OUString Change-Id: I30e91f961b6d310799d3641f68b7ed54b3080f3a Reviewed-on: https://gerrit.libreoffice.org/38020 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-03-03Remove redundant 'inline' keywordStephan Bergmann
...from function definitions occurring within class definitions. Done with a rewriting Clang plugin (to be pushed later). Change-Id: I9c6f2818a57ccdb361548895a7743107cbacdff8 Reviewed-on: https://gerrit.libreoffice.org/34874 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-01-09New loplugin:externvar: salStephan Bergmann
Change-Id: Iefc33784f21e7a0b88c8d6308618926e38ab8554
2016-06-14sal: rename O[U]String parameterMichael Stahl
Callgrind tinderbox complains that "string" shadows some global, so let's try "rString" instead. Change-Id: I3973f23ef6e8ebf861d66012fede84cb8a685be8
2015-12-20sal: make OString/OUString immovable for MSVCMichael Stahl
Odd problem, with MSVC 2013 in CppunitTest_smoketest in sal/osl/w32/procimpl.cxx the read_environment calls std::stable_sort, which turns about 89 elements into the empty string since commit c9f6e12e7eb6a49389360626d206191147a174fb. No idea what the problem is but let's disable the move for now. Change-Id: I2912cd54a339bb6ab39922be516ea368a430f7c9 Reviewed-on: https://gerrit.libreoffice.org/20834 Reviewed-by: Noel Grandin <noelgrandin@gmail.com> Tested-by: Noel Grandin <noelgrandin@gmail.com>
2015-12-17OString/OUString: move constructors and operator=Noel Grandin
Change-Id: Icdc5f7137cca8360f116d5d4c7b0bf4a4c526e1d Reviewed-on: https://gerrit.libreoffice.org/20712 Reviewed-by: Noel Grandin <noelgrandin@gmail.com> Tested-by: Noel Grandin <noelgrandin@gmail.com>
2015-11-10loplugin:nullptr (automatic rewrite)Stephan Bergmann
Change-Id: I1bc6c87fcd6e5e96362623be94c59be216a3b2b8
2015-11-09Prevent += called on temporary O[U]String instancesStephan Bergmann
...found regression e31205f3ec1f941ab5a188bfde6329edf2acc55b "EditUndoRemoveChars::GetStr must return a reference" and dubious code 0e23f7b0839df68d277186b4df54ba391ac3406a "Lets assume this doesn't want to update m_pForcedPrefix->GetText() anyway" in addition to the apparent sillies directly fixed in this commit. Introduces HAVE_CXX11_REF_QUALIFIER. Change-Id: I564e98254fd53c1dd9b34193d7057c59721ee24c
2015-09-30Fix typosAndrea Gelmini
Change-Id: Id66432ef80fc2963fd2cbc6fad5d8e135e8975b0 Reviewed-on: https://gerrit.libreoffice.org/18956 Reviewed-by: Oliver Specht <oliver.specht@cib.de> Tested-by: Oliver Specht <oliver.specht@cib.de>
2015-09-10Add OString::startsWithIgnoreAsciiCaseStephan Bergmann
...analogous to the existing OUString::startsWihtIgnoreAsciiCase, to be used in the next commit Change-Id: Iad6989c16e1bda6b2b0a58e6c768f7852560bb00
2015-08-11new loplugin: defaultparamsNoel Grandin
find places where we do not need to be passing a parameter to a function, because that function has a default value which matches the value we are passing. Change-Id: I04d1fd6275204dd4925e6563282464f461123632
2015-07-12Rule out OString(std::nullptr_t)Stephan Bergmann
(This is no issue for OUString, as it has two ctors taking a single pointer argument, so passing a null pointer is ambiguous anyway.) Change-Id: I36f44b29eb84eb83e284fa080d706eabb4b485d5
generated by cgit (git 2.34.1) at 2025-01-18 09:00:08 +0000