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

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

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

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

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

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

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

and drop unused ERRCODE_AREA_OFA_END constant

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

I'm not exactly sure what role the Endnote Symbol char style
plays, but it is only related to Endnote Characters, not the
main footnote text.

Note: the existing mapping rarely takes effect since MSWord
exports the stylename in lower-case. Unfortunately, there is
no history to indicate why "Endnote Text" is mapped to
"Endnote Symbol". That looks like an error to me.

related to tdf#82173 which exposed this issue.

Change-Id: Ie92f527b1e594fd571f1118d18a8ff225cfc2314
Reviewed-on: https://gerrit.libreoffice.org/38605Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>

This makes the pivot table exported to XLSX refreshable (does not
crash Excel on pivot table refresh).

Change-Id: Icc35795cd116e091b75bb1d4a603c52ccc71c44d
Reviewed-on: https://gerrit.libreoffice.org/39018Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>

Change-Id: I3f30b5ab985c2ff709116568905b941c5d50fd1a

Change-Id: I307662ef0d8360da3cbc7edc96890575715bbf07

Change-Id: I3dce45da77c6ab21be5a999d4ea5b7944a07bbd7

Change-Id: I8f02cfdcaa1a5d2ce981b5de1b9754da36760649
Reviewed-on: https://gerrit.libreoffice.org/39124Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>

I didn't find UI in Word to create

<w:spacing w:line="-260" w:lineRule="auto"/>

the equivalent markup when you set line spacing to exactly 13pt for new
documents is:

<w:spacing w:line="260" w:lineRule="exact"/>

The OOXML spec and Microsoft's implementer notes ([MS-OI29500]) is also
pretty silent about what a negative value means. However, if this markup
is converted to WW8 by Word, then the WW8 LPSD structure is like this
(as presented by doc-dumper):

<lspd type="LSPD" offset="5086">
  <dyaLine value="0xfefc"/>
  <fMultLinespace value="0x1"/>
</lspd>

For the 0xfefc value the [MS-DOC] spec clearly states that means the
type of the spacing is "exactly", with the value of 0x10000-0xfefc, i.e.
the same 260 twips.

Change-Id: I84b485d02dea49c610b6df2e06ccce03e1d29d21
Reviewed-on: https://gerrit.libreoffice.org/39091Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

This file is generated by "make vim-ide-integration"

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

Change-Id: Idb22bd00572d362eb2cc0137fe01835d6c28fcf8

xmlparse.c has a
 #define buffer something

later
 #include something

that happens to use buffer as a parameter.

Change-Id: I7378aa9481b30364097c70317c794c0bcca2f05c
Reviewed-on: https://gerrit.libreoffice.org/39109Reviewed-by: jan iversen <jani@libreoffice.org>
Tested-by: jan iversen <jani@libreoffice.org>

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

Change-Id: Iaa23361510b1aa1eebfa6618b526fc7d9d6fa537

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

Allows you to remove an entry along with its children
without selecting the entry.

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

Change-Id: I7cbea9381bc993e7894603c731ab0ac54e80d4b4
Reviewed-on: https://gerrit.libreoffice.org/39049Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

The only remaining difference is that in the system-xmlsec case we work
with the default key manager, not with the one that's only added by our
xmlsec patches.

This works for me for the uses I know of (see
<https://lists.freedesktop.org/archives/libreoffice/2017-February/076947.html>
for the motivation): signing and verifying of different signatures (bad
signature, good with non-trusted CA, good with trusted CA) with
software-based certificates all behave as expected.

Change-Id: If3f3e2b8373ab7397db3f98070a5a2ce51fa7c06
Reviewed-on: https://gerrit.libreoffice.org/39075Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>

The ClearSwLayouterEntries() accesses anchored objects and if they are
anchored in footnotes then RemoveFootnotes() has already deleted them.

(regression from 962d0500)

