Change-Id: I389d8cb733a5ee24d3119a1ebac5a5b70daff04e
Reviewed-on: https://gerrit.libreoffice.org/31900Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I5c9b96e2ebd2ac98dfa610346c1da89fbf56e2d2
Reviewed-on: https://gerrit.libreoffice.org/31916Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I3a47c0e90e93050419326303c175cdc2adef6796
Reviewed-on: https://gerrit.libreoffice.org/31925Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

JunitTest_dbaccess_complex spuriously fails 1% of the time with:

1) testCloneMovesPlusDeletions(complex.dbaccess.RowSet)
java.lang.AssertionError: moving to the next record after |deleteRow| and clone moves failed
    at complex.dbaccess.RowSet.testCloneMovesPlusDeletions(RowSet.java:756)

The problem is that line RowSet.java:750 deleteRow() manages to delete
the last row in the set, because the positionRandom() is tricked to
position itself on the last row (which it tries not to do), becuase the
RowSet is currently positioned past-the-end on a deleted row and the
ORowSetBase::impl_getRowCount() is a lying bastard that adds 1 to the
result in this special case.

Funnily both the ORowSetBase::impl_getRowCount() and the test using
positionRandom() were added in CWS rowsetdel.  Yay for randomized
tests!

Change-Id: Ic8c7bfa190f6a5269604cf5b3c338f2d0b64205e

Change-Id: I9e822cfc1447fcd49c80c56df8ba37959555396a

See https://bugs.documentfoundation.org/attachment.cgi?id=129537 for bt
For the remind, it follows a replace of OSL_ENSURE by an assert, see:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=8228227168a7eb3ebf14629bec87f01536c23970

Change-Id: Id05eeb6e6669232e9b5cc2ef2989827fef3025d0
Reviewed-on: https://gerrit.libreoffice.org/31918Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>

Comparing colors to determine whether to set one in the result item set does
not work if the color previously was set before SaveValue() was called
unconditionally even for the "undetermined" color state. Actually we want to
know whether the user selected a color instead.

Change-Id: I508f791684ebd79ba4af9cb654f9aa0bb25bff5d

Rule for ctags: Sublime generated(or otherwise) ctags look like
sc/abc/xyz/tags. The present rule cannot look after tags which
are more than 1 directory deep. Hence this change.

Other rules added : Jetbrains Clion, cscope, sublime text specific

Change-Id: I1dbbe4904f3d15bbf198cd372591b464efb3896a
Reviewed-on: https://gerrit.libreoffice.org/31874Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jaskaran singh <jvsg1303@gmail.com>

CTFontCreatePathForGlyph() will return NULL for blank glyphs causing
CoreTextStyle::GetGlyphOutline() to return false which propagated as
error all the way to OutputDevice::GetTextOutlines() causing it to
needlessly enter into fallback code. Other implementations just return
true and an empty polygon here.

Change-Id: Ib20ebff00f7cb3aae22f1c6b4c3a0e9d7a429987
Reviewed-on: https://gerrit.libreoffice.org/31902Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>

