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

Change-Id: I86f9b9ada62687e8159497bf428e18be1442c8a6

Change-Id: I0dfb044b8a339fa6c473e42f31fc28c200cd03ea

Change-Id: I526feb77b85607438dd9816ad02e06a2c7720fc8

Build problem on Android-ARM platform...

This reverts commit 0d2ce71a.

Change-Id: I05343a0c541ae2f66eedd7cc033140f810f3b1a2

Check that various older problems remain fixed.

All problematic dates of
https://bugs.documentfoundation.org/attachment.cgi?id=79051

Muchas gracias to Isamu Mogi!

Replaces the three-step timezone+DST correction. Hopefully ICU does take these
into account, but this needs to be double-rechecked and if necessary
correction be implemented at XCalendar4::setLocalDateTime()

See also
http://userguide.icu-project.org/datetime/calendar#TOC-Ambiguous-Wall-Clock-Time-Resolution
Interpreting as standard time for non-existing times sounds like what we need
and covers the dreaded "00:00-01:00 doesn't exist" case that decremented the
day and was fixed here with the now removed workaround.

Implementation only, new local date/time routines not used yet from the
outside in this step.

e.g. "CM Roman CE" should be left alone.

bump font cache id to invalidate old cached lists

I think this practice stems from Window 3.1/Word 95 where the encoding was
included in the font name
http://www.webcenter.ru/~kazarn/eng/fonts_ttf.htm#charsettbl Microsoft Office
still generates RTF files with weird-ass Win 3.1 style fontnames but any actual
existing fonts that happen to have names that fall into that pattern should be
left alone now.

Change-Id: Ibb704048d63b33ce510d6b1076700c6e94a0af2a

Change-Id: Ie6a024463e7ee9b0f4492b2431533708a578faf0

Change-Id: I8f90fb809d5275e8a74964776f01f4d563f2e657

(-fsanitize=function)

Change-Id: I009f1558990a46900e2dfa56492827cb6dcfb3cd

Change-Id: Ife0151a04477ce30bb132e6dfae9f4d3a74bf4b0

...not only when building the libs themselves, but also when including their
header files from other code.  (Omission only becomes obvious with hidden
function type RTTI causing false positives from Clang -fsanitize=function.)  As
these external libs do not record the decision to enable visiblity in a config
header file that gets included, it appears easiest to hack that knowledge into
gbuild for now.  (Note that libodfgen internally uses librevenge.)

Change-Id: I6a3a722d561b8cbce6e5b1f27d7aa2d7602f3cdf

Change-Id: I32c115aa46855375cc28402f21f4f63299e165d4

Change-Id: Ia972d7364b5acfbafd9df5b07f4fb8bd6efbab5f

Change-Id: Ie2a6e993b7982629aed650d6534a09a9eefe1c51

Change-Id: I6a1ab01bbe5cd128b132c3f6dde4b520ddb4c373

...by adding some further SAL_DLLPUBLIC_RTTI type annotations (cf.
b4f6b26b "SAL_DLLPUBLIC_RTTI for proper RTTI
visibility for LLVM") and by making sure relevant function types do not use
incomplete types in their parameter and return types (which would make the RTTI
hidden).

Change-Id: Id7aadcbc0704b9759968ae36266fc9ce11a2e340

Change-Id: Ib3f9849c2f28375a7e8bcd6575a6c3da0860d4fb

Change-Id: Ida0e92abd806d017d17365fa2ac53b4f7cb2ebad

Change-Id: I8fb6d555a7f7afe02b4c0297d3fe4e456ba41dd0

const bool bSelectUp = ( bVert && !bRow );
...
if ( bSelectUp )
    ...
else
    bVert ? (bRow ? 0 : 3) : (bRow ? 2 : 1)

the bRow is only queried on the non-bSelectUp path
if bVert is true then bRow must be also true, because
if bVert is true and bRow is false we would be in
the other branch

Change-Id: I784b41dbfda1afaf574fd8259eff3ab5cc5550fe

Change-Id: I96d4c457f8eb64de7d2009b6d6b78fda4a15a4d8

Change-Id: I7708ecaf5412535055584ed6c71beaa9cd71c10c

Change-Id: I2b4b0704afbf750aae0ef59f058c6000a06dc185

Change-Id: I5903dafb4bb29657a5b6e239cb918e656c381315

Change-Id: I60d68ef1e0f4035a650248047816cb8328fcfce0

Change-Id: I1085d6df3af1198e0fc087da4058f705f13e2f61

Change-Id: Ic50ace9d1421c9207ac95c54f363072c69b9ad00

Change-Id: Ic969ea78a53d0a67591dd476bc01fbdce18c7eab

Change-Id: Id7ad0f2060afb2f12d3111400f45d3d63e6abf8f

Change-Id: I8687e4ac621470f8f5f870c079d5740369bb4555

Change-Id: Iecca52277a2aea438c277da24afffcaeaf1119f1

Change-Id: I21ca714a701f58aa413bc508eb1ad128ebb39e58

Change-Id: I96732e57c4e40b1e9e7ff6b18fa7250b80af31bd

Change-Id: I5ea0e972eeb585870f309e7e73ba4b1ece5dfa6a