Invalid write of size 1
   at 0x4143CCB3: SwAnchoredObject::SetTmpConsiderWrapInfluence(bool) (anchoredobject.cxx:739)
   by 0x414D8A21: SwObjsMarkedAsTmpConsiderWrapInfluence::Clear() (objstmpconsiderwrapinfl.cxx:58)
   by 0x414C943E: SwLayouter::ClearObjsTmpConsiderWrapInfluence(SwDoc const&) (layouter.cxx:401)
   by 0x411DBE57: sw::DocumentLayoutManager::ClearSwLayouterEntries() (DocumentLayoutManager.cxx:504)
   by 0x414D05D9: SwRootFrame::DestroyImpl() (newfrm.cxx:594)
   by 0x41535AB3: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:389)
   by 0x419E8171: std::_Sp_counted_deleter<SwRootFrame*, void (*)(SwFrame*), std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() (shared_ptr_base.h:464)
   by 0x40EB6DB5: std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (shared_ptr_base.h:150)
   by 0x40EB5E76: std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() (shared_ptr_base.h:662)
   by 0x419E65F9: std::__shared_ptr<SwRootFrame, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() (shared_ptr_base.h:928)
   by 0x419E6615: std::shared_ptr<SwRootFrame>::~shared_ptr() (shared_ptr.h:93)
   by 0x419E619D: SwViewShell::~SwViewShell() (vnew.cxx:285)
  Address 0x5feb6eee is 334 bytes inside a block of size 488 free'd
   at 0x4C2F21A: operator delete(void*) (vg_replace_malloc.c:576)
   by 0x41488962: SwFlyAtContentFrame::~SwFlyAtContentFrame() (flyfrms.hxx:134)
   by 0x41535AFC: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:391)
   by 0x415360BD: SwLayoutFrame::DestroyImpl() (ssfrm.cxx:477)
   by 0x41535AB3: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:389)
   by 0x414A2FF4: sw_RemoveFootnotes(SwFootnoteBossFrame*, bool, bool) (ftnfrm.cxx:852)
   by 0x414A3104: sw_RemoveFootnotes(SwFootnoteBossFrame*, bool, bool) (ftnfrm.cxx:874)
   by 0x414A321A: SwRootFrame::RemoveFootnotes(SwPageFrame*, bool, bool) (ftnfrm.cxx:897)
   by 0x414D0558: SwRootFrame::DestroyImpl() (newfrm.cxx:585)
   by 0x41535AB3: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:389)
   by 0x419E8171: std::_Sp_counted_deleter<SwRootFrame*, void (*)(SwFrame*), std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() (shared_ptr_base.h:464)
   by 0x40EB6DB5: std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (shared_ptr_base.h:150)
   by 0x40EB5E76: std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() (shared_ptr_base.h:662)
   by 0x419E65F9: std::__shared_ptr<SwRootFrame, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() (shared_ptr_base.h:928)
   by 0x419E6615: std::shared_ptr<SwRootFrame>::~shared_ptr() (shared_ptr.h:93)
   by 0x419E619D: SwViewShell::~SwViewShell() (vnew.cxx:285)

Change-Id: I147f46d49c90de46189ad34feed66c289adddc15

Use temporary SAL_DEBUGs in your local tree instead if/when you need
to trace these constructors and destructors.

Change-Id: Icc52c905205914f0e5b911a2dae8322e99e9234e

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

Change-Id: If4de6e4cdebb082cbe8faa9392fceb61c3f8fb9e

Change-Id: I38cb79abb2a495ccca454903bc46b407009e8290
Reviewed-on: https://gerrit.libreoffice.org/39084Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>

for some reason they are not set and cause parse warnings

Change-Id: I1bbc14da8cd7f4cbde8e59934b6ace932245e2a1
Reviewed-on: https://gerrit.libreoffice.org/39093Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>

tde and mozilla externals are gone.
breakpad, bzip2 and mDNSResponder are omitted.

filter out 'orcus-parser\' line, 'orcus-parser' is still in
iwyu_EXTERNALS

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

no logic change intended.

follow some shellcheck advises:
use block for redirects to same file for better style (SC2129)
double quote vars (SC2086)
ignore false positive warnings SC1003 and SC2016

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

Last holdout for separate xmlSec init removed, cf.
ed92db7a

Change-Id: I46a05074706bba77ebc488f0df296e35e2b7d553

removed with 06d7dbb3

Change-Id: I7e01cc1f3551cd18c8fe09e908b6dbab75e2ae2d

Take it into use in a couple of places.

Change-Id: I72127f4236220fbe6fbf9ea25cdd56470be89961
Reviewed-on: https://gerrit.libreoffice.org/38997Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Tor Lillqvist <tml@collabora.com>

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

This reverts commit d36dc7b3.  Turns out e.g.
tb75-lilith has a 'file' command that doesn't print "execfn:" information, just

> /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/workdir/UITest/calc_demo/done.core/core.24697: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/instdir/program/soffice'

(<https://ci.libreoffice.org/job/lo_tb_master_linux_dbg/13930/console>), but
with a truncated "from:" path, so would probably be little benefit to try to get
the path from the "from:" instead of (or in addition to) the "execfn:"
information (where the latter appears to be more accurate at least with my local
file-5.29-4.fc25.x86_64).

also when we could not create lockfile, not only when open as readonly

Change-Id: Ied53bbfe47669f62553d97d81f0bed156ae58887
Reviewed-on: https://gerrit.libreoffice.org/39054Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Tested-by: Katarina Behrens <Katarina.Behrens@cib.de>

Change-Id: Idb4ee77ed83c17f8040cf1a5852ae1ac8fa855d6

...that dumped a core file.  Is it just that the pathname is too long and gets
truncated?  To be reverted again.

Change-Id: I2e571cf7d5d3a128e8875e01df37bfccadefe80a