When the field in question is read from inside a constructor
initializer.
In the process, create some needed infrastructure in the plugin classes.
Change-Id: I2f440efa6912801a236727c9fe3180404616958c
Reviewed-on: https://gerrit.libreoffice.org/38960
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
tell the plugin code when we are unit-testing it, so we can suppress all
the warnings except for the plugin we are currently testing
Change-Id: I240c8e37eba90c219e53c29531a3a43bc841a1c8
...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 45a7f5b62d0b1b21763c1c94255ef2309ea4280b "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>
(such redundant std::unique_ptr copies could happen when changing parts of the
code base to make use of std::unique_ptr individually)
Change-Id: Ib48a45a212f9426a775c7f379bc5d3c92230218a
add the results files so I can just see the diff in future
Change-Id: Ia20a1aa6418be95ed620719cde340c00b7b053e1
Reviewed-on: https://gerrit.libreoffice.org/37988
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
teach it to look for the following sequence in a destructor:
delete m_pfoo;
m_pfoo = nullptr;
Change-Id: Icd6271a63a024e32b53cc9e599f8f59952160380
Reviewed-on: https://gerrit.libreoffice.org/37900
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Change-Id: I438b6719817e0bbb47370ec54561eed2bc402cba
Reviewed-on: https://gerrit.libreoffice.org/37783
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
<http://reviews.llvm.org/D22128> "Make CastExpr::getSubExprAsWritten look
through implicit temporary under CK_ConstructorConversion" was biting me again.
(I had originally developed loplugin:stringcopy against a Clang build that
includes my local fix for that issue. I really need to see to get that resolved
upstream...)
(And while 957874168491f4b030fda85c65dd969aae82a670 "loplugin:stringcopy" was
actually a false positive, it doesn't hurt either, so just keep it.)
Change-Id: I726956adfbe67681005173cfdfed2e4b4cd6253d
Some versions of Clang apparently have an issue with
CastExpr::getSubExprAsWritten, causing false postivies as in
957874168491f4b030fda85c65dd969aae82a670 "loplugin:stringcopy", where
getSubExprAsWritten in
> CXXFunctionalCastExpr 0x114a333a8 'class rtl::OUString' functional cast to class rtl::OUString <ConstructorConversion>
> `-CXXBindTemporaryExpr 0x114a33388 'class rtl::OUString' (CXXTemporary 0x114a33380)
> `-CXXConstructExpr 0x114a33348 'class rtl::OUString' 'void (class rtl::OUString &&)' elidable
> `-MaterializeTemporaryExpr 0x114a33330 'class rtl::OUString' xvalue
> `-CXXBindTemporaryExpr 0x114a33310 'class rtl::OUString' (CXXTemporary 0x114a33308)
> `-ImplicitCastExpr 0x114a332f0 'class rtl::OUString' <UserDefinedConversion>
> `-CXXMemberCallExpr 0x114a332c8 'class rtl::OUString'
> `-MemberExpr 0x114a33290 '<bound member function type>' .operator OUString 0x1149b3b60
> `-DeclRefExpr 0x114a324b8 'class jfw::CXmlCharPtr' lvalue Var 0x114a31ce0 'sUser' 'class jfw::CXmlCharPtr'
erroneously returns the MaterializeTemporaryExpr instead of looking through all
the way down to the DeclRefExpr. Will need further investigation.
Change-Id: I579cd6047b8bbf8833123ce5ad47ae7e3a33eb12
make it a little smarter in dealing with fields that are smart pointers
Change-Id: I44072105170882dc29fb19558f1065cffc7e5f11
Reviewed-on: https://gerrit.libreoffice.org/37751
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which would come out garbled. One place is
> bool bRet = SfxItemState::SET == pSet->GetItemState( i, rAttr.Which() != RES_TXTATR_AUTOFMT, &pItem );
in SwAttrHandler::PushAndChg (sw/source/core/text/atrstck.cxx)
Change-Id: I1486313b25850dc59e10edb38b8bd28a30e6aa63
...instead of merely getting a warning from PluginHandler::HandleTranslationUnit
after the fact. Such automatic rewriting should probably never be what one
wants.
Change-Id: I3829007224a197ebb4d55d24323b375cbbdf815c
...that had plagued 2e293a731c1559c9869dfcb32491bc600fc18e4e "new
loplugin/rewriter comparisonwithconstant" (in sal/osl/unx/pipe.cxx), and
auto-rewrite the remaining occurrences in sal (that the mentioned commit had
failed to address, for whatever reason)
Change-Id: I3dc3bae8dd92ba8bf576f6e06e7c9ee21f883661
by whitelisting a couple of methods we know only write to their
parameters
Change-Id: Id7aef9c03c23d10c27707b21eb9a0db4a6c2757c
Reviewed-on: https://gerrit.libreoffice.org/37647
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
