summaryrefslogtreecommitdiff
path: root/compilerplugins/clang/faileddyncast.cxx
AgeCommit message (Collapse)Author
2017-10-21Avoid loplugin:faileddyncast for "unnecessary", up-casting dynamic_castStephan Bergmann
Change-Id: Iecb943db0aff7ffc21cc2f6adb625be369255b32 Reviewed-on: https://gerrit.libreoffice.org/43606 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-09-11More clang::*Type vs. llvm::*Type ambiguitiesStephan Bergmann
Change-Id: I21133976793ab018c633dda077029666308526db
2016-06-28Adapt to Clang 3.4 (in preparation of a buildbot on CentOS 7)Stephan Bergmann
Change-Id: Ie2859f03b31c57deb7fd0deba3285f782e33b239
2016-01-12New loplugin:faileddyncastStephan Bergmann
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