Offline discussion about tdf#96067 "Crash on undo row inserts" brought up the
idea to warn about cases where uses of dynamic_cast are statically knwon to
always fail. Clang's clang::AST::CXXDynamicCastExpr::isAlwaysNull already
implements such a check, reporting true if the casted-from class is final, but
has two issues:
For one, it does not work for template code, when one of the involved types is a
template parameter type (so e.g., DestType->castAs<PointerType>() can crash).
For another, it misses the opportunity to report true if the casted-to type is
final and only derives from the casted-from type non-publicly. My hope was that
this, after the "final" decorations in 548c43238d02b34cf73e7c2ca1a912ee4fe82544
"Mark some classes as final," might turn up the culprit of tdf#96067 (with a
scenario similar to the failed dynamic_cast on private derivation in
63b67ab5cab8cf7576a68cabe5fb1a42c6ad800c "Use public derivation, and remove
then-unnecessary downcasts")---but not so.
Change-Id: I962ee19820758f9c601f4a292da7f37fa9dff5ce
...to flag places that implicitly derive a class privately instead of publicly,
where accidental private derivation can cause unexpected failure of
dynamic_cast, cf. 63b67ab5cab8cf7576a68cabe5fb1a42c6ad800c "Use public
derivation, and remove then-unnecessary downcasts."
Change-Id: I4bcd5c79c7e27380c820e2dd072fa4c4e8980078
I had it locally enabled for like a month now, and it did not produce any more
noise than any of the other plugins.
Change-Id: I94dab702c537969cf32922f6e88b4f5b503cd3f5
I had it locally enabled for like a month now, and it did not produce any more
noise than any of the other plugins, but quite some amount of malformed area
designators had been introduced over time.
Change-Id: I642591496bb9338246ba43a3d988481930c087fb
My clang 3.7 built against libstdc++ 5.2.1 doesn't seem to have it. We
can get away with a non-regex replace all here, though.
Change-Id: Iea36311d89acb434c4e4f7c1f9ce876a6ee84f42
This should fix a regression from 3bdd176731c351638f541a37b94094124f3c9f52,
apparently the cppcheck's advice is misleading.
Change-Id: I427ecaa1eb3c9841cb6112997b9b51feda4583d0
...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
