Fixes CVE-2019-5435. It looks like this is not a problem on 32-bit
Windows because fortunately we don't use /LARGEADDRESSAWARE flag
to set IMAGE_FILE_LARGE_ADDRESS_AWARE... but on 32-bit Linux
the user-space VM is 3GB so an exploit might be possible.

Apparently there's no code in LO that uses the CURLU_URLENCODE flag.

The other one, CVE-2019-5436, doesn't matter because we disable tftp.

Change-Id: I0d4f087befa5a3c4fb21ec36761dad68932425d9
Reviewed-on: https://gerrit.libreoffice.org/72732
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

...which causes asserts to fire since <https://github.com/llvm/llvm-project/
commit/04323c24a1ac9464471331d9f6499d3cb95d1ccd> "Added an assertion to constant
evaluation enty points that prohibits …"

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

It doesn't correctly make a dependency on the .gch or anything
the .gch is made from, so there would be stale cache hits even
if anything included from the .gch changed. Disable CCACHE_DEPEND.
https://github.com/ccache/ccache/pull/427

Change-Id: I6929ff6ec1f1e50498033cdf95b56c94522166eb
Reviewed-on: https://gerrit.libreoffice.org/72704
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

With just -include a.hxx ccache checks only for presence of a.hxx.gch
and it doesn't search the path given by -I, so it didn't detect the usage
of the .gch and thus didn't include it in the checksum, possibly leading
to false positives. Icecream similarly doesn't search paths given by -I
and may fail to properly handle the .gch usage.

Change-Id: I40ba2d5089e77cd5e8da670c7e030f9e90ebc8ac
Reviewed-on: https://gerrit.libreoffice.org/72703
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

Enable the gtk3_kde5 and kde5 VCL plugins as discussed
in ESC all of 2019-05-02.
Also drop the "--disable-gtk3" switch so gtk3 is built
as well (which is enabled by default).

Change-Id: I65230255f8db6a7de992c6f5e9f9892a72436349
Reviewed-on: https://gerrit.libreoffice.org/71865
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>

There's pretty much the same code in CanvasHelper::fillTexturedPolyPolygon()
that has received various fixes over the time, but this code not, so
fix it as well.

Change-Id: I7293d4d67dff2d5276928bb3ab25adfb883ce3ca
Reviewed-on: https://gerrit.libreoffice.org/72700
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

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

See <https://gerrit.libreoffice.org/#/c/67754/3> for discussion, the
stability of this test has to be improved before it can be enabled
again.

Change-Id: Iae7d16c7a6c3659de132e2d64ca43865081b3c9b
Reviewed-on: https://gerrit.libreoffice.org/72724Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins

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

The problem here is that we never actually hit the maExportGraphics
cache in SvXMLGraphicHelper, even though we are passing the same image
down repeatedly.

There are two bugs here:

(1) BitmapEx::operator== does not return true if we instantiate 2
Graphic objects from the same XGraphic, so change it to use the more
expensive operator==. To mitigate the cost, move the expensive checks to
the bottom of the method.

(2) in order to use an object in std::unordered_map, the object must
implement an equality function and a hash function. If two objects are
equal THEY MUST have the same hash value. Using the Impl* as the hash
value does not satisfy that condition, so rather use the checksum, which
does.

After these fixes, the save time drops to less than a second.

Also make the checksum method look more like the operator== method,
and add a checksum calculation method for SVG data that more accurately
reflects the underlying SVG data.

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

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.

Change-Id: Ib7e1d0f7483aa8b5cab320278714f2d5f36fdbd9
Reviewed-on: https://gerrit.libreoffice.org/72534
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Change-Id: I7e45e30f8e316c49d1fe2311baf82a5729905a3c
Reviewed-on: https://gerrit.libreoffice.org/72702
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

by considering the axis direction.

Note: Legend name order in left/right position was fixed in
commit 40144617

Change-Id: Id5bd585a666c3bcf346af5317e9197e6460f932a
Reviewed-on: https://gerrit.libreoffice.org/72670Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>

and endnotes by creating redline data for their anchors, too.

Now footnote/endnote insertions are visible, and it's possible
to reject them.

Change-Id: I5cd3300c0d423b8c6803b7aeb848dcc103c3b565
Reviewed-on: https://gerrit.libreoffice.org/72680
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>

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

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

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

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

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

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

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

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

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

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

The problem with latest macOS versions is that creating a graphic
context with window (NSGraphicsContext graphicsContextWithWindow:)
only works when actually drawing and otherwise it returns null.
This caused problems before in AquaVrtualDevice, but we also use
this when creating a device backing storage. This interestingly
caused slowdowns and eventual crash, but the backtrace looked
very misterious as it didn't crash because of a nullptr, but
it halted all drawing commands and it crashed because of that.

This changes the graphic context with a bitmap context, as it
was already done in VirtualDevice and use that instead. The
problem with a bitmap context is that we need to handle HiDPI
scaling by ourselves now.

LayerHolder was extended to store the scaling information of the
layer (and its underlaying bitmap context) and provides methods
that get the size of the layer in pixels or in scaling independent
points (which is just size in pixels multiplied by the scaling
factor).

An known issue is that VirtualDevice also needs to take scaling
into account, which it currently doesn't, so the text is still
blurry on a HiDPI screen, but that was already true previously
and is something that will be done in a different change.

Change-Id: I8e10c518ecba285125746bd20525c4cb5ca67279
Reviewed-on: https://gerrit.libreoffice.org/72663
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

This adds the ability to define the spinbox orientation that has
decrease and increase buttons on the right side and can be changed
by adding "orientation="edit-decrease-increase" to the Spinbox
"Entire" part in the widget definition.

Change-Id: I3601a987a4abb8d998e9cd2d8973d794d3d66f9b
Reviewed-on: https://gerrit.libreoffice.org/72662
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

This is similar to e8d5b8be (tdf#113714
vcl menu bar window: avoid flicker, 2019-05-20), except that was for the
menu bar window, and this is for the floating window opening from that
one.

Change-Id: Ib24f4999ad3e8cbbecc058368e9d112e106e9178
Reviewed-on: https://gerrit.libreoffice.org/72688Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins

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

Change-Id: I5987fcc04396e4e22640d6b09b52fa7b08460369
Reviewed-on: https://gerrit.libreoffice.org/72687Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins

Since the guard is only cleared optionally, most probably the code after
the conditional block is expected to be guarded until the second clear.

Change-Id: I913cb4bff42140da605a6f45414bece419f4a4c8
Reviewed-on: https://gerrit.libreoffice.org/72689
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

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

Revert the commit caused this regression:
0fc41c53

The original issue does not come back with
reverting this commit.

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

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

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

by sending the notifications to the parent windows as well

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

A threadpool controls a number of threads that execute a number
of thread *tasks* from a queue. The API even says they are tasks.
So it's damn confusing when ZipPackageStream::saveChild()
claims to limit the number of threads to 4x the maximum number
of threads. It limits the number of queued thread tasks.

Change-Id: I317497f27a82d92a7c8566b14aaeae73a4ffef1f
Reviewed-on: https://gerrit.libreoffice.org/72677
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

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

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

Windows (by default) and gtk3 paints its own background, but e.g. the
Linux gen backend does not; so make sure that we not only copy from the
buffer, but also initialize it.

This restores the gradient background of the main menu with the Linux
gen backend.

Change-Id: I5ce8cc734f64bc1d57d343caf22071e6aa63a69f
Reviewed-on: https://gerrit.libreoffice.org/72676
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

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