Use correct assert in places from the clang plugin output in the bug report,
also fix some asserts of doubles and argument order (expected, actual)
Change-Id: I4e8e36f3025d74af2baf4a9be27fe4869c82e8cd
Reviewed-on: https://gerrit.libreoffice.org/22911
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
outdir doesn't seem to be created. Use current directory for
pdb files as the obj files are already stored in the current
directory.
Change-Id: I41dd65714d314cd374cc5de073d48f1a58b18c56
Reviewed-on: https://gerrit.libreoffice.org/22888
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
The default table style defined in tableStyles.xml file can be used
when a table is initially inserted into a document. It must not be
applied by default to any of the tables not referencing a table style
explicitly from the tableStyleId element.
Change-Id: I025cdfba352c87a32f9a1e297fbc8b9fc2c8c0a4
Reviewed-on: https://gerrit.libreoffice.org/22619
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Tested-by: Katarina Behrens <Katarina.Behrens@cib.de>
If no fill type is defined for a table cell, then set it to XML_noFill
explicitly, in order to override the fill type defined by the default
graphic style or the graphic style named standard, added by LO and
exported into ODP.
Change-Id: I9c5aa4c2a939ee7b8c75ae686d845cd14a718254
Reviewed-on: https://gerrit.libreoffice.org/22618
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Tested-by: Katarina Behrens <Katarina.Behrens@cib.de>
I made small changes to disable some test code conditionally by adding a few
new debug macros.
Change-Id: Ieaf6f1b29343fb896cc64163a116c629165e8db3
Reviewed-on: https://gerrit.libreoffice.org/22711
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
Issue is a regression in commit 09c722873b2d378d2d155f5f1dd7d8f3fb2012e9.
(EMF/WMF: fix rendering of pen styles (dash, dot, dashdot, dashdotdot).
I've looked at how the latest version of Word on the Mac works, and it
turns out that the spacings for the PenStyle enumerations in the LogPen
objects for all the create pen EMF records are as follows:
* PS_DOT - ■ □ ■ □ ■ □ ■ □ ■ □ ■
* PS_DASHDOT - ■ ■ ■ □ ■ □ ■ ■ ■ □ ■
* PS_DASHDOTDOT - ■ ■ ■ □ ■ □ ■ □ ■ ■ ■
(where ■ is the actual filled in area, and □ is the space between the
filled in areas)
In other words, each dash fills in the space of three dots, and there
is the one dot worth of empty space between the dashes and dots. Each
"dot" has a width and height equal to the width specified in the pen.
So basically, we seem to be arbitrarily setting the dot, dash and
distance lengths arbitrarily, which were reasonable guesses but tended
to produce very odd lines at different zoom levels.
Change-Id: Ie8b5fa396e4fb0f480cb3594c8129a59f472c1b8
Reviewed-on: https://gerrit.libreoffice.org/22886
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
clang-cl as-is does not provide the intrinsics provided by MSVC; you need to
explicitly include Intrin.h (provided by clang) for that. So, as a hack,
specify CC/CXX as
clang-cl.exe -FIIntrin.h ...
to have the intrinsics always available. But Intrin.h includes stdlib.h, so by
the time sal/osl/w32/random.c defines _CRT_RAND_S before including stdlib.h, the
latter has already been included without _CRT_RAND_S support. So, as a second
hack, specify CC rather as
clang-cl.exe -D_CRT_RAND_S= -FIIntrin.h ...
But then clang-cl starts to emit -Werror,-Wunused-macros, as defining
_CRT_RAND_S in the main file has no effect here.
Change-Id: I5dfe9872dea7e8eb476d9260f17ab8d8893f48af
In the second part, looks odd that those two lines are a perfect copy of what is
already done near the start of the function, but I have no insight at all into
that code, so just leave it at that.
Change-Id: I6b1d973f77a3d9389880ddec500968144ba615f2
Looks odd that this isGet block is a perfect copy of what is already done before
this else-if block, but I have no insight at all into that code, so just leave
it at that.
Change-Id: Ieefd6618cb6b0dc49bc4d2c4733b02be2a8e3f7e
This looks like a real bug, causing leaks in the derived VistaFilePickerImpl
(but harmless for the derived AsyncPickerEvents).
Change-Id: Ic0de3f56574b89fb45eccb09fb27b78427f712d4
PATH_MAX was reported unused on Windows with clang-cl, but the whole block seems
rather a leftover than something that is really required.
Change-Id: I545701ef83de0c2a1d74457778b86b70e334a457