Age | Commit message (Collapse) | Author |
|
Change-Id: I0457b81668e9427a3c8d6a4af93438b7fb2bb7ba
|
|
the compiler will do it for you
Change-Id: I770670e70a43664a87ce28b48fc822d891d8fb41
|
|
Change-Id: I9c66dd5331f422d8d6271157fece2b346d8b3756
|
|
Change-Id: I4d71640baa3c169fba069ca1328273fb78964541
|
|
Change-Id: Ib6f7463d97e9c835b2c9d64fa498efd546360645
|
|
Change-Id: I3f9742cafdcdce3302c925a2227da1f7839c80c3
|
|
and
coverity#1326880 FE: Test for floating point equality
coverity#1326881 FE: Test for floating point equality
coverity#1326882 FE: Test for floating point equality
coverity#1326883 FE: Test for floating point equality
coverity#1326884 FE: Test for floating point equality
coverity#1326885 FE: Test for floating point equality
coverity#1326886 FE: Test for floating point equality
coverity#1326887 FE: Test for floating point equality
coverity#1326888 FE: Test for floating point equality
Change-Id: I04a00035d541ea7a253a37d2a87c4dc407228346
|
|
FindBugs' FE.FE_FLOATING_POINT_EQUALITY is about double value inaccuracies, not
about NaN or negative zero (which is the topic of java.lang.Double.equals vs.
==).
Reuse existing qa.TestCaseOldAPI.approxEqual method, moved to util.utils.
Change-Id: I65f7bb1faf921e1c4035bb96aeff1eaf2cfb3153
|
|
Change-Id: I8a0b657942cbe3de559a6b115fad2229490f8985
|
|
Change-Id: I82350eab9ccfa331ada54a26f257d22bfcf6c8d8
|
|
Change-Id: Ib17eb78f4790880945a82ecff54d94528993bb22
|
|
Change-Id: If684189efc0ebba70c283f18ee8bd95b63be3557
|
|
Change-Id: I9cf946c24ad867ce5f2a2a476dbd1d9df473c1aa
|
|
Change-Id: I85d82f2c0a1c0ef8c123d9ba1a197e06cd76b92c
|
|
Change-Id: I76bb111d01cfbb72b707cedc3706d02922991dc7
|
|
Change-Id: I6923585dae30fb1fb2b0a7ce1a2d9d104b42ebc7
|
|
Change-Id: I250a03387dd714d844019b363e3be1f2e2ed6a20
|
|
Change-Id: I0623ecb8e9737e117f3db183d5aee7be5a405abf
|
|
and
coverity#1326561 Dereference before null check
Change-Id: I53d1e99ee05dd8d32a7fadc870344391647f3b9d
|
|
Change-Id: I0438dba50a9842e67ebeef872e27e6006871020f
|
|
Change-Id: Id0ed896b36293703c39d61cad6d74871ef16a806
|
|
Change-Id: I85a469a482ab0d7c1f897dd8f9fb809f1e55a7c2
|
|
Change-Id: I8a5418907570a53c2aaf88fc20458559b5bbf40e
|
|
Change-Id: I2f91ca0876e52a2480a2d6a3098f570b32e7d07a
|
|
Change-Id: Icca5032f27a25e3e67e821aa338c428687249ba2
|
|
Change-Id: I26d5a42cd52b442cc5ba9947b39508f4695adffa
|
|
Change-Id: I05e24d706679ae8e17fb382837e4edfe69e3b96d
|
|
Change-Id: I8013eb660ab0d2cd159a8a30277be6552089e428
|
|
Change-Id: I36ccf3fdf17e409c15e0e75ac4964d31781699a3
|
|
Change-Id: I0b0d71f86343b45fafdc8c2648f4667456e6bcd4
|
|
Change-Id: I31fdf38a9a62c4bf92286509c973fe4e7273b643
|
|
Change-Id: I5d6fb9c9bbec5b17e764677b34cfa4a9e2f4ceb6
|
|
Change-Id: I297f4495a64d0fb32c7a07841668006c4f3f5ed6
|
|
Change-Id: Ia6d9fbc90f526603f8dc1aff72d5cba9ed9a2d76
|
|
Change-Id: I72f70f8f0e01cdd59c2086244f328a007563adbd
|
|
Change-Id: I463ad43a31b870e6e67720089514337336e6015e
|
|
Change-Id: Ia5d4957b7b47ec103e2af0136ea8d40f21a0a4cf
|
|
Change-Id: I2973ab6cd021e4a36f11ae97d926faca77ea42be
|
|
Change-Id: I546d3a1be35c627b4fe36972620eefd4ee099e7f
|
|
Change-Id: Iceccb42d7e65abe012411fd61b3c69145d91f17a
|
|
Change-Id: I99aba91939af31837923d2e2e3ca4814178449dc
|
|
Change-Id: Ib0dcae05793927ecca4e8031e66b6ca1bf4721f7
|
|
Change-Id: I17c0f7e22e63823c16ebcdc1db1e4f618aad22a1
|
|
Change-Id: I88188482af59bb94f1869a1ad4fb3c72c71789b7
|
|
Seamonkey based address book driver is based on pre-compiled libraries
and is only used on Windows 32 bit. Remove it in favor of mork driver.
Given that Seamonkey based mozab driver also provides Outlook and
Outlook Express address book integration, that Windows-32-bit--only
feature is lost for now. If necessary, support for that feature could
be rewritten from scratch, in a way that would also work for Windows 64
bit.
Change-Id: Ie1c125e692598bda999767c328c9e2262a2b82af
Reviewed-on: https://gerrit.libreoffice.org/19560
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia266e5c1b66e35fdb4c6fdd5816f3b35d54ae1bd
|
|
...same as 8fb3808f555ad5b5c66cb894f9402647ca9ba341
Change-Id: If21d6bbf5f88b8ca5ed5387d98b2dd9c74f0e32c
|
|
...as null values are handled just fine by compare()
Change-Id: Ifd17b96187ad3d13be99b107d3c3fa47e51b586e
|
|
When the property type is e.g. a UNO sequence or struct type, !equals would
trivially be always true (as the UNO bridge creates fresh instances of such
value types on the fly), masking failures where the tested code didn't change
the property value at all.
And one such masked failure was
sw.CharacterStyle::com::sun::star::style::CharacterProperties in
JunitTest_sw_unoapi_1 not changing any of the CharLeft/Right/Bottom/TopBorder
properties, as SvxBorderLine::GuessLinesWidths
(editeng/source/items/borderline.cxx) appears to only work properly if nStyle is
DOUBLE, so work around that for now by explicitly setting that BorderLineStyle
in the ValueChanger for BorderLine2.
Change-Id: If9536822c5db04cbd01e6d760b5b63da04c4cf5b
|
|
...lcl_SetTableSeparators (sw/source/core/unocore/unotbl.cxx) when trying to
change the TableColumnSeparators property of
sw.SwXTextTable::com::sun::star::text::TextTable in JunitTest_sw_unoapi_4
Change-Id: I314e3f08eae0b1df6d5c60340e33f34477daf76e
|