This was a feature requested by mmeeks, as a result of
tdf#92611.
It validates that things that extend XInterface are not
directly heap/stack-allocated, but have their lifecycle managed
via css::uno::Reference or rtl::Reference.
Change-Id: I28e3b8b236f6a4a56d0a6d6f26ad54e44b36e692
Reviewed-on: https://gerrit.libreoffice.org/16924
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
...to avoid lots of loplugin:staticmethods warnings. Also enables DBG_ASSERT
etc. also for --enable-debug builds in addition to --enable-dbgutil builds.
Change-Id: Ib89ecd9ab8ce7abb2c64790ace248b31f9d2b64d
Idea from bubli - look for loops where the index variable is of such
size that it cannot cover the range revealed by examining the length
part of the condition.
So far, I have only run the plugin up till the VCL module.
Also the plugin deliberately excludes anything more complicated than a
straightforward incrementing for loop.
Change-Id: Ifced18b01c03ea537c64168465ce0b8287a42015
Attempt to clean up most but certainly not all the spelling
mistakes that found home in OpenOffice through decades.
(cherry picked from commit e62c0f54ef18a5a79b76e934834b148523c69847)
Conflicts:
LICENSE
NOTICE_category_b
UnoControls/source/base/basecontainercontrol.cxx
UnoControls/source/base/registercontrols.cxx
UnoControls/source/controls/OConnectionPointContainerHelper.cxx
UnoControls/source/controls/progressbar.cxx
UnoControls/source/controls/progressmonitor.cxx
UnoControls/source/controls/statusindicator.cxx
UnoControls/source/inc/framecontrol.hxx
Change-Id: I882a1d640d931b4e89b2d19f3585fd35fdd320ca
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
Looks like no code instantiated these via those odd service names (except for
ProgressMonitor/StatusIndicator instantiating ProgressBar via odd
"com.sun.star.awt.XProgressBar" service name until that got cleaned up in the
previous commit).
Also looks like no code instantiates them via their implementation names either
(in which case ProgressBar/ProgressMonitor/StatusIndicator would be dead code),
but maybe there is code that dynamically constructs those implemenation names
and calls creeateInstance on them? So best leave the implementations in for
now...
Change-Id: I20b92345e343b1f776387f63d9b02a5b0a47fe21
...and create ProgressBar directly in ProgressMonitor/StatusIndicator, instead
of going via service manager.
Change-Id: I798e0c415c113cfc65d70ed17cb16aafded41a6d
...which it did unlike all the other implbaseN.hxx. Required lots of downstream clean-up,
of course.
Change-Id: Ib720e7a0a43410dcd7e6338b84a3973dfbb20866
