instead of re-implementing it ourselves.
Which lead to some changes in Xf::AttrList since the import process
wants to donate it's array to ScAttrArray.
Change-Id: I176148131fb5f163e25691ad690f63398ba1a556
Reviewed-on: https://gerrit.libreoffice.org/42205
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
[API CHANGE] publish all of LibreOfficeKitClass, and the
getDocumentType callback for the LibreOfficeKitDocumentClass
Change-Id: I4d6529a71b29a0014053b797c67255df53a6ccde
Reviewed-on: https://gerrit.libreoffice.org/42243
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
aarch64 (and mips) for that matter were not updated to adjust for clang
As clang now is default and only toolchain, also got rid of some now
unnecessary conditionals/variables.
additionally group the target-dependent vars in one block instead of
spreading them around in the file
Change-Id: Ie7fa19d14bf9fc7c05a9bea5345309f42f414db7
Reviewed-on: https://gerrit.libreoffice.org/42252
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
To fix the grand total calculation, we add another step.
This step loop through all row to find the min and max of each value.
These min and max are then used by the grand total.
Patch by Linagora
Change-Id: If3200840764d0ad9cb63231ac9f67b5d5ed197f1
Reviewed-on: https://gerrit.libreoffice.org/42042
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Both ODFF1.2 and the mathematical definition allow 0 as value(s).
Excel does not allow 0 as argument value(s), but IMHO this is to be
regarded as an aberration of Excel.
Also added tests for no arguments or negative arguments, which is not allowed by ODFF1.2.
Change-Id: I330206b6e817e0ec092fe19f713b044578da41d1
Reviewed-on: https://gerrit.libreoffice.org/42107
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
and simplify some of the calculations that needed to be changed.
Which resulted in one unit test needing to change by one pixel,
let's hope not an indication of a real problem.
Change-Id: Ie56434f35f4e58d21ee6f671392e93dc7542fca3
Reviewed-on: https://gerrit.libreoffice.org/42240
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
the context is requires to create translation templates (pot files,
using "make translate") to guarantee uniqueness of strings
Change-Id: Ie3df130f69c72ad468839235769f55286f4f3e48
using the same context as in datastreams.ui causes duplicate (identical)
strings in pot files, and some translation tools stumble over those
see also tdf#109258
Change-Id: I88b083f56a45123a6cf7521ceaaefa89f77e0477
... should be more platforms ... but be conservative.
U_PLATFORM_IMPLEMENTS_POSIX does not hold what it promises.
"The file and this data structure is not standardized. Don't rely on it. It
can go away without warning."
...
And since glibc 2.26 it's gone.
https://ssl.icu-project.org/trac/ticket/13329
Change-Id: I4c1f6130571f5d094cb35ce70e4d333763cee32a
There are apparently various places that want to check for a Unicode scalar
value rather than for a Unicode code point. Changed those uses of
rtl::isUnicodeCodePoint where that was obvious. (For changing
svtools/source/svrtf/svparser.cxx see 8e0fb74dc0
"Revert 'svtools: HTML import: don't put lone surrogates in OUString'".) Other
uses of rtl::isUnicodeCodePoint might also want to use rtl::isUnicodeScalarValue
instead.
As a side effect, this change also introduces rtl::isSurrogate, which is useful
in a few places as well.
Change-Id: I9245f4f98b83877145a4d392f0ddb7c5d824a535
...so it doesn't overflow for odd version numbers like
<https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER
&full-log=1505293801.994#53>'s 'clang --version' reportedly returning "Android
clang version 5.0.300080 (based on LLVM 5.0.300080) […]"
Change-Id: I7e3b3e0fa93d48fbbfa7a9b71e91776f976ed0da
of course this stuff is exposed through uno through
com::sun:⭐:awt::XSpinListener so VclEventId::SpinfieldFirst
and VclEventId::SpinfieldLast have to be retained
Change-Id: Icbf31cc8c62f2bc3bc0ccf966c0fd4f5c43dcf6b
Reviewed-on: https://gerrit.libreoffice.org/42231
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Multi-threading makes this difficult; have it print synchronously
where it is in the input when setting:
SAL_LOG="+INFO.sax.fastparser+WARN" SAX_DISABLE_THREADS=1
Change-Id: I8c77974acb2b4d4e273fc9c0f273c345d8feb2ff
OOXMLFastContextHandlerShape::sendShape() deletes the parent context's
ShapeTypeContext::mrTypeModel.
It looks like the sendShape() can't be delayed because writerfilter
wants to import the v:textbox content into a text frame.
Keep the shape alive until the end of the containing context.
Not sure if it's going to process the v:fill element properly,
but at lest valgrind is happy.
(probably regression from CWS writerfilter32bugfixes01)
Change-Id: Ifeab84751a1b20b2f272c4dd74b7097deb5eece0
...motivated by <https://gerrit.libreoffice.org/#/c/41565/2> adding dead code
at the end of a switch statement, after the last case's "break".
-Wunreachable-code appears to work well on Clang, while it appears to have no
effect on GCC.
Most of the affected places are apparently temporary/TODO/FIXME cases of
disabling code via "if (false)", which can be written with an extra set of
parentheses as "if ((false))" to silence -Wunreachable-code on Clang (which thus
needed loplugin:unnecessaryparen to be adapted accordingly). In some cases,
the controlling expression was more complex than just "false" and needed to be
rewritten by taking it out of the if statement to silence Clang.
One noteworthy case where the nature of the disabled code wasn't immediately
apparent:
Sep 12 16:59:58 <sberg> quikee, is that "if (false)" in
ScExponentialSmoothingDialog::ApplyOutput
(sc/source/ui/StatisticsDialogs/ExponentialSmoothingDialog.cxx) some work-in-
progress or dead code?
Sep 12 17:02:03 <quikee> sberg: WIP, but you can remove it
Sep 12 17:04:47 <sberg> quikee, I'll wrap the false in an extra set of
parentheses for now, to silence -Wunreachable-code (I wouldn't want to
remove it, as I have no idea whether I should then also remove the "Initial
value" comment preceding it)
Sep 12 17:07:29 <quikee> sberg: both are different ways to calculate the
"intital value"... so no
Another case where the nature of the dead code, following while (true) loops
without breaks, is unclear is sd/source/ui/remotecontrol/BluetoothServer.cxx,
where I added TODO markers to the workarounds that silence the warnings for now.
basic/source/sbx/sbxvalue.cxx had a variable of type double, of automatic
storage duration, and without an initalizer at the top of a switch statement.
Clang warning about it is arguably a false positive.
Apart from that, this didn't find any cases of genuinely dead code in the
existing code base.
Change-Id: Ib00b822c8efec94278c048783d5997b8ba86a94c
Reviewed-on: https://gerrit.libreoffice.org/42217
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
to disposed, the relevant variables (bDisposed and bInDispose) are written to
outside a synchronized block.
The equivalent C++ implementation in main/cppuhelper/source/implbase.cxx,
method WeakComponentImplHelperBase::dispose(), already does this.
Patch by: me
(cherry picked from commit 2d382cef5450cf1593322184649257d3666cbbd8)
Change-Id: I6c3e2ef78bc3c945245fe9fb7b6b713eb83710be
Reviewed-on: https://gerrit.libreoffice.org/42189
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Consider non-shortest forms, surrogates, and representations of values larger
than 0x10FFFF (which can even cover five or six bytes, for historical reasons)
as "invalid" (they used to be considered as "undefined" instead).
This is in response to fc670f637d "svtools: HTML
import: don't put lone surrogates in OUString" (which can now be reverted again
in a follow-up commit). My fear would have been that some places in the code
rely on the original, relaxed handling, but at least 'make check' still
succeeded for me.
Change-Id: I017e6c04ed3c577c3694b417167f853987a1d1ce
