Whatever may or may not advance or put back nLineIdx, if there's
no progress at the end return false so we don't end up in an
endless loop with the next NextSym() starting at the same
position.
Change-Id: I7084fea073490c15b8ff5abb3781ac82cdccd6d6
Reviewed-on: https://gerrit.libreoffice.org/56029
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Regression from
commit 9a6527a98fb968b3fe6bc293ff7520a9480d43d0
CommitDate: Mon Jun 27 21:57:52 2016 +0200
stringToDouble() do not parse separator without digit as 0.0
Change-Id: I9d90aedc324ef0938297224297d89817e3fd1e90
Reviewed-on: https://gerrit.libreoffice.org/56028
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
and drop the sole use of WB_EARLYTOGGLE
Change-Id: I01e7d085eb3f9daf5a62a048178ab90defb4c5b1
Reviewed-on: https://gerrit.libreoffice.org/55983
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here
and a bit of fallout management.
Change-Id: I347377d7bb2a0cf8acda1ad28b5cc79bb954ab7d
Reviewed-on: https://gerrit.libreoffice.org/55726
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Many OpenType features are required features that are applied to certain
context determined by the layout engine, or should always be on. There
is no value in presenting these features to the user and they just
clutter the dialog for fonts that usually have many of such features
(e.g. Arabic or Indic fonts).
Change-Id: Idc3d7d3a9eb1c4f693ea6fdf9f26f0264b910f91
Reviewed-on: https://gerrit.libreoffice.org/55951
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Using SwTableFormatCmp in loops with SwTableLine::ChgFrameFormat, where
the latter may delete the old format of a frame, may invalidate the pOld
of a SwTableFormatCmp, and lead to use-after-free. To avoid this, let's
register SwTableFormatCmp as the old format writer listener.
Also use unique_ptr in vectors to simplify memory management.
Change-Id: I5ac93f4c3ae549b79a41220bda880386dd529c36
Reviewed-on: https://gerrit.libreoffice.org/55653
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Sources such as
http://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/
or https://en.wikipedia.org/wiki/Double-checked_locking suggest that
it wasn't possible to reliably do a portable double-checked initialization
before C++11. It may be true that for all platforms we support those
memory barriers are in fact not needed (which seems to be the assumption
behind OSL_DOUBLE_CHECKED_LOCKING_MEMORY_BARRIER being empty), and
looking at the generated assembly here on x86-64 seems to confirm that, but
in the worst case then this is a more chatty and standard way of writing
a no-op.
I don't want to use threadsafe statics or std::call_once() because
ScGlobal::Clear() does cleanup, which would be non-trivial to do with these,
and also some functions may not necessarily always force
creation of the singleton when touching the pointer, so it can't be easily
hidden behind a single function call.
The need to explicitly use load() with delete (thus preventing DELETEZ)
looks like a Clang bug to me.
Change-Id: Id3b0ef4b273ed25a5c154f90cde090ea1f9674fb
Reviewed-on: https://gerrit.libreoffice.org/55851
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
