Age | Commit message (Collapse) | Author |
|
...in (somewhat contorted) test code
Change-Id: I247a30e580b3d458eb748a833100a662c9890d99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130991
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ief086996f94978d2ffd6879a6c3e5b0b2312dffe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130962
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
And disable the tests that try to use nullptr where it's not accepted.
Change-Id: I1cd031e371485fdd57e7691565376253a01049c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130938
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...that had been introduced with b5cb4935c268f12e63b61e035b455b0a59e67aa2 "Work
around undef conversion of large double to float" but should no longer be
necessary with
<https://github.com/llvm/llvm-project/commit/9e52c43090f8cd980167bbd2719878ae36bcf6b5>
"Treat the range of representable values of floating-point types as [-inf, +inf]
not as [-max, +max]" added towards Clang 9.
Thanks to Mike Kaganski for pointing me at this old code and at Richard Smith's
comment at
<https://cplusplusmusings.wordpress.com/2013/03/26/testing-libc-with-fsanitizeundefined/>.
Change-Id: I8ecf115fcf6b1ebf621cb4567f8d31ac9b10ef1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130531
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This header-only library is accurate in decimal representation of
doubles; provides API that allows to create custom representation
- so it's possible to use custom decimal separators and grouping.
This allows to unify all corner cases: integers, numbers close to
DBL_MAX, up-rounding to the next decade.
Note that Dragonbox creates the shortest decimal representation
of the number, that is unambiguously convertible back to the same
number; thus it may hide trailing digits that are unneeded for
such conversion.
The functional changes are minimal, and beneficial:
1. Rounding numbers close to DBL_MAX now takes into account the
bEraseTrailingDecZeros argument, as it should, allowing to have
"1.8E+308" for rounding DBL_MAX to 2 decimals without trailing
zeroes, instead of previous "1.80E+308".
2. Incorrect rounding is fixed in some cases, e.g. 9.9999999999999929
rounded to 10 previously using rtl_math_DecimalPlaces_Max.
3. Representing the number in the shortest way may change display
of some printed numbers. E.g., 5th greatest double is represented
as "1.797693134862315E+308" instead of a bit longer, but giving
the same double on roundtrip, "1.7976931348623149E+308". This would
generally look better for some numbers similar to the famous 0.1,
where users would likely expect more "round" representation where
it's unambiguous (but we still truncate to 15 significant decimals
anyway - so there's no point in pretending to provide exact digits
for actual binary representation).
These are reflected in the unit tests affected by the change.
Change-Id: I05e20274a30eec499593ee3e9ec070e1269232a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129948
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...as discussed in the mail sub-thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2022-February/088476.html>
"Also bump Linux Clang baseline to 12.0.1 (was: Bump --enable-compiler-plugins
Clang baseline?)", and clean up newly-obsolete __clang_major__ checks
Change-Id: Idacb9148b019c07e138277df3a085ba71c64a8e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130028
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I66feced8bed05c7859e36a6d2f746a7faf30c7a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126915
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Not only did it not work on Windows (witness the #ifdef), it would also fail at
least for Linux Flatpak builds (if they did make checks) where creating
<file:////tmpname> happens to succeed with E_None.
Change-Id: I9b82d500cb37fb80648407d2b4ade5ac85e97a60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126831
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I65d64002e5021c84af9ad7b8f5b693f04d79d4ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126797
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...which can be subsumed by their OUString vs. OUString counterparts now that
conversion from OUStringLiteral to OUString is cheap since
e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a
consteval'ed, static-refcound rtl_uString". (The only place that needed
adaption was the dubious use of temporary OUStringLiteral instances in
sal/qa/rtl/strings/test_oustring_stringliterals.cxx, which now caused "error:
conversion function from 'rtlunittest::OUStringLiteral<6>' to
'const rtlunittest::OUString' invokes a deleted function".)
Change-Id: I4f0f96efa2d5331ed5cbc9a29bdfdf3c0f4148a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125020
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...by making the OUString's pData point to the OUStringLiteral, instead of
copying the contained characters. This is one of the improvements that had not
been done as part of e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn
OUStringLiteral into a consteval'ed, static-refcound rtl_uString": "To keep
individual commits reasonably manageable, some consumers of OUStringLiteral in
rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now,
where they don't take advantage of OUStringLiteral's equivalence to rtl_uString,
but just keep extracting its contents and copy it elsewhere. In follow-up
commits, those consumers should be changed appropriately, making them treat
OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in
favor of an existing (and cheap to use now) OUString overload, etc." (Simply
dropping the OUStringLiteral overload was not possible in this case, though, as
that would have lead to ambiguities among the various OUString and
std::u16string_view overloads.)
The now-deleted OUStringLiteral rvalue reference overload means that some
existing assignments from ternary-operator OUStringLiteral<N> to OUString no
longer compile and had to be replaced with uses of std::u16string_view. Those
had not already been replaced in e6dfaf9f44f9939abc338c83b3024108431d0f69
because they happened to use OUStringLiteral instances of identical length N in
both arms of the ternary operator, so did not already start to fail to compile
back then.
Change-Id: I328e25b8324d045774e811d20a639f40d6a9a960
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124040
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia3e4dd8cad79b156d44eb03f1ae3d308204df2e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123691
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...compared to a full-blown O[U]String, for temporary objects holding an
O[U]StringConcat result that can then be used as a std::[u16]string_view.
It's instructive to see how some invocations of operator ==, operator !=, and
O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit
materialization of an O[U]String temporary, and how that expensive operation has
now been made explicit with the explicit O[U]StringConcatenation ctor.
(The additional operator == and operator != overloads are necessary because the
overloads taking two std::[u16]string_view parameters wouldn't even be found
here with ADL. And the OUString-related ones would cause ambiguities in at
least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with
RTL_STRING_UNITTEST, so have simply been disabled for that special test-code
case.)
Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I43474265a9b3e1d07394c5f7e429e081d67f2eda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122935
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I18b98f4be3212199004a1bb8fd8725fe71254ec4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122870
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I368123ce4ffdfb0e5c47e80cf4fece0c6ddc5f9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122854
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
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>
|
|
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>
|
|
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>
|
|
...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>
|
|
Change-Id: I333100fda7e181f68f36b03279b3fbb8cb768310
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117615
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 6727dc5d9414e77975b9fd765993c6e207f872f3.
We now don't support compiling using MinGW.
Change-Id: I0dee00780bfb4b7deceddd8cd30af03b7f7ed212
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116591
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I8c5e2d4c4687beab08876fe3e945d19a1629bc36
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116514
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...as inet_addr is deprecated (it does not allow to distinguish successful
return for "255.255.255.255" from -1 error return); and update tests
Change-Id: I605cb2ba18fe9bd11d2d68c8f1c94271c4503509
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116441
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...as inet_ntoa is potentially not thread-safe; and add a test
Change-Id: I9df945b006ba7194c3b1444c4886101c08339ad0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116425
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for
operator call arguments. (The "rather than copy, pass subView()" diagnostic is
already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly
for operator call arguments.)
(And many call sites don't even require an explicit [u16]string_view, esp. with
the recent ad48b2b02f83eed41fb1eb8d16de7e804156fcf1 "Optimized OString operator
+= overloads". Just some test code in sal/qa/ that explicitly tests the
O[U]String functionality had to be excluded.)
Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Id7c2db4abcf947c4efa0296df29feca2c36d3cf8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114692
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I656f06a74d9f0180ae460264563d6a935c7d2c60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114377
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
some parts of the OString seem to have fallen behind
its more popular sibling OUString.
Change-Id: Ie6d64c3005b2df5da49ba79d0c38282dd5057a23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114252
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Mostly automated rewrite
Change-Id: Ie020a083f898bc126b8fb039d4ecb2e687172da1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112965
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I4180f14aa633bf0f3f45178c1fd02b52b784f7e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111960
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
I didn't take clock resolution into account when created the test,
and it failed for me occasionally because the value was slightly
less than expected.
The typical system tick resolution is documented at
https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers
Change-Id: Ie48b10d15b14f9ac7d292a2cc9916bcbfff44b6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111946
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Debugging the test case from the latter bug report shows that indeed
the call to OleGetClipboard may fail first time, as jasonkres had
suspected in the former bug. So follow the suggestion in tdf#116983,
and retry the failing calls several times in case of failure.
Many thanks to Telesto for preparing a clear bug report with reliable
test case.
Co-authored-by: jasonkres
Change-Id: Ib3c497da830bc5faac586bcfe1eededa54bfa117
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111825
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I9eb6d99d883b44943ad69c2c28d4e55716dc34f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111673
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This is a blind attempt to fix a part of a failure reported on IRC:
/lode/dev/core/sal/qa/osl/file/osl_File.cxx:486: Assertion
Test name: osl_FileBase::getAbsoluteFileURL::getAbsoluteFileURL_001_1
equality assertion failed
- Expected: file:///var/folders/tj/jl7sh26124n4b94tm541m6xr0000gn/T//relative/file1
- Actual : file:///private/var/folders/tj/jl7sh26124n4b94tm541m6xr0000gn/T/relative/file1
- Assumption is wrong: ResultURL is not equal to expected URL
That "private/" in Expected might be because user's /var is a
symlink
to /private/var.
Change-Id: Ia5b95621dffdae7e0193aca4c3d12c86ed28dceb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110785
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
On platforms where char is signed,
> OUString aTmpName10(aTempDirectoryURL + "/\xE6\x9C\xAA\xE5\x91\xBD\xE5\x90\x8Dzhgb18030");
would have created, via addDataLiteral (include/rtl/stringconcat.hxx), an
OUString containing sign-extended char16_t counterparts of the \x char values
(\xE6 -> \uFFE6, etc.).
That caused CppunitTest_sal_osl
CPPUNIT_TEST_NAME=osl_FileBase::SystemPath_FileURL::getSystemPathFromFileURL_005
under an RTL_TEXTENCODING_ISO_8859_1 locale (e.g., LANG=C, as used by Fedora
when executing the %check part of libreoffice.spec) to fail on such signed-char
platforms (e.g., Linux x86_64) with
> [_RUN_____] osl_FileBase::SystemPath_FileURL::getSystemPathFromFileURL_005
> createTestDirectory failed: 21!
> sal/qa/osl/file/osl_File.cxx:267:osl_FileBase::SystemPath_FileURL::getSystemPathFromFileURL_005
> assertion failed
> - Expression: (osl::FileBase::E_None == nError) || (nError == osl::FileBase::E_NOENT)
> - In deleteTestDirectory function: remove Directory file:///tmp/?????????zhgb18030 -> result: 21
because FileURLToPath -> osl::detail::convertUrlToPathname ->
getSystemPathFromFileUrl<rtl::OString> -> decodeFromUtf8 -> convert (all
sal/osl/unx/file_url.cxx) would fail to convert those values beyond \u00FF to
RTL_TEXTENCODING_ISO_8859_1, ultimately returning osl_File_E_INVAL (i.e., 21).
(We could "fix" addDataLiteral in include/rtl/stringconcat.hxx, explicitly
converting from char to char16_t via unsigned char, but arguably that
concatenation construct should only be used with ASCII-only ordinary string
literals, similar to the restrictions for OUString construction from such
string literals.)
(Before 5a77636c9a638c86fd3de3afb6e88cf48f987b6a "WIN enable osl_File.cxx part
of CppUnitTest_sal_osl", that aTmpName10 was constructed as
> OUString aTmpName10(RTL_CONSTASCII_USTRINGPARAM( FILE_PREFIX TEST_PLATFORM TEST_PLATFORM_TEMP "/\xE6\x9C\xAA\xE5\x91\xBD\xE5\x90\x8Dzhgb18030" ));
but that would have caused similar issues, as RTL_CONSTASCII_USTRINGPARAM uses
RTL_TEXTENCODING_ASCII_US which converts non-ASCII chars to
RTL_TEXTENCODING_MS_1252 (see comment at aImplUSASCIIByteCvtData,
sal/textenc/textenc.cxx), which would have converted e.g. \x9C to \u2018, which
then would have failed to be converted to RTL_TEXTENCODING_ISO_8859_1. And that
use of RTL_CONSTASCII_USTRINGPARAM had violated the requirements as stated in
include/rtl/ustring.h anyway: "Each element of the referenced array must
represent an ASCII value in the range 0x00--0x7F.")
Whatever this crappy getSystemPathFromFileURL_005 actually wants to prove, it
happens to work now also for RTL_TEXTENCODING_ISO_8859_1 locales.
Change-Id: I044c4bd3aee4f7ea4f29737b6876cc55e4e6e436
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110714
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic0500db292d52a827f2139cd2cbbc0e8e4274dac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110701
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...detection of
OUString( const sal_Unicode * value, sal_Int32 length )
ctor. (On platforms where sal_Int32 is a typedef for int, an argument that
already is of type int will not be wrapped in an ImplicitCastExpr to the
sal_Int32 typedef.)
Change-Id: Ifc5456a62d42c1acad76ea949549dc24bd67201a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110654
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I0f61268b2027eb617b2312615ea544387af1b381
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110643
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I512cedcd46f829b97b62a57d90d5a4a81d024d66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110562
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...by re-enabling the code temporarily #if'ed-out in
a528392e71bc70136021be4e3d83732fccbb885e "Fixed/improved
loplugin:cppunitassertequals" (and which then triggers lots of other
lopglugin:cppunitassertequal CPPUNIT_ASSERT -> CPPUNIT_ASSERT_EQUAL warnings).
For two css::uno::Reference equality comparisons in cppu/qa/test_any.cxx, it
was more straightforward to rewrite them with an explicit call to operator ==
(which silences loplugin:cppunitassertequal) than to adapt them to
CPPUNIT_ASSERT_EQUAL's requirement for arguments of identical types.
In sc/qa/unit/ucalc_pivottable.cxx, ScDPItemData needs toString, which has been
implemented trivially for now, but might want to combine that with the
DEBUG_PIVOT_TABLE-only ScDPItemData::Dump.
Change-Id: Iae6d09cf69bd4e52fe4411bba9e50c48e696291c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110546
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This reverts commit 3ed9bba283a6a67864c0928186e277240be0d9ba. osl_Pos_Absolut
(include/osl/file.h) is part of the stable URE interface; it must not be changed.
Change-Id: I1f49923a9351e4be5aee39b10720d38b424feb9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110435
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
80b7949016fbc6addd54bf9f6cf300c756fd0f8a enabled a bunch of previously
disabled checks, but on m1 macs osl_File::open::open_004 fails the
assert, because it doesn't fail with E_ACCES, but with E_ROFS.
(probably nothing to do with apple silicon, but rather because of Big
Sur and using apfs as filesystem)
Change-Id: Ibd2168ba5fb9d859ea339713099c9bc8a799fcc7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110431
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: Ib8b306a27d25a34e784aeeb72708b0d5d1511f3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110394
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
Change-Id: If94a492fa8ef2167bb4c767802e8ea92405a59e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110337
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
A follow-up to commit 6e0fa7d4c7b45c98418c289d1d4715eb9eb133f7. Also enables
corresponding unit tests on Windows.
Change-Id: I250d1269e06c8ce11ebc0e4ea12171c5755aa42d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110273
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
and update the stringview loplugin to detect cases where we can
use these new methods.
Change-Id: I998efe02e35c8efcb3abfb4d7186165bbe6dfb2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110046
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...to also consider O[U]String ctors taking pointer and length
Change-Id: Iea5041634bfbf5054a1317701e30b56f72e940fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110025
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Revert the addition of the latter.
Change-Id: I93636a901cde401b0b7d923e052887f57dd58212
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109315
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Will be used in an upcoming change. Unit test included.
Change-Id: I777a755cab543ea277b84fb5ad021d0b91725764
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109264
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|