aboutsummaryrefslogtreecommitdiff
path: root/source/nl
diff options
context:
space:
mode:
Diffstat (limited to 'source/nl')
-rw-r--r--source/nl/svtools/source/misc.po4
1 files changed, 2 insertions, 2 deletions
diff --git a/source/nl/svtools/source/misc.po b/source/nl/svtools/source/misc.po
index 31b76ca825f..e128a23e710 100644
--- a/source/nl/svtools/source/misc.po
+++ b/source/nl/svtools/source/misc.po
@@ -1484,9 +1484,9 @@ msgstr "Kasjmir (India)"
msgctxt ""
"langtab.src\n"
"STR_ARR_SVT_LANGUAGE_TABLE\n"
-"LANGUAGE_KAZAK\n"
+"LANGUAGE_KAZAKH\n"
"pairedlist.text"
-msgid "Kazak"
+msgid "Kazakh"
msgstr "Kazachstaans"
#: langtab.src
t'>feature/themesupport LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/sal/qa/rtl/strings/test_ostring_concat.cxx
AgeCommit message (Collapse)Author
2019-10-14Fix misuse of OStringLiteralStephan Bergmann
...(which got introduced with 9b5dad13b56bdde7c40970351af3da3a2c3c9350 "loplugin:stringadd look for unnecessary temporaries", and had reportedly broken CppunitTest_sc_ucalc on tml's Windows build by hitting the "strlen( str ) == N - 1" assert at include/rtl/string.hxx:1867), by introducing rtl::OStringView (and rtl::OUStringView, for consistency). Change-Id: I766b600274302ded66a6bffc91be189b20ed1ac3 Reviewed-on: https://gerrit.libreoffice.org/80778 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.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-27Avoid declaring function templates in namespace stdStephan Bergmann
...that don't even depend on program-defined types Change-Id: I102ce7e97280e7b80f8270ab3b7bbdc111d4d68c Reviewed-on: https://gerrit.libreoffice.org/78168 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-09-17New loplugin:externalStephan Bergmann
...warning about (for now only) functions and variables with external linkage that likely don't need it. The problems with moving entities into unnamed namespacs and breaking ADL (as alluded to in comments in compilerplugins/clang/external.cxx) are illustrated by the fact that while struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { struct S2: S1 { int f() { return 1; } }; int f(S2 s) { return s.f(); } } int main() { return f(N::S2()); } returns 1, both moving just the struct S2 into an nunnamed namespace, struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { namespace { struct S2: S1 { int f() { return 1; } }; } int f(S2 s) { return s.f(); } } int main() { return f(N::S2()); } as well as moving just the function f overload into an unnamed namespace, struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { struct S2: S1 { int f() { return 1; } }; namespace { int f(S2 s) { return s.f(); } } } int main() { return f(N::S2()); } would each change the program to return 0 instead. Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c Reviewed-on: https://gerrit.libreoffice.org/60539 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>