Age | Commit message (Collapse) | Author |
|
Indeed, the cDecSeparator and cGroupSeparator require that the buffer
uses the proper character type, otherwise it won't be possible to use
Unicode separators in rtl_math_doubleToUString.
Change-Id: Id26bed72776475c1be5b092e3ffcff0e75ffe557
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151451
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
And change o3tl::iterateCodePoints to use sal_Int32 for its
second param, to integrate better with places where the parameter
comes from an UNO API, which cannot use std::size_t
Change-Id: I7b9dd2c9bc7f48e6c4a912f039f1b5dae7beae69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151421
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and unify with *ToAscii(Lower/Upper)Case
Change-Id: I06999b4f5f34abc8da2860b7f9e279608edb40dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151381
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
No need to use different temporary objects here
Change-Id: I1b47cae8b80adea5426c780003bddf68310a0060
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151380
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The plugin in its current form is probably not intending to find these cases.
But it happened to do so on macOS with libc++, where the std::basic_string ctors
taking a final defaulted Allocator argument are instead implemented by a pair of
overloaded ctors, one taking no Allocator at all (see
671d1c6cd14b28b5960ad56086299bd69533dfd8 "Adapt loplugin:unnecessarygetstr to
libc++").
But these changes here are useful regardless, so lets leave it at that.
Change-Id: I2776671e2953182bdcad36432951a75f82412ebb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151410
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...as requested in the comments of
<https://gerrit.libreoffice.org/c/core/+/151303> "a11y: Fix returning unpaired
surrogates when retrieving characters" (incl. the additional preAdjustIndex
parameter).
The type of the indexUtf16 parameter obviously needed to be adapted to
std::u16string_view's std::size_t. But there is no obvious best choice for the
type of the incrementCodePoints parameter (int? std::ssize_t?), so lets leave it
as sal_Int32.
For simplicity of avoiding a Library_o3tl, and to allow o3tl::iterateCodePoints
to be used in the implementation of rtl_uString_iterateCodePoints now,
o3tl::iterateCodePoints is provided as an inline function defined in the include
file.
Change-Id: I8280ca11d2a943bd2b7150a266807b358f321a72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151366
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia766db91030528c320a27a2d608bd0ec0a34f31b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151261
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
I want to know the symbol address we actually capture, since
we seem to getting duplicates in the output of SymFromAddr, I
want to know if the fault is in SymFromAddr, or the backtrace
capture call.
Change-Id: Iece9c204abb780ae6b67a11e6ba77db816351e8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151254
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Replace bulky and difficult-to-read template argument names with
clearer ones; remove excessive whitespaces; reorder to avoid forward
declarations (these are remnants from the refactor from macros to
templates, when I tried to keep the old structure as close to the
original as possible).
And also a small code simplification in doubleToString.
Change-Id: I901cfb86daf410e85269538f36ebb6b553a4be76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151125
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I5553138bfc8dd989e68b8bcc2be981746e8c1e84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150783
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I674655aa4bfe38675dd3c9d677a7d7c64b3eaac8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150478
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I4de8658c36c21fe07fa45f697cf3145c567a95c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150210
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I632607599060e625bda3dabee627ae1ddd6bd709
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150102
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
They use rtl_(u)str_valueOf(Float|Double), to fill the buffer, and
the latter use doubleToString, which creates an rtl_(u)String, copies
to the buffer, and releases the rtl_(u)String.
So instead just use the rtl_(u)String from rtl_math_doubleTo(U)String
directly. Even when the end result is not needed as O(U)String, this
would avoid an extra copy step. Also, this avoids separate
LIBO_INTERNAL_ONLY implementations.
Change-Id: Ib1d9ecebd7876dfff7dc758f89ee4c1536647a50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150150
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
both because it is more obvious to read, and it takes a string_view,
which is handy
Change-Id: Ic201cfa0434446f51436d23c33d3f1a919ed65be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150167
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I059f0324597a90aee01c95170a48ac5578f3caee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150037
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I184fa0e4e45662e0fac86076d1c8733a0465bb56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149978
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Iae784d3ae40cd237c768413c067a2067c608238d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149885
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
after my patch to merge the bufferadd loplugin into stringadd
Change-Id: I1658b960d44780f7d9c447246b1178cb70be5e66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149581
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ife02e6d2be3ebfbb08522ab0183ef4aa31a99e19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149415
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibfdc0e7e3af243f157d5d14e3fbe5ab204c0b8df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149140
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib39caf31b5d2fb06cc81cdeb14578794b35d8ed4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149120
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib98b507db9305ed20e3000f7f457a135a3bb3836
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148936
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I1c175753242783d83b5b1edc9b8b4cee2a5bd277
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148449
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
and
cid#1521510 Thread deadlock
annotation is getting a bit spamy
Change-Id: I3120562c0f7ca996f53d14965efe7af506be6d19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147935
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
... using a static thread_local variable, as already was used on Windows;
this replaces the non-Windows implementation based on pthread_setspecific
and friends.
Change-Id: Iba42510dea90a9e7d1983ba4af674667055f6dfc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147624
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Drop all the complexity of thread-local storage used only to make
EnumSystemLocalesW thread-safe. Just create a BCP47 tag, and use
GetLocaleInfoEx to get the codepage.
Also use locale name API in imp_getProcessLocale, and avoid the
deprecated LCID API.
Change-Id: I223564cc6d2cc919b0e5aadda1c12beee21e49f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147625
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...not the whole CppUnit::assetion_traits<T> classes (where applicable). That
avoids spelling out the (identical) equals member functions, and also leaves
around the less and lessEqual member functions, in case they want to be used
after all.
Change-Id: I18f8d6cff0353921ced4952b33a0c85ff8292923
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147165
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
which is both faster (because we don't need to allocate a pthread
condition) and simpler
Change-Id: I0a98432b5106c1c2b8e8ed97cbd779ef2b0c9e4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146996
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...so that the reported numbers add up if you specify both in SAL_LOG. Also
make the code look more symmetric.
Change-Id: I8b24dbe7cfa4d7aaebd2069db87a4e9d5fe6e3f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147017
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...executing on the TODO left by 4f0c70fb5554325e0cc2129741175bf07de22029 "Avoid
calling OString ctor with null pointer" in late 2020.
Change-Id: I3db6e2df61ca290948affc5e02ae74757441471d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146428
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_linux_s390 is
apparently dead and should thus be removed. However, that was the only bridge
implementation for 32-bit S390, which implies that support for the 32-bit S390
architecture as a whole is dead and should thus be removed.
Change-Id: I18b3b4fa11df4ce693107bad6bbea2fab1c19f26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146058
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
And not just Android. Hardcoded to return "/instdir" to match what is
in the emscripten_fs_image.
Change-Id: I26d4ec5e02ec9900e35ca47f1565a13ad2b723b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144849
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: Ia4a713c8a5ddda11e9802cbc317dde9ff48b8fd3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144026
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I15d31873a27ace544a76a64fe354edb97b144424
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144039
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Often a developer debugging a failing CppUnit test wants a core dump with the
place where an uncaught exception is thrown. So if the newly introduced
CPPUNIT_PROPAGATE_EXCEPTIONS environment variable is set (to any value), disable
all the protectors that would otherwise catch such exceptions (and just report
some limited information about them).
Change-Id: I3052f71c0787583c496279a6f5b35a0299c357b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143882
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iea433a2a7be9b62f04b57883dbefaf25586f21d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143616
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic350a924d3e5b58e8f1a60621edc701553d8cbab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143617
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I479b694cd1d02b39ad54deab8ba69b4eec64d7d4
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143489
Tested-by: Jenkins
|
|
Change-Id: I7e0e7f7a8bdc3fa92beca10935bb3c62d57f92fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143002
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 0d9613b77fc653c6144b5e4f0136c0536300c0db: As discussed in
the comments at
<https://gerrit.libreoffice.org/c/core/+/142344/2#message-c52fe7b2037e717525e89dd20a8f320142654ae0>
"TempFile: clear handle on close", that change was intended to reset *pHandle to
null in cases where osl_createTempFile returns an error and has already set
*pHandle. But that is obviously not what the change actually does, it rather
sets *pHandle to null in (only some of the) cases where osl_createTempFile
returns an error and has not modified *pHandle. Given that there may
potentially be clients that rely on osl_createTempFile not modifying the passed
in *pHandle when it returns an error, and given that the
sal/osl/unx/tempfile.cxx implementation of osl_createTempFile now inconsistently
set *pHandle to null in only some of the cases where it returns an error while
the sal/osl/w32/tempfile.cxx implementation of osl_createTempFile never sets
*pHandle to null when it returns an error, it appears best to just revert that
change.
Change-Id: Ia68353d04a488b024573ad03de0c5e5bd6e2a2c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142798
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...introduced with d8b60f77f389a248f98aa45592e6e1045baafbe1 "rtl_String->OString
in DirectoryItem_Impl".
(I came across this code with an upcoming loplugin:constmove that flags
suspicious uses of std::move involving const-qualified types.)
Change-Id: I3df2e6fb9dbf97adba6fbeda51d24cf025f5b207
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142565
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
After 6d6a143913603b040c10a5db83c2103557899011 "Address some of the sprintf in
vcl/source/fontsubset/cff.cxx", --with-latest-c++ builds that pick up a C++23
compiler that implements
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html> "P2266R1:
Simpler implicit move" started to fail with something like
> vcl/source/fontsubset/cff.cxx:2061:16: error: no viable conversion from returned value of type 'char[64]' to function return type 'OString'
> return aDefaultGlyphName;
> ^~~~~~~~~~~~~~~~~
[...]
> include/rtl/string.hxx:313:5: note: candidate constructor [with T = char[64]] not viable: expects an lvalue for 1st argument
> OString( T& value, typename libreoffice_internal::NonConstCharArrayDetector< T, libreoffice_internal::Dummy >::Type = libreoffice_internal::Dummy() )
> ^
etc. So I figured there should be something better than
433ab39b2175bdadb4916373cd2dc8e1aabc08a5 "Adapt implicit OString return value
construction to C++23 P2266R1" (which this commit reverts, modulo its conflicts
in comphelper/source/xml/xmltools.cxx and
sc/source/filter/xcl97/XclExpChangeTrack.cxx) to address the underlying issue in
a way that keeps code that works up to C++20 also working in C++23.
(The fix is only relevant for non-explicit constructors that involve
NonConstCharArrayDetector and non-const lvalue references, not for other
functions involving those. OUString has a similar constructor but which is
explicit, and OUStringBuffer doesn't have any similar constructors at all, so
this only affects OString and OStringBuffer constructors.)
Change-Id: I31cf16b9507899f5999243f8467dfa24bc94c5ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142455
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Current code does, malloc->memset, that's what calloc is for.
Change-Id: Ie3a4872249f78442b96f98c9dad9d7170afe784c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142345
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
If we close the file on error, then clear the handle we returned to
the caller so it doesn't try and close it again or do anything else
with it.
Change-Id: Idd054f92f4f3cbc3427896ec9795e588471292d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142344
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I668a8b4c6ce3458baa6975161be7ed0cb160968f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142331
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
And use an overloaded helper function with a better (?) unified name
to show that the result is not an O(U)String.
Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I65a4dad0aceb83f2449c86c438cb478937c8b90a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138229
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Regression after commit 92e835dbf00590c9c29509d2995cc7918a9bbb90
Author Kunal Pawar <hellokunalpawar@gmail.com>
Date Fri Feb 18 19:15:04 2022 +0530
tdf#98705 Replace GetCaseCorrectPathName with GetLongPathNameW
The fix tries to keep the performance improvement, and when the path
exists, it will only call GetLongPathNameW once. Anyway, for unclear
reason, this normalization only happens on long paths.
Change-Id: I1cf9a47dfc35046ec1b5eebbbcaca09edb1c471a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140516
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|