sal_Bool and sal_uInt8 are typedefs for the same underlying type, so any use of
ORowSetValue with sal_Bool instead of bool, apparently intending to treat the
value as a boolean, actually treated it as a TINYINT.  (See e.g. recent
7b0c57b2 "some compilers don't like implicit
bool-to-ORowSetValue conversion".)

Now that there's no way to create a sal_uInt8 ORowSetValue, getUInt8 and the
m_uInt8 union member can probably go away, too.

Change-Id: Ia27554f76e7e9edce6410284b578064573e54fd3
Reviewed-on: https://gerrit.libreoffice.org/31909Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

Project: help  47ad5a2f2102740bda4cf02dcd73562da79f67a9

tdf#100836 "Starting the LibreOffice Software With Parameters" help update

rewritten cmdHelp in accordance with the attached document in bug tdf#100836

Change-Id: I6061dab2ed83a2be0653fbbd422e3193386d9d98
Reviewed-on: https://gerrit.libreoffice.org/31595Reviewed-by: Olivier Hallot <olivier.hallot@edx.srv.br>
Tested-by: Olivier Hallot <olivier.hallot@edx.srv.br>

Change-Id: I7ea9c1af7568ce37f29df14f8dc4345031c20eb8

Change-Id: Id42e9a2e2cfd7c95140411123e8702dfdb4054da
Reviewed-on: https://gerrit.libreoffice.org/31676Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

Also changed variable names for easier understanding of their meaning.

Change-Id: Iab558d7d1d9533f2a0c42e3d5f4acecead2e818e
Reviewed-on: https://gerrit.libreoffice.org/31807Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

Bah, the reverted change actually of course breaks the compilation, I
had missed that accidentally. More intrusive chnages are needed to
change css::uno::Reference to rtl::Reference, also in parameters to
constructors and other calls here.

This reverts commit 073f8cdb.

Change-Id: I2d0f9db9cef8dfbfe7d8a409eb09375c45b9e49f

Change-Id: I5bf8adf86da9d2e9c53341cdbc94aba05557abfc

To avoid this:

sc/source/core/tool/formulalogger.cxx:55:26: error: bad static variable causes crash on shutdown [loplugin:badstatics]
    static FormulaLogger aLogger;
    ~~~~~~~~~~~~~~~~~~~~~^~~~~~~
sc/inc/formulalogger.hxx:42:31: note: ... due to this member of 'FormulaLogger' [loplugin:badstatics]
    const ScFormulaCellGroup* mpLastGroup = nullptr;
    ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
sc/inc/formulacell.hxx:66:20: note: ... due to this member of 'ScFormulaCellGroup' [loplugin:badstatics]
    ScFormulaCell *mpTopCell;
    ~~~~~~~~~~~~~~~^~~~~~~~~
sc/inc/formulacell.hxx:114:21: note: ... due to this member of 'ScFormulaCell' [loplugin:badstatics]
    ScDocument*     pDocument;
    ~~~~~~~~~~~~~~~~^~~~~~~~~
sc/inc/document.hxx:312:27: note: ... due to this member of 'ScDocument' [loplugin:badstatics]
    VclPtr<SfxPrinter>    pPrinter;
    ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~

Change-Id: I533e45f655ca928a801188aa48ee818d89a962ac

Change-Id: Ia470ed848c5c27de1b0ae3fa89a59f6cb2ae38fe

Change-Id: I69f11aa5dd81834aa916a66437d8c091cdf245f3

Change-Id: I7ef42d66a0ffbbd8f2754bd4aba0e77659c9ae83

Change-Id: I6ab405e7e9a0c8ac3a323fd2484e334c500280ae

Change-Id: I45d7e14cef0058c4bfca4a3466e31d64e29bdfae

Change-Id: If538d5d5347f58e18869cab2b687af26a39a89eb

Change-Id: Ic8e00ab8961811044c26eb237f283617ddeb5cb6

Change-Id: I44a03f557d7a7aafeb17e5d662797203f975672f

Change-Id: If35981bce951dfab4a784d4cb54ac911249572ed

Change-Id: I4437484192016db7ce72614ae07c5a7d1bd9ec5b

Change-Id: I17146905c93162977effe9179c844ba691320d35

Format "%.2f" is not optimal for large or small values.
Format "%g" should be prefered.

Change-Id: I92899d80564b9000b1f3e049221c456f8e1176a9
Reviewed-on: https://gerrit.libreoffice.org/31445Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>

Despite being a 32-bit architecture, m68k has a basic
alignment of 16-bit for historic reasons. On m68k,
SAL_TYPES_ALIGNMENT8 is therefore equal to 2 and we
need to cover this case in the static asserts as well.

Change-Id: I4c756af25d57e5d49209697f6e678ef71a5845aa
Reviewed-on: https://gerrit.libreoffice.org/31878Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Remove useless class NameContainerImpl.

Change-Id: I3066abea69ed68d597aeecdd6b3ec7264f7ebe9c
Reviewed-on: https://gerrit.libreoffice.org/31830Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I6b224fa890dc96aada7140af27078da5e25c3ff8
Reviewed-on: https://gerrit.libreoffice.org/31898Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Ica62a13b19134030c6f0e2eeaf41df3c0f1294a4

Change-Id: Ib0106c3b88cf54e54aaf784bb526480a1c745a1f

This reverts commit cc020974.

Need to improve the solution here a little I think.

Change-Id: I02a3a46d2222b8bfe955eb17ca655d36d9155b48
Reviewed-on: https://gerrit.libreoffice.org/31867Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

Change-Id: I9759a0f21641b6f5ba5e456e5c45ac28238ca672
Reviewed-on: https://gerrit.libreoffice.org/31866Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

Change-Id: I76e9d317dabeefcdf53468a89f3a6130279993f3
Reviewed-on: https://gerrit.libreoffice.org/31865Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

Change-Id: Ie7127668aceade312c68ed3d7f3398fbaf5e8df7
Reviewed-on: https://gerrit.libreoffice.org/31864Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

Change-Id: I49c448c454f9bb820c3b9afa3825c58cb2dab978
Reviewed-on: https://gerrit.libreoffice.org/31863Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>