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>
Change these back to consistently use the "..." form to include other UNO API
include files, for the benefit of external users of this API.
Change-Id: I9c9188e895eb3495e20a71ad44abfa2f6061fa94
These are pretty silly anyway, but apparently it complains even about
integer variables which make this rather a waste of time.
Change-Id: I15e847d33d5decd2adcab04e4f1567d3997d28a2
Add a macro in include/cppuhelper/implbase_ex.hxx
to make initialising the type_entry classes a little less verbose.
Change-Id: I0904b5b9db269c92bc89e7ce3d6c8b09350c9897
Stephan Bergmann