We should only use generic foo function name when it takes params
that are also dependent on UNICODE define, like
LoadCursor( nullptr, IDC_ARROW )
where IDC_ARROW is defined in MSVC headers synchronised with
LoadCursor definition.

We should always use Unicode API for any file paths operations,
because otherwise we will get "?" for any character in path that
is not in current non-unicode codepage, which will result in failed
file operations.

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

<https://bugs.llvm.org/show_bug.cgi?id=25641> "clang-cl: vtordisp thunks not
emitted for functions with class template specializations in their signatures".

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

PythonTest_pyuno_pytests_testcollections had failed with -fsanitize=address:

> ==6341==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffe5cf77048 at pc 0x7f6be12e51ba bp 0x7ffe5cf76810 sp 0x7ffe5cf76808
> WRITE of size 8 at 0x7ffe5cf77048 thread T0
>     #0 0x7f6be12e51b9 in x86_64::fill_struct(_typelib_TypeDescriptionReference*, unsigned long const*, double const*, void*) bridges/source/cpp_uno/gcc3_linux_x86-64/abi.cxx
>     #1 0x7f6be1307f03 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:171:17
>     #2 0x7f6be130346d in cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void*, void**, _uno_Any**) bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:233:13
>     #3 0x7f6be1301c56 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch(_uno_Interface*, _typelib_TypeDescription const*, void*, void**, _uno_Any**) bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:420:13
>     #4 0x7f6be0be09ff in stoc_corefl::IdlInterfaceMethodImpl::invoke(com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) stoc/source/corereflection/criface.cxx:679:9
>     #5 0x7f6be0be304c in non-virtual thunk to stoc_corefl::IdlInterfaceMethodImpl::invoke(com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) stoc/source/corereflection/criface.cxx
>     #6 0x7f6be0375ef9 in (anonymous namespace)::IntrospectionAccessStatic_Impl::getPropertyValueByIndex(com::sun::star::uno::Any const&, int) const stoc/source/inspect/introspection.cxx:609:33
>     #7 0x7f6be03753eb in (anonymous namespace)::IntrospectionAccessStatic_Impl::getPropertyValue(com::sun::star::uno::Any const&, rtl::OUString const&) const stoc/source/inspect/introspection.cxx:519:16
>     #8 0x7f6be036bd75 in (anonymous namespace)::ImplIntrospectionAccess::getPropertyValue(rtl::OUString const&) stoc/source/inspect/introspection.cxx:1040:26
>     #9 0x7f6be037102c in non-virtual thunk to (anonymous namespace)::ImplIntrospectionAccess::getPropertyValue(rtl::OUString const&) stoc/source/inspect/introspection.cxx
>     #10 0x7f6be0f95805 in stoc_inv::Invocation_Impl::getValue(rtl::OUString const&) stoc/source/invocation/invocation.cxx:495:35
>     #11 0x7f6be0f95fcc in non-virtual thunk to stoc_inv::Invocation_Impl::getValue(rtl::OUString const&) stoc/source/invocation/invocation.cxx
>     #12 0x7f6be665d69a in pyuno::PyUNO_getattr(_object*, char*) pyuno/source/module/pyuno.cxx:1424:52
>     #13 0x7f6bf34b1a5f in PyObject_GetAttr workdir/UnpackedTarball/python3/Objects/object.c:894:16
>     #14 0x7f6bf39f10f9 in PyEval_EvalFrameEx workdir/UnpackedTarball/python3/Python/ceval.c:2793:29
...

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

Sometimes bugzilla set the mimetype to application/wps-office.<the extension> incorrectly.
Ie: Our bugzilla shows 80 bugs with those mimetypes: http://tinyurl.com/ybjrmldu

Change-Id: I9f73c65604d45e76430a2d34401bcfa883534445
Reviewed-on: https://gerrit.libreoffice.org/34101Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>

Exporting variables XCODE_* makes xcodebuild read them,
independent of command line settings. Therefore renamed
these variables to IOS_ (they are only used to build iOS).

Change-Id: I2c44d2e8a1348270e2f2a6768e0552c39e7f7d72

...so spell out its single use, locking the appropriate mutex around the access

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

