...as happens on Windows when looking at
maControlToPropertyMap.clear();
in PrintDialog::dispose (vcl/source/window/printdlg.cxx), where std::map's clear
happens to be declared at some base class std::_Tree.
Change-Id: I41810514bca59af8b4f2812d9412ce6a8d43576c
COMPMOD_RESPREFIX=abp was unused ever since initial commit in 2001.
COMPMOD_NAMESPACE was used to set the namespace name qualifier of
the helper in componentmodule.hxx to the extension's namespace name.
I don't see why this is necessary as the helper is always compiled in
a separate extension library.
Change-Id: I287607008db3dc0ebc32731536747a921c91807d
Reviewed-on: https://gerrit.libreoffice.org/39184
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...deriving from VclReferenceBase. Complicated by the fact that the argument
type may be incomplete at the time of template instantiation. So this approach
may be less precise than the change to loplugin:vclwidgets from
cbf5b21f2a65bbb342295200f6ad93a00f90733e "Catch some misuses of VclPtr
construction" when the argument type becomes complete later in the comilation
unit. However, this approach would also catch the two misuses in UnoControls
found by cbf5b21f2a65bbb342295200f6ad93a00f90733e, so go with this approach for
now and revert the change to loplugin:vclwdigets.
Change-Id: I7888f23d2b9e2db81ae2ce4bf4c8277912317685
Reviewed-on: https://gerrit.libreoffice.org/31966
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Inspired by a recent bug report where we were assigning the result
of VclPtr<T>::Create to a raw pointer.
As a consequence, we also need to change various methods that were
returning newly created Window subclasses via raw pointer, to
instead return those via VclPtr
Change-Id: I8118e0195a5b2b4780e646cfb0e151692e54ae2b
Reviewed-on: https://gerrit.libreoffice.org/31318
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Look for places where we are accidentally assigning a returned-by-value
VclPtr<T> to a T*, which generally ends up in a use-after-free.
Change-Id: I4f361eaca88820cdb7aa3b8340212db61580fdd9
Reviewed-on: https://gerrit.libreoffice.org/30749
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...they don't cause any change in behavior, likely they predated Noel's figuring
out the template part of containsWindowSubclass
Change-Id: I0d5b6bd7f228acef9a0ce1c85fe98fbab89bd7a8
...as a member of ImplCommandButtonData (vcl/source/control/button.cxx), no need
to falsly warn "OutputDevice subclass 'rtl::Reference<VclStatusListener<Button>>'
declared as a pointer member, should be wrapped in VclPtr [loplugin:vclwidgets]"
Probably loplugin:vclwidgets should enable shouldVisitTemplateInstantiations()
and not try to second-guess whether an OutputDevice can be a template argument.
Change-Id: Ia8feb1b1d7504941c35dfbf0aa02dc6a7dd818a0
Just use a Link, or rather std::function to set a member in the tab
page. Unfortunately loplugin:vclwidgets complains about the new member.
Change-Id: Ie2f9cb73c38292d02057d43b12694c6609fa0db8
Fix errors that occur in build with clang 3.7.0
Change-Id: I0e8743f2b6a288d10b4e78e884ce34cfca4dd77c
Reviewed-on: https://gerrit.libreoffice.org/18738
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
introduced by commit c15b4cf39a74176cee64795129d76f411d2c0a69
"Adapt to current Clang trunk towards 3.7"
Change-Id: I00f58d3bc79e641df9bba4e9b1d5c8463b87dc42
sometimes we need to call clear() instead, and there is no
automatic way of figuring this out
Conflicts:
compilerplugins/clang/vclwidgets.cxx
Change-Id: Iad96342ce3fdb3fa2f548270392aa00e19fec599
