this bug was caused by commit
2aacf6c2
"sc: boost::ptr_vector->std::vector"

Since the code in question likes passing around a pointer
to the element of the vector, convert to using
std::vector<std::unique_ptr>

Change-Id: I9e9676fe7c2dc32e23ba6708aaea1f16c1bf2ff8

Change-Id: I0103ca0da3a39e48416617aab4372cde8be0bbab
Reviewed-on: https://gerrit.libreoffice.org/20654Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Martin Hosken <martin_hosken@sil.org>

Change-Id: I5f35e0aeb6cef5920891eaa338c1d9b29e0ce554

Change-Id: I7141510fbda1158511698f73c48274008f0a41dc

Change-Id: I5a8daa1c0f2b62dbf56fa9fc1d14555f0ff613e2

Change-Id: Iada331a12232fd83b6813e6db65bd011d3746142

Change-Id: I9e9372ea9df6b959493445901b70a9ee6d3c0dac

Change-Id: Ib3acd5b853283dce2cdcbe72d7992637368fdf6b

Change-Id: Ib6f55bc0ce6c09ea523174cb630c6d7cd9808f96

Other code is out of legacy mode now, so can't legacy as a proxy.

Change-Id: Ie3807a3af680b707f2f08d058db955bc9cae6c2b
Reviewed-on: https://gerrit.libreoffice.org/20647Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>

(in an attempt to cause tinderboxes to rebuild)

Change-Id: I5cc94a988303b7b1ff85ec09c3d4f88d300f73b0

To selectively use the sticky mechanism, i.e. not in an actual move of a
range during cut&paste or drag&drop. Actually currently only in
ScTokenArray::AdjustReferenceOnShift()

Change-Id: I223e5013e4b820efb4ecb9e8ce8aa04a8bc01e27

Change-Id: I639638cb9cc387178183760137c0510802b8c6d9

...which contained the bulk of .cxx files that should logically go into
Library_pdfimport.  It was likely (only) used so that check_targets
CppunitTest_sdext_pdfimport, Executable_pdf2xml, and Executable_pdfunip could
access the library's internals without exporting them.  For the CppunitTest, use
the standard gb_CppunitTest_use_library_objects hack instead.  For the two
Executables, make that _use_library_objects hack available for Executables, too.
(It is a bit unclear whether those two Executables are really needed, they are
only referenced from the dead dmake-based
sdext/source/pdfimport/test/testdocs/makefile.mk and from vcl/README,
respectively; but just keep them alive for now.)

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

Change-Id: I962544005b5d408f7c044a02eefe09b87d8a81fe

When importing SdrObjCustomShape for each an Outliner and a
VirtualDevice as RefDevice are created and held. On 32bit systems this
breaks the import with many such objects (in the bugdoc around 4300). On
64bit it works, but more memory as necessary is used. To avoid this,
flush the UNO API implementations at these objects after one page is
imported.  Do not do this for each single object, that will break the
connector import which does some processing later.

Change-Id: I7296edd40f01c1a40258808d78bf39e6d4fe29bf
Reviewed-on: https://gerrit.libreoffice.org/19990Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

... and fix the breakages it finds.

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

...introduced in b9d1006e "re-base on ALv2
code," probably due to a merge conflict or something like that.

Change-Id: Ib38cd24e935f951482ba99f483a419a9a7782ae8

error: assuming signed overflow does not occur when assuming that
(X + c) < X is always false [-Werror=strict-overflow]
     if ( rAddress.Row() < Row() )

Change-Id: Ia643491657680fffcaacae4a474af479b9a07e35

...to prevent errors like 5ac6e002 "Memory leak"

Change-Id: I3e20393af628849d8a387b491b75e1aacdea982a

...even if no correpsonding xPopupMenu proxy has been set up for some i (because
that sub-menu has never been opened by the user).  Otherwise, the Menu that
m_pVCLMenu->pItemList->maItemList[i]->m_pSubMenu points to will be deleted
(during a recursive xSubMenuManager->dispose call), and when later for some
sub-menu j > i that /has/ been opened by the user SetPopupMenu is called, that
can lead to

