V560 A part of conditional expression is always false:
     nY == nStartRow.

Change-Id: I2d1a809400d48889780ce320be740648f8d9b97f
Reviewed-on: https://gerrit.libreoffice.org/67541
Tested-by: Jenkins
Reviewed-by: Marco Cecchetti <mrcekets@gmail.com>

...or else mapException would extract garbage from the fake
exception->exceptionType std::type_info* when catching via
cppu::getCaughtException the rethrown exception thrown via
std::rethrow_exception in Test::testgetCaughtException in
cppuhelper/qa/misc/test_misc.cxx.

6ddecf61 "fillUnoException not working on
std::rethrow_exception exceptions" had adapted the other relevant
bridges/source/cpp_uno/gcc3_*/ cases but missed the gcc3_linux_aarch64 one.

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

The bugdoc has 3 shapes in the "outer" circle which have a position
where either x or y is not 0. But these are defined using constraints
talking about the right or bottom edge of the shape.

Map that to top/left, given that we already know the shape size.

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

Change-Id: Id432035aba9ea443a1f4afcd54e39a8f3b0939cf
Reviewed-on: https://gerrit.libreoffice.org/67543
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

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

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

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

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

Since it is now possible to use C++14, it's time to replace
the temporary solution with the standard one

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

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

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

rather than have version specific behaviour

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

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

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

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

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

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

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

* Update helpcontent2 from branch 'master'
  - Fix "Error: Duplicated entry. ID = par_id3146919"
    
    ...after 00c5a418955574905aed5137c43ce2219b50e6f9 "Minor color and padding
    tweaks; some styling for TOC"
    
    Change-Id: I4340e2e52a5cbd7627364157aeb9eec17bc96cb4
    

Change-Id: I3ab1f7a5ec55d3f7fd8886d3578a9437f4ce03c1
Reviewed-on: https://gerrit.libreoffice.org/67522
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

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

* Update helpcontent2 from branch 'master'
  - Minor color and padding tweaks; some styling for TOC
    
    Just to fix the most egregious issues in content paragraphs.
    Some day I will actually have the energy to systematize
    everything into a cohesive set of spacing and padding values.
    
    Change-Id: I6d5d36e96d9c9a133d61b233413ebd17d8189d33
    

* Update helpcontent2 from branch 'master'
  - tdf#107930 - Help needs to be corrected and amended for Recalculation
    
    changed test in 06080000.xhp
    
    Change-Id: I4cc8a0a04517306e5196aa79c607e624b488a56f
    Reviewed-on: https://gerrit.libreoffice.org/67518
    Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
    

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

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

of an embedded XLSX OLE object, instead of showing
always the first sheet.

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

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

The markup is:

<dgm:if name="Name6" axis="ch ch" ptType="node node" st="1 1" cnt="1 0" func="cnt" op="gte" val="1">

Where PowerPoint evaluated the condition to true, but Impress evaluated
to false. This means that the undocumented relation between the child
lists is "OR" (not "AND").

Also, our code assumed that "node" has to be a data node (not
presentation node), but it seems the only way this condition can be true
if presentation children is also counted. (The presentation node in
question is not a presentation of anything.)

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

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

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

...which happens when GetParent()->GetOutputSizePixel().Width() is zero (as
seen, e.g., during JunitTest_forms_unoapi_2).  It is assigned to sal_uInt16 nX
further down, which then causes failure with Clang's -fsanitize=implicit-signed-
integer-truncation.  And when the parent size is apparently too small (zero)
there is probably no value in operating with a value less than zero here---there
won't be a reasonable layout of controls anyway.

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

regression from commit
    commit 1b7bcaa7
    use unique_ptr in svx

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

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

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

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

this reverts

commit 3c4cfa20
Date:   Mon Nov 26 12:51:05 2007 +0000

    INTEGRATION: CWS fwk72 (1.195.14); FILE MERGED
    2007/09/10 14:55:01 mav 1.195.14.1: #i81437# do not allow to export to the file the document is based on

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

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

Regression from commit 50223ea6
(tdf#98987 sw: add AddVerticalFrameOffsets compat mode, 2016-03-31),
the problem was that vertical position of the shape was wrong after
mouse move, even if we attempted to take fly frames of the paragraph
into account. (Similar situation is when saving and loading the file;
which is much easier to test.)

Fly frames are created as the
text frames is formatted, and then SwTextFrame::CalcBaseOfstForFly() can
calculate the vertical offset correctly. But in the "move with mouse"
case SwToContentAnchoredObjectPosition::CalcPosition() was invoked by
the time the old flys of the text frame were already removed, but the
new ones were not yet added.

Solve the problem by formatting the text frame from
SwAnchoredDrawObject::MakeObjPosAnchoredAtPara() (if any of its validity
flags are set to false) -- this is expected to be safe, as the object
formatter is invoked by SwLayAction::FormatContent(), i.e. there is no
recursive SwFrame::Calc() call here.

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

Change-Id: I52d75427fe30945293f347e3f49d21bc2016edae

Change-Id: I134101d1be5922051e34352331a49f5706030ff2