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
It looks like the cleanest method of getting lok_init into
a LibreOfficeKitInit.h header (in a c89 compatible way) is to
have it as a static function.
(inline is only available in C99 or later -- this is actually
available on Linux which is the only place that we can actually
use lok_init anyways currently, however given we have to keep
c89 for the C code (for MSVC) compatibility, selectively enabling
c99 would likely be more messy.)
Conflicts:
libreofficekit/Module_libreofficekit.mk
Change-Id: I0493e7a68ed5397479220bb6ba8c3db870b6dd32
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
It appears that the C++ standard allows overriding destructors to be marked
"override," but at least some MSVC versions complain about it, so at least make
sure such destructors are explicitly marked "virtual."
Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
...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
