Change-Id: Ief7d3b09cb68eb2abdb99ebc9cfac7f71cd1476e

Change-Id: I694d90e2cfca2b4b68a33df0d3912c2492563d28

Change-Id: I810ea99f61c47da62f2489d5176f6fbb779134a9

Change-Id: Iaf30a41dcc74e4542d3df60ca26354876badc81f

Change-Id: I23ac6a7328a43c2fb63f2f804f6718f64e73eb8e

Change-Id: Ibcd5d2b4124ab441a90748588d063f394b1ef372

otherwise the VclExpander will have no effect

Change-Id: I039fa361d7088dfe4a6ff849623e34b27e2be26b

Change-Id: If655720c1d1d2e8685315261b4524b876adfc053

Change-Id: If266fa0ebaf2c3c0cd54238879a858098066c03d

Change-Id: I9955223aac20f3f640fde51bb7231666c269ca70

These were used by the now removed analyzemodel, effort and modelcleanup
scripts, so can be removed as well.

Change-Id: I3a3ed98b914e8ee21a2ffccdc399821fded90708

Change-Id: I2d702a3ea94412a35fee163581ef8c3f28566657

Regression from 263938c4 (fdo#73596
[DOCX] Multiple Columns in Index, 2014-02-13), header / footer was lost
in multi-column section. This fixes both DOC and DOCX export.

Change-Id: Icb30ec882b38853e25289299d8f829a5cf56e6d8

Saves ~40bn cycles, 10% of calculation for the bug document.

Change-Id: I9d48706ad2cfe290965b648306d95b4d66e5fc63

to replace hand-rolled version

Change-Id: Ie4e66d2f1f893c04be589877ef53f470ca74c9eb

to replace hand-rolled version

Change-Id: I7a7bf7f8f7d4f8a73ee842e7aba5eab5a254d8eb

to replace hand-rolled version

Change-Id: I084a21161ae44991199fbd2b12d61dcb7d592408

to replace hand-rolled version

Change-Id: I7a1048ff1ea335c3934fe7e91a09489a4d7aeb96

Change-Id: I652dc63cc0e8fb04d7c3115d66d60dabda60f0f4

Cleraly the variable "n" from line 999 is not in scope in
line 1054 or line 1057?

Change-Id: I8ca321e6030390ad0192e4dceb37d87b6f06f0a5

(to fix up f2945255)

Change-Id: Ie20fb9db4515b9737322ec7224ecd7e411d31c03

also translate the mark to make cell border visible

Change-Id: Ifa9f3befd1e25a66cc3443a3f33255603feea6a6
Reviewed-on: https://gerrit.libreoffice.org/10135Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

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

All environment variables contain native Win32 paths.

This allows building with Win32 make and Cygwin sh.exe,
but Cygwin make cannot build any more with the Win32 entries in PATH.

Requires adding "bash" detection to configure since /usr/bin/env
can't be invoked by Win32 make and it's possible to install cygwin
somewhere else than C:/cygwin.

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

matrix-ranges not supported

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

Change-Id: Ieb01023b93923777cf53a2fc8d7198d88422e8a4

Change-Id: I88a590344292b4adf562ca83f5072d543b5924ad

Change-Id: I8500b0cc4e541c96124425b713ba96226ff4715d

A bit unclear to me whether the code really did what was intended with
earlier VS versions either.

VS2013 said: error C2664: 'rtl::OUString::OUString(const sal_uInt32
*,sal_Int32)' : cannot convert argument 1 from 'const char *' to
'const rtl::OUString &'

Reason: cannot convert from 'const char *' to 'const rtl::OUString'

No constructor could take the source type, or constructor overload
resolution was ambiguous

Change-Id: Ie23d8382515064062a3ed46418d9d4a977b35d28

Change-Id: Idd6c227b8f50446c1d3c48385de6c843faf47466

...CUtList::cDummyElmt is always only of type CUtListElmt, not a derived type.

Change-Id: Ibc372642e2a53c548421b5cfa7cc496986036815

This commit cherry-picks 49a45422
for serf webdav version.

Change-Id: Ic5aba4fba8f8a2a521224b08865500dd932e85bf

Why insist on using the same name as a standard function? Causes
confusion with VS2013 at least, "ambiguous call to overloaded
function."

Sure, this might be caused by a bug in the compiler (or its
headers). Or maybe vagueness in the language definition? Who cares, I
still claim that intentionally writing an own function called round()
is asking for problems. So rename it to round_to_long().

(And then the return value of calls to this function, which is of type
'long', is assigned in a couple of places to variables of type 'int',
fun... Intentional, knowing there will be no overflow, or a bug
waiting to happen?)

Change-Id: If15d44f10f9f05de1c7c79492baf158eee770b8b

to replace hand-rolled version

Change-Id: I9dd8d02024702972722b43f2654db91eb3da3794

to replace hand-rolled version

Change-Id: I36d4ce14d0c0c8a4b224a240c6e25c8df99b78aa

so I can clean just the non-external stuff when re-running my
clang plugins

Change-Id: I251ceba7e57454a91da5b1082192bb2d211e5406

It has gone at 0e73ffc3.

Change-Id: I98fcdfe4861e47fbd33ff620971f247bee89290e

Change-Id: I1cc91bccd288543162b1169ce5621a91a5d4f991

Not sure if the intent is that clearCache() should be called, but the
calls have just accidentally been placed after the return statements,
or whether the code works correctly and as intended as it is now,
i.e. with the unreachable calls to clearCache().

Warning emitted by VS 2013, why don't other compilers warn? Perhaps
these functions are never called?

Change-Id: I16b0bc1b836753ef5579dadba211cbce4f50cbc3

Using it as a namespace in our rtl string headers breaks compilation
of cli_ure/source/climaker/climaker_emit.cxx (and other C++/CLI
sources we might have that include rtl string headers). Rename it to
'libreoffice_internal'.

Change-Id: Ieae68bd612b05d326d570945c1d08a54bf011852