The implicit defined ctors and operators will copy all members
(and bases).
Since C++11 implicit copy is depreciated if there is a non-default
dtor, keep such copies.
This commit includes only types that had either copy ctor or
copy operator and were found by cppcheck.
Change-Id: I93ee687fb3b3c5884f475a2c6054955cdde57ed7
Reviewed-on: https://gerrit.libreoffice.org/39351
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...ever since the code's introduction with
afb2f41ca9 "cws sw33bf08: #i113584#, #i113587#
transliteration fixed"
Change-Id: I9881ed1585857a95d2d8dd83ebf5d68d989e2c1d
would have preferred to re-use o3tl::strong_int, of which this
is a modified copy, but there are lots of convenience accessors
which are nice to define on the class.
Change-Id: I301b807aaf02fbced3bf75de1e1692cde6c0340a
Reviewed-on: https://gerrit.libreoffice.org/38497
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...with the aid of an extended compilerplugins/clang/store/sfxitemsetrewrite.cxx
(which in turn needed a small addition to compilerplugins/clang/check.hxx).
Enable svl::detail::validGap check for the static case, but keep it disabled for
now for the dynamic case.
Change-Id: I4846ba8e99aff94a86518e2cb5044e575093386e
This is a follow-up to 45a7f5b62d "Keep WID ranges
sorted, and join adjacent ones". While SfxItemSet::MergeRange relies on the
m_pWhichRanges being sorted (and, under DBG_UTIL, asserts if they are not), the
various SfxItemSet constructors curiously only check (via assert or DBG_ASSERT)
that each individual range has an upper bound not smaller than its lower bound.
Arguably, all SfxItemSet instances should fulfill the stronger guarantees
required and checked by MergeRange.
And in many cases the ranges are statically known, so that the checking can
happen at compile time. Therefore, replace the two SfxItemSet ctors taking
explicit ranges with two other ctors that actually do proper checking. The
(templated) overload taking an svl::Items struct should be used in all cases
where the range values are statically known at compile time, while the overload
taking a std::initializer_list<Pair> is for the remaining cases (that can only
do runtime checking via assert). Most of those latter cases are simple cases
with a single range covering a single item, but a few are more complex.
(At least some of the uses of the existing SfxItemSet overload taking a
const sal_uInt16* pWhichPairTable
can probably also be strengthened, but that is left for another day.)
This commit is the first in a series of two. Apart from the manual changes to
compilerplugins/clang/store/sfxitemsetrewrite.cxx, include/svl/itemset.hxx, and
svl/source/items/itemset.cxx, it only consists of automatic rewriting of the
relevant SfxItemSet ctor calls (plus a few required manual fixes, see next).
But it does not yet check that the individual ranges are properly sorted (see
the TODO in svl::detail::validGap). That check will be enabled, and the ensuing
manual fixes will be made in a follow-up commit, to reduce the likelyhood of
accidents.
There were three cases of necessary manual intervention:
* sw/source/core/unocore/unostyle.cxx uses eAtr of enum type RES_FRMATR in
braced-init-list syntax now, so needs explicit narrowing conversion to
sal_uInt16.
* In sw/source/uibase/uiview/formatclipboard.cxx, the trailiing comma in the
definition of macro FORMAT_PAINTBRUSH_FRAME_IDS needed to be removed manually.
* In svx/source/svdraw/svdoashp.cxx, svx/source/svdraw/svdotext.cxx,
sw/source/uibase/app/docstyle.cxx, sw/source/uibase/shells/frmsh.cxx,
sw/source/uibase/shells/grfsh.cxx, and sw/source/uibase/shells/textsh1.cxx,
some comments had to be put back (see "TODO: the replaced range can contain
relevant comments" in compilerplugins/clang/store/sfxitemsetrewrite.cxx).
A few uses of the variadic form erroneously used nullptr instead of 0 for
termination. But this should have been harmless even if promoted std::nullptr_t
is larger than promoted sal_uInt16, assuming that the part of the nullptr value
that was interpreted as sal_uInt16/promoted int was all-zero bits. Similarly,
some uses made the harmless error of using 0L instead of 0.
Change-Id: I2afea97282803cb311b9321a99bb627520ef5e35
Reviewed-on: https://gerrit.libreoffice.org/38861
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Allowing export of EditEngine document into flat XML from actual clipboard
by modifying SotClipboardFormatId
Change-Id: I9c7dfd3ca428d0fa355bd3dfb7bfa0f0e30dada6
Reviewed-on: https://gerrit.libreoffice.org/38226
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
to markup dtors that coverity warns might throw exceptions
which won't throw in practice, or where std::terminate is
an acceptable response if they do
Change-Id: I32b94814e8245372e1d1dc36be0d81e3564042f4
Reviewed-on: https://gerrit.libreoffice.org/38318
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
rAttr references *pC->maCharAttribs[nAttr].get() and assignment of
a unique_ptr is essentially a reset, invalidating the reference.
regression of commit dd891ec422
cppcheck: memleak (false positive)
but manage ownership from start
Change-Id: Ica81f0af18e11b32d2f97045961630858c78e9af
Reviewed-on: https://gerrit.libreoffice.org/38382
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
EditDataObject has odd hand-coded XInterface implementations,
this is unnecessary and can be improved by replacing its superclasses
Change-Id: Ife19c114450dfd95a10a10de1a78b035babb5443
Reviewed-on: https://gerrit.libreoffice.org/38163
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Translates all (leftovers) found using a custom regex, in directories not
shown by /bin/find-german-comments and beginning with "e".
Additionally, following is translated:
- A help string in /extensions/test/ole/EventListenerSample/EventListener/EventListener.idl
Change-Id: Iff521ae1c4a616ed5a4ca79641a5cee6f380bee0
Reviewed-on: https://gerrit.libreoffice.org/37836
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
