summaryrefslogtreecommitdiff
path: root/sal
AgeCommit message (Collapse)Author
2021-10-01Always use buffer on stackMike Kaganski
Change-Id: I39ed2485a67ec7a8b24ab90ea0d69a5982374334 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122860 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-01loplugin:nullptr (clang-cl)Stephan Bergmann
Change-Id: I47ac4ff7d82eb5732ad54e3b42c18c3665c83b82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122845 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-30-Werror,-Wformat (clang-cl)Stephan Bergmann
> sal/cppunittester/cppunittester.cxx(553,115): error: format specifies type 'unsigned int' but the argument has type 'ULONG64' (aka 'unsigned long long') [-Werror,-Wformat] > printf("\tat %s in %s: line: %lu: address: 0x%0X\n", pSymbol->Name, line->FileName, line->LineNumber, pSymbol->Address); > ~~~ ^~~~~~~~~~~~~~~~ > %0llX > sal/cppunittester/cppunittester.cxx(558,64): error: format specifies type 'unsigned int' but the argument has type 'ULONG64' (aka 'unsigned long long') [-Werror,-Wformat] > printf("\tat %s, address 0x%0X.\n", pSymbol->Name, pSymbol->Address); > ~~~ ^~~~~~~~~~~~~~~~ > %0llX > sal/cppunittester/cppunittester.cxx(576,50): error: format specifies type 'unsigned int' but the argument has type 'DWORD' (aka 'unsigned long') [-Werror,-Wformat] > printf("*** Exception 0x%x occurred ***\n\n",ex->ExceptionRecord->ExceptionCode); > ~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > %lx ...but where SYMBOL_INFO::Address is documented to be of type ULONG64, which in turn is documented to be a typedef for unsigned __int64, for which there is the MSVC-extension I64 format specifier Change-Id: Ibed1d3fa49ac6fd988174c6041071292fc66dd3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122872 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-30loplugin:sallogareas (clang-cl)Stephan Bergmann
Change-Id: I6a529d2eb737d284bf1e9c1857680c33581f5e0e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122846 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-30loplugin:external (clang-cl)Stephan Bergmann
Change-Id: I71be097d5051d39295f9f85d3e2329564388b4c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122851 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-30loplugin:cstylecast (clang-cl)Stephan Bergmann
Change-Id: I2c68832a23d80dbe208212ce36b14b21b5312f5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122850 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-30loplugin:unusedcapturedefault (clang-cl)Stephan Bergmann
Change-Id: Ib7b3bfb7a3162e032cf6c9bf7f19576434592a00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122849 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-30loplugin:includeform (clang-cl)Stephan Bergmann
Change-Id: Ia374fe0a7a0392e91821fecd1e6ee5917864d59c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122848 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-30loplugin:fakebool (clang-cl)Stephan Bergmann
Change-Id: I48ee1c1906ab06a487059128eb1eba0d6adb068f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122847 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-30Simplify comparisons in the loopMike Kaganski
Change-Id: I9963a527d2323f4df8c3b46c13f5b7993e22f163 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122855 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-09-30Avoid reversing the bufferMike Kaganski
Fill it in the correct order, starting from the middle Change-Id: Id35475e391d771d6c23252124a92825b24b55e0c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122853 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-29Use std::reverse instead of swapping in a loopMike Kaganski
Change-Id: Iee8966eeeaea461e34b5d22b80cb612dfaa57fe4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122750 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-29Simplify integer roundingMike Kaganski
Change-Id: I09ab406a8b7279801ce79b2f9c0a0011f6db05be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122749 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-20use clang-cl's -Zc:dllexportInlines- for clang-cl buildsLuboš Luňák
This is clang-cl's equivalent of -fvisibility-inlines-hidden, and it seems to be also sort of the equivalent of MSVC's -Zc:inline. So it saves build time and disk space. Clang docs say that this is binary compatible in only one direction, so our public C++ code shouldn't be using this, as external C++ code could try to use exported inlines that are no longer there. Change-Id: Ie6217808f8ee4a15344183abfc65038e1558d1b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122352 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-17Drop this unneeded indirectionMike Kaganski
Change-Id: I6b40642c7574a1863658854d206ed849517dbd0f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122130 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-13loplugin:simplifypointertoboolStephan Bergmann
Change-Id: I0186e8f1566ec2e4cec768cc18bdeba0bae182b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122033 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-10clang:optin.performance.Padding in salNoel Grandin
warning: Excessive padding in 'struct ImplTextEncodingData' (8 padding bytes, where 0 is optimal). warning: Excessive padding in 'struct ImplByteConvertData' (10 padding bytes, where 2 is optimal). warning: Excessive padding in 'struct ImplDBCSConvertData' (10 padding bytes, where 2 is optimal). warning: Excessive padding in 'struct DirectoryItem_Impl' (11 padding bytes, where 3 is optimal). Change-Id: Ia19f192099c305734256103c7cdc0f64e398b6af Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121902 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-07prepend #<num> to frames in unx backtracesLuboš Luňák
To make complex backtraces readable. Change-Id: I3a95d03d97c8e6d1aa7aeab37957d3b8441c3c90 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121724 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-06also cache addr2line resultsLuboš Luňák
Change-Id: Ib4351ba7a585ada3887f1cbeb5d676733250598b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121585 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-06group addr2line calls per binary for better performanceLuboš Luňák
Change-Id: Ifc655e4d5e2f3eb934b407e146ee564e3db0146b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121584 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-06improve sal::backtrace_get() by using addr2line in debug buildsLuboš Luňák
The backtrace_symbols() function provides backtraces that often miss many function names, try harder to resolve them, using addr2line is the best (only?) working solution I've found. Change-Id: Ieda06fc52735596e499fb7f9443cae13d134da5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121539 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-03log PATH length and content when complaining about itCaolán McNamara
Change-Id: I54495044f2bd487eb9315c7a974b9859b26235a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121588 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-09-01use a dummy clipboard when running unit testsNoel Grandin
so the multiple unit tests don't stomp on each other. This fixes a couple of things in my earlier attempt (*) actually set the env variable on Windows (*) don't use a global variable to test the env var, because that variable might be initialised BEFORE the env var is actually set Change-Id: Id43a1dd2fbd324691e0b6578c9026b8a523012e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121436 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-27Fix this FIXMEMike Kaganski
Change-Id: I4449d3c87adbcb94c721799aa6de1d615eb7041f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121070 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-08-27Use PSAPI functionality directlyStephan Bergmann
Dynamically trying to obtain the two PSAPI functions was apparently originally done because "This version can fail because PSAPI.DLL is not always part of NT 4 despite MSDN Libary 6.0a say so", according to the comment added with 961512bd9ae008fdd8ab5cdf1ba6b5d25ffb0429 "#94875# Added additional method (for NT4) to determine the module containing an address". (That comment was removed again in 515d2579d305a6127c6c194319a58eac62437e33 "Replace legacy dynamically- loaded functions with statically linked ones", which curiously left the dynamic loading of PSAPI.DLL in place there, though.) <https://docs.microsoft.com/en-us/windows/win32/api/psapi/nf-psapi-enumprocessmodules> states that the PSAPI functionality is available in "Kernel32.dll on Windows 7 and Windows Server 2008 R2; Psapi.dll (if PSAPI_VERSION=1) on Windows 7 and Windows Server 2008 R2; Psapi.dll on Windows Server 2008, Windows Vista, Windows Server 2003 and Windows XP". I do not find any mention of PSAPI_VERSION across our code base, so assume that PSAPI_VERSION=1 would be some legacy mode that we do not use, so with our baseline of Windows 7 (cf. README.md), relying on the PSAPI functionality being available without adding anything specific to gb_Library_use_system_win32_libs,sal should presumably be OK. Change-Id: I55ab29be2a3ee3984c6987e953819cb2e92e4aa8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121136 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-20New loplugin:unusedcapturedefaultStephan Bergmann
In sc/qa/unit/ucalc_formula.cxx, dropping the capture-default from the lExpectedinF lambda revealed that MSVC in C++17 mode (i.e., when building without --with-latest-c++) requires ROW_RANGE (a local const int variable from the enclosing TestFormula::testTdf97369) to be captured, even though all uses of that variable within the lambda body are constant expressions. That is still true at least for the latest Visual Studio 2019 version 16.11.1. (This is not an issue for the lExpectedinH and lExpectedinI lambdas a few lines further down, as they, in addition to using that ROW_RANGE, also use the local const double variables SHIFT1 and SHIFT2, whose uses are not constant expressions, so they are implicitly captured and loplugin:unusedcapturedefault does not suggest dropping those lambdas' capture-defaults in the first place.) Change-Id: Iee7efb485187cbe8eba6a2d470afca4993eb1816 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120693 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.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-08-02display stack trace on assert for windows jenkins buildsNoel Grandin
Change-Id: I1c23fda56c013eeeaf4ad1099c164d6d1146f68b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119851 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-31rtl::Static -> static localNoel Grandin
in a handful cases, like a map or a vector, we don't need init on demand at all, the default constructor can be laid out at compile time Change-Id: Ifa3188af7a65cd475ce0f603d15a8c26bcda7e6d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119710 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-29Fix typosAndrea Gelmini
Change-Id: I0430fe4bc3107b321e7b7ab84cbc3e6afff97372 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119647 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-07-28log access violation on windows tinderboxenNoel Grandin
where we currently have no good feedback when something goes wrong. Credit: Exception printing code written by msdn-whiteknight as seen at https://stackoverflow.com/questions/22467604/how-can-you-use-capturestackbacktrace-to-capture-the-exception-stack-not-the-ca Change-Id: I44c65b10c0b0151c3236521d62a824570d4cdccf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119561 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-27[API CHANGE] Drop obsolete osl_demultiplexSocketEvents et alStephan Bergmann
...which were deprecated in 0a126b4c661d65860fd2de92f8cc49bdb65a957c "Deprecate osl_demultiplexSocketEvents et al" towards LO 7.2 (and leave aborting stubs in place for backwards compatibility) Change-Id: Ice6032eb2f351af87dd56eecb002aa2a91e79373 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119560 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-23no need to allocate these static vars on demandNoel Grandin
the constructor can be laid out at compile/link time Change-Id: I377a537e15199ae81394d76ac662576280a25c25 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119362 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-21Use existing rtl_math_stringToDoubleStephan Bergmann
...like it is also already done in LineParser::readDouble in sdext/source/pdfimport/wrapper/wrapper.cxx (esp. since the code should be changed to use C++17 std::from_chars once that is available in all our baselines), reverting again the introduction of rtl_str_toDouble_WithLength in b1df9c67349cf4cc5be4128d797aefb87f50e38f "[API CHANGE] reduce cost of numeric conversion" Change-Id: If7e3a15649f80093d3407157412fd3deb3a38b12 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119318 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2021-07-21Use existing rtl_str_toInt64_WithLengthStephan Bergmann
...like it is also already done in LineParser::readInt32 in sdext/source/pdfimport/wrapper/wrapper.cxx (esp. since the code should be changed to use C++17 std::from_chars once that is available in all our baselines), reverting again the introduction of rtl_str_toInt32_WithLength in b1df9c67349cf4cc5be4128d797aefb87f50e38f "[API CHANGE] reduce cost of numeric conversion" Change-Id: I2789f8ec55c8d89150d1c68e6b353a1d2e1d1703 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119301 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2021-07-17[API CHANGE] reduce cost of numeric conversionNoel Grandin
on a hot path, since we already know the length of these strings. Which requires adding some new variants of our string conversion functions Change-Id: I1877f8f3c72934c07f14eec7e73bbe8d7b0f1808 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119065 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-09loplugin:indentation (clang-cl)Stephan Bergmann
Change-Id: Iae559ca8bee9650c01167a4d1b918e18cbf03c28 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118660 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-07-04Remove unused includesBaiXiaochun
Change-Id: I243d2998725f09ef533bd06865081d5c415f0d18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118282 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-07-02Purge out setNan from math.cxxBaiXiaochun
Change-Id: I95f9b37b564bb733f44899a8c6c1ea3c36e35694 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118196 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-06-29Simplify expresionBaiXiaochun
Reduce operation count by space / speed tradeoff. This expression is widely used in LO. Then needs to be fast. Change-Id: Ic88cf15d451ec95a8ad6da88cd9f601cf2876871 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117954 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2021-06-28loplugin:indentation improve checks for brace alignmentNoel Grandin
Change-Id: I333100fda7e181f68f36b03279b3fbb8cb768310 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117615 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-21tdf#135316 add small cache to rtl_bootstrap_args_openNoel Grandin
Filesystem access is quite expensive on Windows, so add a small cache for the filepath/name normalisation. This takes my load time from 19s to 18s Change-Id: I4410d066b8a4d2fd2eb746a5dd8f4ee763a8aa3e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117549 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-21remove now unnecessary commentNoel Grandin
Change-Id: I0297f299c42a5ce5485cdcdebfbd1597969c907c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117573 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-21simplify bootstrap_map (tdf#135316 related)Noel Grandin
No need for this indirection Change-Id: I87c90c9f1a7904f5a506acac631fe5a1f52f9190 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117521 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-18Use std::fesetround / std::nearbyint for half-to-even roundingMike Kaganski
C++ floating-point environment has thread storage duration, so std::fesetround call is thread-safe. std::nearbyint uses half-to-even rounding with FE_TONEAREST, as specified in ISO/IEC 9899:1999 F.3, and in Appendix to ANSI/IEEE 854. Change-Id: I26995842c30e2663b40af5b5314791c1328037d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117307 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-06-16Adapt implicit OString return value construction to C++23 P2266R1Stephan Bergmann
With the recent implementation of <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html> "P2266R1: Simpler implicit move" in Clang 13 trunk as <https://github.com/llvm/llvm-project/commit/bf20631782183cd19e0bb7219e908c2bbb01a75f> "[clang] Implement P2266 Simpler implicit move", a --with-latest-c++ build started to fail with > comphelper/source/xml/xmltools.cxx:103:20: error: no viable conversion from returned value of type 'char [39]' to function return type 'rtl::OString' > return str; > ^~~ [...] > include/rtl/string.hxx:277:5: note: candidate constructor [with T = char [39]] not viable: expects an lvalue for 1st argument > OString( T& value, typename libreoffice_internal::NonConstCharArrayDetector< T, libreoffice_internal::Dummy >::Type = libreoffice_internal::Dummy() ) > ^ [...] etc. Change-Id: If34f143a1855fdd7cd22ea3d7594f9381d50a7ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117336 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-06-02Make optional use of SetThreadDescription in osl_setThreadNameMike Kaganski
... so that thread name could appear in crash dumps, and be potentially available for logging on Windows 10 version 1607 and later. Change-Id: I176ca1fce57e0532a226f85836b3889a8ffb2984 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116462 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>