This mostly affects explicitly defaulted functions that had recently been user-
declared to silence new GCC trunk -Wdeprecated-copy. It is not entirely clear
to me what the best approach is overall, see my mail
<http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20181001/245321.html>
"Re: r343285 - [cxx2a] P0641R2: (Some) type mismatches on defaulted functions
only", but lets just explicitly delete those functions for now.
Change-Id: If8c72f612f67a8feb8b03c2fb988c807e704ef03
Reviewed-on: https://gerrit.libreoffice.org/61259
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Also make the functions constexpr.
Due to slight changes in floating-point arithmetics (90.0 instead of
180.0, M_PI2 instead of M_PI resp.), results might differ in last
digits (usually 17th decimal digit). This has lead to need to tweak
char2dump's PieChartTest unit test.
Change-Id: I20323dd7dab27e4deb408ea4181e390cc05e7cd3
Reviewed-on: https://gerrit.libreoffice.org/58583
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...by explicitly defaulting the copy/move functions (and, where needed in turn,
also a default ctor) for classes that have a user-declared dtor that does
nothing other than an implicitly-defined one would do, but needs to be user-
declared because it is virtual and potentially serves as a key function to
emit the vtable, or is non-public, etc. There appears to be no good reason for
these classes to have a deleted copy assignment op, so just change that to
implicitly-defined, too.
Change-Id: I65fb6ea78a13b7b3d237529613c0489c8cf50614
Reviewed-on: https://gerrit.libreoffice.org/58119
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx> (and don't make use of it themselves), but many other files happen to depend on it.
This is a continuation of commit 6ff2d84ade to be able to remove those unneeded includes.
This commit adds missing headers to every file found by:
grep -FwL sal/log.hxx $(git grep -Elw 'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF|SAL_DETAIL_LOG_STREAM|SAL_WHERE|SAL_STREAM|SAL_DEBUG')
to directories from connectivity to cui
Change-Id: I9903c10d0a04bbeb93d0f776d1d252b152459499
Reviewed-on: https://gerrit.libreoffice.org/57408
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
the text hightlighting feature was implemented backed on to the vcl
TextFillColor feature. TextFillColor fills the background of the bounds
of the text with that color
Likely either the same problem or similar as tdf#93789
Change-Id: Iace62cedc49e5f5844ac35d3caa23249b6cb4bc1
Reviewed-on: https://gerrit.libreoffice.org/55629
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
so that we flush out various code using Bitmap, in favour of using
BitmapEx.
This is part of the process of making Bitmap largely an internal detail
of vcl
Change-Id: Iaf2ead5e3d9960838723fb55b812b97108093d74
Reviewed-on: https://gerrit.libreoffice.org/55062
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This reverts commit 8bc951daf7.
As discussed at
<https://lists.freedesktop.org/archives/libreoffice/2018-April/079955.html>
"long->sal_Int32 in tools/gen.hxx", that commit caused lots of problems with
signed integer overflow, and the original plan was to redo it to consistently
use sal_Int64 instead of sal_Int32. <https://gerrit.libreoffice.org/#/c/52471/>
"sal_Int32->sal_Int64 in tools/gen.hxx" tried that. However, it failed
miserably on Windows, causing odd failures like not writing out Pictures/*.svm
streams out into .odp during CppunitTest_sd_export_ooxml2. So the next best
approach is to just revert the original commit, at least for now.
Includes revert of follow-up 8c50aff217 "Fix
Library_vclplug_qt5".
Change-Id: Ia8bf34272d1ed38aac00e5d07a9d13fb03f439ae
Reviewed-on: https://gerrit.libreoffice.org/52532
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
using
git grep -lwP "Color\s*\(\s*(COL_\w+)\s*\)"
| xargs perl -pi -e "s/Color\s*\(\s*(COL_\w+)\s*\)//g"
and then some manual fixup where the resulting expression no longer
compiled
Change-Id: I0e268d78611c3be40bba9f60ecfdc087a36c0df4
Reviewed-on: https://gerrit.libreoffice.org/50372
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: Ib58b16600c97f8dab1b32d7e049c946ca82e660b
SvStream::ReadFloat already does that, and SvStream is initialised
to SvStreamEndian::LITTLE by default.
Change-Id: I5859e43014533bcebef9d4b8f0678c516193b92e
Insert constructor everywhere, except a couple places that apparently
want to compare GetMapUnit().
Change-Id: I1910deb60562e5e949203435e827057f70a3f988
which actually does nothing useful. Looks like it was originally
intended to be used to implement color profiles, but since nothing
has happened on that front since it was created, safe to say it never
will. Probably not the right place in the graphics stack to do it
anyhow.
Change-Id: I36990db4036e3b4b2b75261fc430028562a6dbd9
Reviewed-on: https://gerrit.libreoffice.org/43240
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reduce potential confusion with the global tools namespace. Will
hopefully make it possible to remove the annoying initial :: when
referring to the global tools namespace. Unless we have even more
tools subnamespaces somewhere.
Thorsten said it was OK.
Change-Id: Id088dfe8f4244cb79df9aa988995b31a1758c996
Reviewed-on: https://gerrit.libreoffice.org/42644
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
had to change the structure of the plugin considerably, was too messy to
structure it to do the calculations on a per-function basis
Change-Id: I4edee7735f726101105c607368124a08dba21086
Reviewed-on: https://gerrit.libreoffice.org/40516
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
