Change-Id: I92f60e717cd2a0695c8b86b103076d26c0c22cef

user config now needs it to collect user's private GPG keys

Change-Id: Ia4ad4133b621160cf37281750cafa9f3c5c3c231
Reviewed-on: https://gerrit.libreoffice.org/45562Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Change-Id: I53a967ab6ad5a6ed89dc807120dd1db540b26a92
Reviewed-on: https://gerrit.libreoffice.org/45894Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

Change-Id: I6242f6028daaa0eb4d14134658e2eb50fd8f8275
Reviewed-on: https://gerrit.libreoffice.org/45932Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

Change-Id: I853e2d6ec2e55c78894a9942aa201763a57fe195
Reviewed-on: https://gerrit.libreoffice.org/45900Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>

Change-Id: I924713f360a41fa5b269468fdf771df6a50df44b
Reviewed-on: https://gerrit.libreoffice.org/45923Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

Change-Id: I35c34d427cc5440994fc16ed7e4d307bc95bc533
Reviewed-on: https://gerrit.libreoffice.org/45817Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Gülşah Köse <gulsah.1004@gmail.com>

At least recent libc++ has a std::string ctor overload without a (defaulted)
Allocator argument (which otherwise causes creation of a temporary Allocator
object and thus a ExprWithCleanups), so in C++17 mode (i.e., with no implicit
move CXXConstructExpr -> MaterializeTemporaryExpr -> CXXBindTemporaryExpr chain
in the way) CellInfo::toString (sw/source/filter/ww8/WW8TableInfo.cxx) has a
ReturnStmt of just

> ReturnStmt
> `-ImplicitCastExpr 'std::string':'class std::__1::basic_string<char>' <ConstructorConversion>
>   `-CXXConstructExpr 'std::string':'class std::__1::basic_string<char>' 'void (const char *)'
>     `-ImplicitCastExpr 'const char *' <NoOp>
>       `-ImplicitCastExpr 'char *' <ArrayToPointerDecay>
>         `-DeclRefExpr 'char [256]' lvalue Var 'sBuffer' 'char [256]'

that erroneously triggered loplugin:passstuffbyref.

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

Change-Id: I7b09fb91f3d0d77851a84a015fc3e2fedc0153c7

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

... with cppu::BaseMutex, because a member cannot ensure the life
cycle guarantees expected by WeakComponentImplHelper.

Change-Id: Iaa10c699abf69882d917487740db241ba1455e1c

Take a drawing rectangle in draw and cut and paste as bitmap to writer.  The
hairline border along the very right/bottom edge of the bitmap appear missing.

fallback to default handlers which can distort the hairline to be visible

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

Change-Id: I434eebac395bbb53a0c586a43568f64ec3fb8448

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

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

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

The classes ODatabaseDocument, ODatabaseModelImpl and
ODatabaseSource share a single mutex declared as
ModelDependentComponent::m_aMutex.

Commit 403eefe8 introduced
a new deadlock here: in case Yield is called, such as
when the user doesn't have a JRE and a dialog requesting
to install one is displayed, the SolarMutex is released
but the ModelDependentComponent mutex is still locked;
now another thread (such as the AsyncEventNotifier)
can lock the SolarMutex but not the other mutex,
while the main thread can't lock the SolarMutex again.

So the SolarMutex must be on the one hand be
locked before the other mutex, to ensure the behaviour
is the same whether the thread already holds it or not,
and locked after the other mutex, to prevent the Yield deadlock.

One option would be to revisit fca62934
and add back the SfxLibraryContainer mutex, but the code
there is a mess, naively assuming that locking the mutex on
UNO entry points is sufficient, taking no care to temporarily
release it while calling other UNO components or event listeners;
since there's about 5kLOC in all the related classes it
would take some time to rewrite all that.

An easier fix is to remove the ModelDependentComponent::m_aMutex.

This patch removes all locking of that m_aMutex, but it still
exists as a non-shared Mutex because it's needed for the
WeakComponentImplHelper base classes, which shouldn't cause issues.

Change-Id: I94aaa0ae8698188c98633c638100a309b20976cc
Reviewed-on: https://gerrit.libreoffice.org/45914Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Change-Id: I5c21f95f763f1491cc68087ecec0909493fd7f63

Change-Id: Ie3931deb3b39160a6f46dd744ea5b098904d55d2

Change-Id: Icf9309addd971c5d98d4057dba6619c4eef9ea6d

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

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

...in various places, which is gone by default at least from recent libc++ in
C++17 mode.  So bring it back there for now, until Boost is fixed.

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

CXXFLAGS_CXX11 is for the compiler used to compile LO proper.  The plugin needs
to be compiled in a way compatible with compiling Clang, and the compiler and
any relevant flags can be controlled with COMPILER_PLUGINS_CXX.  (And at least
on macOS when compiling LO against a locally-built recent Clang trunk,
CXXFLAGS_CXX11 will now contain -std=gnu++17, but COMPILER_PLUGINS_CXX can still
point at Apple's Xcode clang++, which does not understand -std=gnu++17.)

Also, if COMPILER_PLUGINS_CXX is not set, simply default it to g++ instead of
trying to construct an acceptable CLANGCXX value from CXX (which would be
Clang).  (The problem with using Clang without CXXFLAGS_CXX11 is that Clang,
unlike GCC, typically defaults to C++03, but building compilerplugins requires
C++11 at least.  That would cause e.g. the Gerrit/Jenkins linux_clang_dbgutil_64
builds to fail---but which also needs COMPILER_PLUGINS_CXX to be explicitly set
to "g++ -std=c++11" as GCC on those machines is still 4.8.5 defaulting to
C++03.)

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

Change-Id: Ie12a39dce136c78e786f805740d855a5d191082e
Reviewed-on: https://gerrit.libreoffice.org/45913Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

As it turns out, gpgme works perfectly fine w/o glib (though it
really wants it configured out of the box)

This reverts commit daee5fc5.

Change-Id: I60002bf3b524696eeae397a26c280a67dcdbfd7a
Reviewed-on: https://gerrit.libreoffice.org/45908Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

We will create the font in ExTextOutRenderer for glyphs that
are expected to be sideway in vertical writing, so we can reset
the font escapement and orientation if @font ( windows notation
of fonts for CJK vertical writing. ) isn't available. That will
keep the font consistent with @fonts for those glyphs expected
to be upright in vertical writing.
Note that it is necessary to change text alignment of DC when
such font is used.

Change-Id: I1a4a6e8aa232119dd136beeb6c19505d7980a534
Reviewed-on: https://gerrit.libreoffice.org/45609Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Hung <marklh9@gmail.com>

Change-Id: I11e9cb607c36112f19f7cace1d8c5b7559ebf2a1
Reviewed-on: https://gerrit.libreoffice.org/45423Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>

(as std::mem_fun is gone by default at least from recent libc++ in C++17 mode)

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

Change-Id: I391448361b5cda729904661a7c5c3b33288b7417

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

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

of raw numbers

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

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

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

Change-Id: Ib0efc84ad2cedc1a149fa57996bc0481bd64591b

Change-Id: I816b15b6795b4946b1bfed0d1f6d103a6a1aba4f

Which effectively is what GetObject() internally also does to
determine whether to set an error, so resetting an error here is
moot (or might even hide a nested error?).

Change-Id: I8736d16e386d1833126965538f96aaa1fd73dfd6

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

(as std::mem_fun is gone by default at least from recent libc++ in C++17 mode)

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