> Menu::GetPopupMenu(unsigned short) const at vcl/source/window/menu.cxx:835
> Menu::GetAccessible() at vcl/source/window/menu.cxx:1400
> OAccessibleMenuItemComponent::getAccessibleParent() at accessibility/source/standard/accessiblemenuitemcomponent.cxx:339
> non-virtual thunk to OAccessibleMenuItemComponent::getAccessibleParent() at accessibility/source/standard/accessiblemenuitemcomponent.cxx:335
> atk_object_wrapper_new(com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessible> const&, AtkObject*) at vcl/unx/gtk3/a11y/../../gtk/a11y/atkwrapper.cxx:839
> atk_object_wrapper_ref(com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessible> const&, bool) at vcl/unx/gtk3/a11y/../../gtk/a11y/atkwrapper.cxx:795
> AtkListener::handleChildAdded(com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext> const&, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessible> const&) at vcl/unx/gtk3/a11y/../../gtk/a11y/atklistener.cxx:157
> AtkListener::notifyEvent(com::sun::star::accessibility::AccessibleEventObject const&) at vcl/unx/gtk3/a11y/../../gtk/a11y/atklistener.cxx:296
> comphelper::AccessibleEventNotifier::addEvent(unsigned int, com::sun::star::accessibility::AccessibleEventObject const&) at comphelper/source/misc/accessibleeventnotifier.cxx:281
> comphelper::OAccessibleContextHelper::NotifyAccessibleEvent(short, com::sun::star::uno::Any const&, com::sun::star::uno::Any const&) at comphelper/source/misc/accessiblecontexthelper.cxx:188
> OAccessibleMenuBaseComponent::InsertChild(int) at accessibility/source/standard/accessiblemenubasecomponent.cxx:436
> OAccessibleMenuBaseComponent::ProcessMenuEvent(VclMenuEvent const&) at accessibility/source/standard/accessiblemenubasecomponent.cxx:624
> OAccessibleMenuBaseComponent::MenuEventListener(VclMenuEvent&) at accessibility/source/standard/accessiblemenubasecomponent.cxx:572
> OAccessibleMenuBaseComponent::LinkStubMenuEventListener(void*, VclMenuEvent&) at accessibility/source/standard/accessiblemenubasecomponent.cxx:569
> Link<VclMenuEvent&, void>::Call(VclMenuEvent&) const at include/tools/link.hxx:84
> Menu::ImplCallEventListeners(unsigned long, unsigned short) at vcl/source/window/menu.cxx:355
> Menu::SetPopupMenu(unsigned short, PopupMenu*) at vcl/source/window/menu.cxx:825
> framework::MenuBarManager::RemoveListener() at framework/source/uielement/menubarmanager.cxx:556

looking at the dangling pSubMenu pointer (and even if the dangling pointer is
never dereferenced, UBSan will try to determine whether the static_cast in

  return static_cast<PopupMenu*>(pData->pSubMenu);

in Menu::GetPopupMenu, vcl/source/window/menu.cxx, is fine and cause a crash).

Change-Id: I5e5f6dba266580e3c2e7693877ea79a07d80bb74

Change-Id: I9032af7583f0cf97664d2f84d5aead0cb1547c1a

Change-Id: Iaf482b357577ff8a5511607844a69c90ea28d29f

Change-Id: Iacddc7b84bf0be8bb112cba88cc7fd36f72e7ca0

Change-Id: I1572e101be0f5d9267dd48e96212689d80d1d023

No transition makes use of repeat, and it could lead to some artifacts
when writing transitions.

Change-Id: Icf6f4f0eb74c28d8c75991e717b6b4ffe9df5060

This is the ground work for some later transitions in slideshow.

Change-Id: Ib200cf7fabd579256a5255b0fb5d8c4accf7d24b

Change-Id: Ice61bfbd75aafd4197584c34ef7fbed80c20c184

Instead replace it with no transition at all.

Change-Id: If7085e2ecd79eda80097f96bebbb2f9d11161c22

Change-Id: If87f441607adf2ed0aa31023352774e7372b7edb

Change-Id: Ifb22c75c77d6bb5d3f144a1ed92bbcdf8d1112fd

Change-Id: I870ef7885fe569c89bde63a70ef038c4133ffbfd

Change-Id: If5f7368bf53dd59e66e990e4f2c57b6ee2cba44b

Change-Id: I9d6c3ad0d2cc2f691afb2c8622471286f8a5e1c7

Change-Id: I2380fc7f8462514e6c032b18b44df51fbaaccb9f

Change-Id: Ib799244c6c3dd8d6fd21adc28e68690287caebd0

Change-Id: I13c91af15caad888b4b56dbf92b63fdb0a97b47d

Change-Id: I92bafb3459f4a2847aac05f114691b39144dc7c9

Change-Id: I0b0c2e33137bfd35a5048638ef3cce18ed1b06f0

Change-Id: Ib85337ebef0ba1a3ab00ad3adb59b4cffbba2b2f