summaryrefslogtreecommitdiff
path: root/include/rtl/stringutils.hxx
AgeCommit message (Collapse)Author
2024-10-14version COVERITY conditionalsCaolán McNamara
so there's a recheck on each major if they are still needed Change-Id: I351f731fe4eaec0ebf735147a9a168cccba3bca5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174883 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-09-08cid#1618764 Operands don't affect resultCaolán McNamara
Change-Id: I4faf81b030f3f7b704b25e4817f0ec6c07be4e79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172977 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-08-30Simplify a bitMike Kaganski
Change-Id: Icaf2e821984d9cdb16dbc4910b65b9b2b824435a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172583 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2023-12-04At least VS 2022 Preview 17.9.0 Preview 1.1 needs the fix tooStephan Bergmann
...from 3c6de7e20e35e37cbddd2d35e065525616deac00 "Fix build against VS 2022 17.7.5" Change-Id: I765db22aba2823e6d9a38282ac53e9ba5bcff092 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160309 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-10-18Extend /clr /std:c++20 char8_t workaround to old versions of VS 2022Stephan Bergmann
On IRC, pppregin now reported that she ran into the issue addressed by 3c6de7e20e35e37cbddd2d35e065525616deac00 "Fix build against VS 2022 17.7.5" when using (a presumably old version of) VS 2022. And <https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering> suggests that older versions of VS 2022 used _MSV_VER values 1930...1936, so cover those too here. Change-Id: Ifee80114c5cd39aeabc31907adafb03eb2f388e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158122 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-13At least VS 2022 Preview 17.8.0 Preview 3.0 needs the fix tooStephan Bergmann
...from 3c6de7e20e35e37cbddd2d35e065525616deac00 "Fix build against VS 2022 17.7.5" Change-Id: I36a7d02959c5ad04781c3d484966727c3283cbbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157932 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-12Fix build against VS 2022 17.7.5Stephan Bergmann
After af9c3ed6f748781f2a77e676ffe740992788969b "__cpp_char8_t is generally available now" (which Jenkins built successfully against some VS 2019 version), various people using at least exactly VS 2022 17.7.5 (--with-visual-studio=2022) started to experience issues like > include\rtl/stringutils.hxx(251): error C2065: 'char8_t': undeclared identifier when compiling e.g. cli_ure/source/climaker/climaker_app.cxx (i.e., in /clr mode). This is similar to the VS 2019 16.11.30 /clr issue discussed in the commit message of 5a40abc86b94c0be5b4a252c6ab5b0b0df6e520d "Drop some newly obsolete __cplusplus version checks", just that it apparently hits with a different set of VS versions. The fix here is similar to the fix there, just conditionally disable char8_t functionality for certain VS versions in /clr mode, and keep fingers crossed. Change-Id: I8c4ed2e3d290dc1c94f329d314407a56170564f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157866 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-11__cpp_char8_t is generally available nowStephan Bergmann
...after 1eef07805021b7ca26a1a8894809b6d995747ba1 "Bump baseline to C++20" Change-Id: I75509f3731357e0e3ae73c3774abd6e4070f605b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157806 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-07-13Restrict deleted catch-all O[U]StringChar ctor to arithmetic/enum typesStephan Bergmann
...which should still cover the issues that 7320d7a4a4dd0657f2d650a6f580ad399529f0f1 "OUStringChar must either take a sal_Unicode or an ASCII char" wanted to address, but without causing ambiguities where some unrelated type would unexpectedly be sucked into a conversion chain going through these ctors Change-Id: Iee3769dc6af5d7a1c8540a548bc2e10a89e637da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154391 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-05Fix typosAndrea Gelmini
Change-Id: Iaf248ec769b82bdb22ac0620a1dc31ea90823d4a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132535 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-03-31Fix -Werror=array-boundsStephan Bergmann
> In file included from svtools/source/svrtf/parrtf.cxx:28: > In member function ‘typename rtl::libreoffice_internal::ConstCharArrayDetector<T, rtl::OUStringBuffer&>::TypeUtf16 rtl::OUStringBuffer::operator=(T&) [with T = const rtl::OUStringChar_]’, > inlined from ‘virtual int SvRTFParser::GetNextToken_()’ at svtools/source/svrtf/parrtf.cxx:183:94: > include/rtl/ustrbuf.hxx:352:20: error: array subscript ‘unsigned int[0]’ is partly outside array bounds of ‘rtl::OUStringChar [1]’ {aka ‘const rtl::OUStringChar_ [1]’} [-Werror=array-bounds] > 352 | std::memcpy( > | ~~~~~~~~~~~^ > 353 | pData->buffer, > | ~~~~~~~~~~~~~~ > 354 | libreoffice_internal::ConstCharArrayDetector<T>::toPointer(literal), > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 355 | (n + 1) * sizeof (sal_Unicode)); //TODO: check for overflow > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > svtools/source/svrtf/parrtf.cxx: In member function ‘virtual int SvRTFParser::GetNextToken_()’: > svtools/source/svrtf/parrtf.cxx:183:94: note: object ‘<anonymous>’ of size 2 > 183 | aToken = OUStringChar( static_cast<sal_Unicode>(nTokenValue) ); > | ^ as seen with recent GCC 12 trunk in an --enable-optimized build. And add a test, even though it is relatively likely that the OUStringChar temporary is followed by null bytes, which would make the test happen to erroneously succeed. But at least tools like ASan or Valgrind could catch that. (For the corresponding OStringChar and OStringBuffer scenario, this issue does not arise, as OStringChar is not covered by ConstCharArrayDetector, so the correpsonding OStringBuffer assignment operator is OK memcpy'ing n+1 elements. There /are/ similar issues with string_view assignment operators for both O[U]StringBuffer, which will be addressed in a later commit.) Change-Id: Ia131d763aa5f8df45b9625f296408cc935df96ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132354 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
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-09-10cid#1466656 silence Logically dead codeCaolán McNamara
Change-Id: Id49181f71390ff6768ce6bc5734f8166e1a310b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102293 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@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-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>
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-21Actually choose the OUStringBuffer::append overload for UTF-16 string literalsStephan Bergmann
...instead of prefering the `const sal_Unicode *` overload Change-Id: Idc8fd0a2188e2b3399965f303faa2aae8dcd6fd0 Reviewed-on: https://gerrit.libreoffice.org/81251 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-19OUStringChar must either take a sal_Unicode or an ASCII charStephan Bergmann
...so forbid anything else, to avoid issues like the one described in 766cdd869d7d983e9e171a3eae0629cb9a0206ff "This code wants to add the numeric SvxRotateMode value". Some remaining places that apparently do want to convert some numeric value to sal_Unicode have been augmented with an explicit cast. Change-Id: I6200a84e250e697bc88694bd71142ca1d9a13651 Reviewed-on: https://gerrit.libreoffice.org/81132 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.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>
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-12-06Remove obsolete GCC version checksStephan Bergmann
...after <https://gerrit.libreoffice.org/63951> "Bump (Linux) GCC baseline to 7.0.0". (In some cases, those checks now need to check for __clang__, which was implicitly covered in the past by Clang consistently reporting to be GCC 4.2.1.) Change-Id: I860fef8c4ca41c22a7541f0fb2d34b37d1d69bed Reviewed-on: https://gerrit.libreoffice.org/63952 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-30Remove obsolete _MSC_VER checksStephan Bergmann
...after 206b8c4ae320d7d8614f21800d8f77fa29f8f5ff "On Windows, check for at least Visual Studio 2017 version 15.7" Change-Id: I38ee86e1649bbdc828a7e328f2dbbac0dc163c8a Reviewed-on: https://gerrit.libreoffice.org/64250 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-31coverity#1438473 silence Logically dead codeCaolán McNamara
Change-Id: I10b3821311515bb5148dab698f07d902c5c73100 Reviewed-on: https://gerrit.libreoffice.org/59822 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-08-21Make OUStringLiteral ctor actually constexprStephan Bergmann
...which had accidentally been broken with 87707670c993794ab12b0fad0f048f11429269c2 "Make OUStringLiteral more useful". (std::strlen unfortunately isn't constexpr, so need to use an explicit loop instead.) Change-Id: I9a820e2940b99a0c37124477810ef879d82c8325 Reviewed-on: https://gerrit.libreoffice.org/59344 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-02-02sal: MSVC: pragma warning: make more specific, remove obsoleteMike Kaganski
Change-Id: Ib7ad23257a966447d627b4f73698d9298790f759 Reviewed-on: https://gerrit.libreoffice.org/49042 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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-03-03Remove uses of SAL_CONSTEXPR in LIBO_INTERNAL_ONLYStephan Bergmann
Change-Id: I9a7dc7c83302b3361f056fcf6636bbba7672f15f Reviewed-on: https://gerrit.libreoffice.org/34840 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-08-30Let OUStringLiteral1 take its arg as ctor arg, not template argStephan Bergmann
...which makes it more flexible, can now also be used on non-const arguments. The drawback of the argument no longer being a compile-time constant is remedied by making the ctor constexpr. Change-Id: Ia4903a2cc86791fece92eac0cb8406b6659dd19d
2016-08-29Make OUStringLiteral1 a wrapper around UTF-16 instead of just ASCIIStephan Bergmann
...not merely an ASCII character Change-Id: Id2b381b35fe3a15574728ed973d60263dfef7249 Reviewed-on: https://gerrit.libreoffice.org/28446 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-08-29Support ConstCharArrayDetector also for UTF-16 arraysStephan Bergmann
The long-term benefit will be support of C++11 char16_t string literals (for cases of string literals with non-ASCII content) once we drop any compilers that don't support those yet. The short-term benefit is support for an improved OUStringLiteral1 that accepts any sal_Unicode value, not just ASCII ones (see next commit). Change-Id: I3f8f6697d7eb62b5176b7e812b5a5113c53b83a4 Reviewed-on: https://gerrit.libreoffice.org/28445 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-08-29OUString construction from OUStringLiteral1 must not be overruled by...Stephan Bergmann
...Except[Const]CharArrayDetector, under RTL_STRING_UNITTEST Change-Id: Ib185fb8406c4afcff1c854a2b74dae02a0ee2b3f Reviewed-on: https://gerrit.libreoffice.org/28444 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2015-11-13Adapt to clang-clStephan Bergmann
Change-Id: I2f79e52da2aa0ad3a37aac07a36dbe14dfe401a9
2015-07-22Apply special treatment of OUStringLiteral1 to MSVC 2015David Ostrovsky
Change-Id: I56e69fbdb555bb30cd88d75717d6f716c81ae237 Reviewed-on: https://gerrit.libreoffice.org/16804 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2015-06-25Revert "Revert "Generalize OUStringLiteral1""Stephan Bergmann
This reverts commit 5cba714b4d03ed54debf71534ad8c8edc383a01e, now including a workaround for <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53658> "internal compiler error -- segmentation fault." Change-Id: I31f6d9ddcb0b884134703df2b9dc1800ba0a84be
2015-06-24Revert "Generalize OUStringLiteral1"Stephan Bergmann
This reverts commit 4d4f3512db0cf0bf47c2ba1b39c3813842903ef7, at least "gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux)" fails with "include/rtl/stringutils.hxx:175:49: internal compiler error: Segmentation fault."
2015-06-24Generalize OUStringLiteral1Stephan Bergmann
...by making all places that accept a string literal via ConstCharArrayDetector also accept an OUStringLiteral1 via ConstCharArrayDetector (which required some tweaking of the ConstCharArrayDetector internals). That removes the need for special-purpose OUStringLiteral1 overloads, and will allow OUStringLiteral1 to be used in more places. Change-Id: I370de8480e02f8423cde5677dd38479b81bccdb2
2014-12-19No need for RTL_FAST_STRING in addition to LIBO_INTERNAL_ONLYStephan Bergmann
Change-Id: I5514898f588b21bafceefca95e3276826cb9a882
2014-12-18Introduce gb_*_set_external_codeStephan Bergmann
...to harmonize the mechanisms to not define LIBO_INTERNAL_ONLY for extension code and CppunitTest_odk_checkapi. (It also needs to revert any -Wundef, as the config_host/config_*.h files will not be included, so the HAVE_* macros will be undefined.) This obsoletes the need for RTL_DISABLE_FAST_STRING. Change-Id: If5eacba80c349efb90762aade8f2ea6d2db7e314
2014-11-19sal, cppuhelper headers a little more complete and self-containedMichael Stahl
All of them now build as-is (doing that is actually a pain because some are named the same as C library headers and clang looks first in the directory where the source file is in...). Change-Id: Ief6e245c8f49fcee678aebd46394c19e4cb47f51
2014-07-08'internal' is a keyword in current C++/CLITor Lillqvist
Using it as a namespace in our rtl string headers breaks compilation of cli_ure/source/climaker/climaker_emit.cxx (and other C++/CLI sources we might have that include rtl string headers). Rename it to 'libreoffice_internal'. Change-Id: Ieae68bd612b05d326d570945c1d08a54bf011852
2013-11-09fdo#65108 inter-module includes <> include/rtlNorbert Thiebaud
Change-Id: Ic90a365a237aa23846f97131146a5aa2c46b5fd2
2013-10-23fixincludeguards.sh: include - the restThomas Arnhold
Change-Id: If1ee11da444a7f96f2d8668b277540da0bb4dbe9
2013-04-24move URE headers to include/David Tardon
Change-Id: Ib48a12e902f2311c295b2007f08f44dee28f431d Reviewed-on: https://gerrit.libreoffice.org/3499 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>
generated by cgit (git 2.34.1) at 2025-03-25 10:42:35 +0000