Without that, Windows (since 8.1) may apply compatibility mode
(at least its version API really works differently: see
https://blogs.msdn.microsoft.com/cjacks/2014/06/23/why-windows-8-1-sometimes-tells-you-it-is-windows-8-0).

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

Change-Id: Ia59f0fb64f10beab70f449d01b8a25113bea475d
Reviewed-on: https://gerrit.libreoffice.org/41741Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>

adding advapi 62 times, icuuc 24 times and libxml2 18 times (and others
multiple times as well) is too much for cygwin to handle and breaks the
build when trying to link mergedlo.dll with the not-very telling
"/usr/bin/sh: -c: line 1: syntax error: unexpected end of file"
(especially since the latter are added with $W/UnpackedTarball/whatever)

uses the sideeffect of make's sort to remove the duplicates

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

Change-Id: I93b40f5f5b493688b27747ba8ccb65097638e4e6

It has to be checked first that it's a CTYPE_CNT because otherwise
it's not a SwOutlineContent.

The assertion also didn't match the actual requirement.

Change-Id: I7fc3a6410f5de1e6b4c18965fff9bd9700562ed1

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

To 85M elements per matrix. The effective allocation depends on data types and
distribution and is not statically predictable here. Previous limit (allowing
128M elements) in the fuzz case allocated 6.5GB temporarily, it now fails early
with matrix size error. With the case's string data types and changed input
ranges probably still 4GB could be allocated.

Change-Id: I20ab3cf22705bf022f1c8c8e55b1c412380915dd

In the same spirit as the Windows commit
7c52d86f.

Change-Id: Ic45803c0715723b6f57c9f6a0c731edd559aa92c
Reviewed-on: https://gerrit.libreoffice.org/42932Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

(regression from 8f04b172)

Change-Id: I111d12a622390afc02eb73a42b1d3c714f046bd2

forgot >> file in LINK_LDFLAGS, leading to a wrong linker statement.

Change-Id: I993b15f27406b4128805fbbdaf19dadf39235f8c

Change-Id: I3b7e7a5dae9f393e3388bc5a3ab3666f116570ab

There's nothing to rearrange if mpFloatTransparenceItem isn't set
0  0x00007fffefb26748 in NameOrIndex::IsIndex() const (this=0x0) at /home/julien/lo/libreoffice/include/svx/xit.hxx:56
1  0x00007fffefb23140 in XFillGradientItem::GetGradientValue() const (this=0x0) at /home/julien/lo/libreoffice/svx/source/xoutdev/xattr.cxx:2009
2  0x00007ffff0b2c95a in svx::sidebar::AreaTransparencyGradientPopup::InitStatus(XFillFloatTransparenceItem const*) (this=0x55555859a520, pGradientItem=0x0)
    at /home/julien/lo/libreoffice/svx/source/sidebar/area/AreaTransparencyGradientPopup.cxx:61
3  0x00007ffff0b2cd33 in svx::sidebar::AreaTransparencyGradientPopup::Rearrange(XFillFloatTransparenceItem const*) (this=0x55555859a520, pGradientItem=0x0)
    at /home/julien/lo/libreoffice/svx/source/sidebar/area/AreaTransparencyGradientPopup.cxx:90
4  0x00007ffff0b262ae in svx::sidebar::AreaPropertyPanelBase::ClickTrGrHdl_Impl(ToolBox*) (this=0x555558485a50, pToolBox=0x5555586ed8c0)
    at /home/julien/lo/libreoffice/svx/source/sidebar/area/AreaPropertyPanelBase.cxx:1272
5  0x00007ffff0b26207 in svx::sidebar::AreaPropertyPanelBase::LinkStubClickTrGrHdl_Impl(void*, ToolBox*) (instance=0x555558485a50, data=0x5555586ed8c0)
    at /home/julien/lo/libreoffice/svx/source/sidebar/area/AreaPropertyPanelBase.cxx:1268

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

Drops all the static calls and variables from SalAquaTimer
and moves all timer handling logic inside the class.

This also fixes the leak in timerElapsed.

Change-Id: Ie7a1a8fffb70b8579ec6876eed10a275d2f06d27
Reviewed-on: https://gerrit.libreoffice.org/42913Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

When _WIN32 is defined, lok_dlerror() uses FormatMessageA() call with
FORMAT_MESSAGE_ALLOCATE_BUFFER flag [1] to get returned error string.
This string is required to be released after use with LocalFree() (or
HeapFree(), since LocalFree() is not available in recent SDKs).

However, there is no mention in the header that this is required, nor
lok_dlopen() that uses it does any cleanup. If the calling application
is expected to be terminated in case of error, then that is no problem;
but the header might be used in any external client application which
we know nothing of.

This adds corresponding cleanup function.

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

Latest gdb release "lazy_string" validates the array size:

  Traceback (most recent call last):
    File "/work/lo/master/solenv/gdb/libreoffice/util/string.py", line
29, in to_string
      return self.make_string(data, self.encoding, len)
    File "/work/lo/master/solenv/gdb/libreoffice/util/string.py", line
66, in make_string
      return data.lazy_string(encoding, length)
  gdb.error: Length is larger than array size.

rtl_uString has "sal_Unicode buffer[1];", which is a lie
as the real size is the same as "length".

Taking the address of "buffer" appears to avoid the exception.

Change-Id: I85710b1adfae584ba09c8d517e9b49b290e79d8a

Change-Id: Ie7c482d387f9ffd3be92759200446951b9084408

...about the definition of __cxxabiv1::__cxa_exception in
bridges/source/cpp_uno/gcc3_linux_x86-64/share.hxx, when a declaration of that
struct has already been seen in /usr/include/c++/7/cxxabi.h in a

  #pragma GCC visibility push(default)
  ...
  #pragma GCC visibility pop

block (so that decl->getAttr<VisibilityAttr>() would point at the first of those
two pragmas).

Change-Id: I4af56be8ce84ace57a809a09da5c44d86fc4237a

Project: help  9ff4dd9cbd323794e72d08e297b59cc09d1abbe0

helpcontent2: fix build, use pack_images.py

Change-Id: Ie96d42c895daca558a716bd234143016318d3b5c

Change-Id: I758b4452bdf0cfcc75280a73993f219a57072e41

as delegating constructor.
In preparation to remove default able copy constructors
of derived classes.

Change-Id: I516efa70ef2a06079194aafbf630e151138c6bbc
Reviewed-on: https://gerrit.libreoffice.org/42923Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>

Remove replaced packimages.pl

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

Since we dropped support of Vista and below in master toward 6.0,
those checks are needless. Removing the code that only worked in
older versions, and streamlining the resulting code.

Also, use kernel32.dll version for Windows version, instead of
deprecated GetVersionEx, and inconvenient VersionHelpers. Since both
GetVersion(Ex) and VersionHelpers (based on VerifyVersionInfo) are
subject to manifest-based behavior since Windows 8.1, this move will
hopefully result in more reliable OS version detection.

Change-Id: I3edd8fc1843e64b6a65bd3a126be6a085511f13c
Reviewed-on: https://gerrit.libreoffice.org/42905Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>

it's obviously not a real problem, because higher up code calls this
even if it doesn't intend to use the result, and in the places where it
does intend to use the result, it warns again, so this warning is
redundant.
And it's the 3rd largest number of warnings in our logs.

Change-Id: I1a6c40bc99a3252594f87e121a81c661686c5348

... and Index of Tables.

Change-Id: I5a677f431d1a2e3836bcacdd382708b0ce397faf
Reviewed-on: https://gerrit.libreoffice.org/42481Reviewed-by: Tamás Bunth <btomi96@gmail.com>
Tested-by: Tamás Bunth <btomi96@gmail.com>

Change-Id: I331e12ab5115401b9fa87e1f0f2be51f33ccbc75

We need to check if it possible to move workspace to
workdir (e.g. do a reverse ln)

Change-Id: I98751c1731f75e3b4200520ffa741a7348fe70fb

This works when working online in xcode, but not from make

Change-Id: I5c871f05b3c986ead17ff926430e82da1808a52c

The bugdoc has a section large enough that it is split across 4 pages.
The section is inside a nested table. First we lay this out properly,
but when later laying out the footer we need to redo the body frame
layout, which first undoes the split of the table/nested table/section.

This fails, the master second and its 3 follows are expected to be moved
back to the first page (and merged together), but
SwSectionFrame::MakeAll() did this only for the first follow, which was
moved to the first page, not for the other 2 follows which were on other
pages.

Fix the problem by merging not only follows which are also next to the
section frame, but also the ones which are follows (but not nexts).

Change-Id: I7a69aa58336a50d4f37808ccb105b443c2f6993c

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

...which is there for MSVC compatibility, but can cause getBody() to return null
even when doesThisDeclarationHaveABody() is true.

And in staticmethods.cxx we need to check doesThisDeclarationHaveABody() instead
of hasBody():  For some class template member functions that are only defined
outside their class definition, as is the case for
OSequenceIterator::hasMoreElements in include/comphelper/sequence.hxx, hasBody()
may be true for the original member function declaration inside the class (as
there is some later definition that does have a body), but
isLateTemplateParsed() is not (it is only true for the later definition).  So
just skip any such declarations that are not definitions (which is sane anyway,
as otherwise such functions could pointlessly be inspected multiple times).

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

...that are apparently accepted by MSVC, but not by clang-cl

Change-Id: I2a11bdc709b9711d9d93d24dcb5957121fcf9efb

Change-Id: Ie7e9c0ed522eff7a8b1de2595468b7999d70a1b9

Move the definition of the static thread_local members of
ScInterpreter to the source file where its constructor is. Also, the
only users of those members are in that file, so it is logically a
better place anyway.

Change-Id: I651b15abc83cc49edebbe8e3f982c3b3e6cc8799

As any .ui based docking window gets it unconditionally,
see extractDeferredBits function in builder.cxx.

Change-Id: I339a72989ad09d8ea7106f5690fc950ee7ba35da