Let loplugin:nullptr look into template instantiations

It missed some occurrences of 0 when only looking into uninstantiated template
code, as Clang doesn't model them with an ImplicitCastExpr, even if the target
is known to be a (dependent) pointer type.

Looking into all template instantiations of course carries the risk that a given
use of 0 is meant to be interpreted as a pointer in some and as an integer in
other instantiations.  But the only case where that happened in the current code
base is RegistryValueList::getElement (include/registry/registry.hxx), where {}
is arguably a better choice anyway.  (And which would presumably also hold for
any future such cases.)

Change-Id: I708bcfc8bedc0a49c9282d7814eb325afa29905c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128462
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

1 files changed, 4 insertions, 1 deletions

diff --git a/compilerplugins/clang/nullptr.cxx b/compilerplugins/clang/nullptr.cxx
index b4a40b408a6c..55551ac09292 100644
--- a/compilerplugins/clang/nullptr.cxx
+++ b/compilerplugins/clang/nullptr.cxx
@@ -75,7 +75,7 @@ public:
 
     bool TraverseInitListExpr(InitListExpr * expr, DataRecursionQueue * queue = nullptr);
 
-    // bool shouldVisitTemplateInstantiations() const { return true; }
+    bool shouldVisitTemplateInstantiations() const { return true; }
 
 private:
     bool isInLokIncludeFile(SourceLocation spellingLocation) const;
@@ -209,6 +209,9 @@ bool Nullptr::VisitParmVarDecl(ParmVarDecl const * decl) {
     if (!isAnyKindOfPointerType(decl->getType())) {
         return true;
     }
+    if (decl->hasUninstantiatedDefaultArg()) {
+        return true; //TODO
+    }
     auto e = decl->getDefaultArg();
     if (e == nullptr) {
         return true;