looks like the subclass member is never written to, so I'm going to
assume this was a bug
Change-Id: Ic56c4a30cd139415eb08c4d572273dad2411b514
Reviewed-on: https://gerrit.libreoffice.org/49001
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
the subclass field is just a copy of the parent field, so drop the
subclass, and consequently simply the CreateCanvases method, we don't
need to pass the parameter down, can just access the parent field.
Change-Id: I3be448a06b32d01cdda4fc36b78cafb4488e2913
Reviewed-on: https://gerrit.libreoffice.org/48553
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
in this case, we can just drop the child member and re-use the parent
member. The parent class barely contains any logic anyway.
Change-Id: I520217c04a38b66323a76bf5fddb476bd3fc8e15
Reviewed-on: https://gerrit.libreoffice.org/48551
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
look for possibly bogus implicit conversions to bool when passing
(normally pointer) args to bool params.
this plugin comes in the wake of a couple of bugs caused by refactoring,
where some of the call sites were not currently updated.
Of the changes, the following are real bugs:
desktop/../dp_persmap.cxx
StartInputFieldDlg
in sw/../fldmgr.cxx
which occurred as a result of
commit 39d719a80d8c87856c84e3ecd569d45fa6f8a30e
Date: Tue May 3 11:39:37 2016 +0200
tdf#99529 sw: don't pop up input field dialog before inserting field
CSerializationURLEncoded::encode_and_append in
forms/../serialization_urlencoded.cxx
XclExpCFImpl::XclExpCFImpl
in sc/../xecontent.cxx
I have no idea how to properly fix this, just made a guess.
SwDocTest::test64kPageDescs
in sw/qa/core/uwriter.cxx
which looks like a simple copy/paste error.
Change-Id: I795ebd5ef485a1d36863dc27fe13832989f5a441
Reviewed-on: https://gerrit.libreoffice.org/48291
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...mostly of C-style casts among arithmetic types, and automatically rewrite
those into either static_cast or a functional cast (which should have identical
semantics, but where the latter probably looks better for simple cases like
casting a literal to a specific type, as in "sal_Int32(0)" vs.
"static_cast<sal_Int32>(0)").
The main benefit of reducing the amount of C-style casts across the code base
further is so that other plugins (that have not been taught about the complex
semantics of C-style cast) can pick those up (cf. the various recent
"loplugin:redundantcast" commits, which address those findings after this
improved loplugin:cstylecast has been run). Also, I found some places where
a C-style cast has probably been applied only to the first part of a larger
expression in error (because it's easy to forget parentheses in cases like
"(sal_uInt16)VOPT_CLIPMARKS+1"); I'll follow up on those individually.
The improved loplugin:cstylecast is careful to output either "(performs:
static_cast)" or "(performs: functional cast)", so that
compilerplugins/clang/test/cstylecast.cxx can check that the plugin would
automatically rewrite to one or the other form.
To allow fully-automatic rewriting, this also required loplugin:unnecessaryparen
to become a rewriting plugin, at least for the parens-around-cast case (where
"((foo)bar)" first gets rewritten to "(static_cast<foo>(bar))", then to
"static_cast<foo>(bar)". Rewriting could probably be added to other cases of
loplugin:unnecessaryparen in the future, too.
(The final version of this patch would even have been able to cope with
361dd2576a09fbda83f3ce9a26ecb590c38f74e3 "Replace some C-style casts in ugly
macros with static_cast", so that manual change would not have been necessary
after all.)
Change-Id: Icd7e319cc38eb58262fcbf7643d177ac9ea0220a
Reviewed-on: https://gerrit.libreoffice.org/47798
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
update plugin to find all places where we are unconditionally deleting
stuff in a destructor
Change-Id: Ia0fedc2420c7717ed2bdd8d3bb00262d2a63e0bc
Reviewed-on: https://gerrit.libreoffice.org/47724
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(The comment what the test wants to check quotes noelgrandin on #libreoffice-
dev.)
Change-Id: I8e8980902c8113eb75d24064e68a47e70bc483d6
Reviewed-on: https://gerrit.libreoffice.org/47676
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It looks like the main point of these being globals is so that they can
be cleared from various places when tables or table frames are destroyed.
Add a SwDoc parameter to ClearFEShellTabCols() and just iterate
over all shells.
Change-Id: I75ad6b695ee1bfa76b9a05c606b07a3574c70ac4
...as finding uses of variables in arguments to expand-to-nothing assert macros
is just not implemented not implemented.
Change-Id: Iacb3bd25d03eca13ac8ff3942f98e46dee3286b9
Reviewed-on: https://gerrit.libreoffice.org/47200
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
and for now, ignore methods with params so we don't fall into the trap
of thinking that calls to methods like:
Bar& foo(Bar &p) { return p; }
can be converted from
Bar f() { return foo(Bar()); }
to
Bar const & f() { return foo(Bar()); }
Change-Id: Ia3795eb2baf353cb6bec4ebf40451f2789d66ad7
Reviewed-on: https://gerrit.libreoffice.org/47034
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
improve the detection of stuff we can return by const &, instead of by
copying
Change-Id: I479ae89d0413125a8295cc3cddbc0017ed61ed69
Reviewed-on: https://gerrit.libreoffice.org/46915
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
merge the droplong and convertuintptr into one new plugin.
Limit the analysis to looking at var decl's, since that seems to be
safest proposition, even if that too needs some careful analysis.
Change-Id: Id005baaf05cfb157ce44a06a1c81f08559a07d1f
Reviewed-on: https://gerrit.libreoffice.org/46851
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>