(Original idea from Kendy)
Look for code that is calling std::find on a sorted container
(set/map/vector) and warn about it - the code should be using
the find method on the container itself, since that is considerably faster.
Change-Id: Ib74e5d3faa836eeb0df16a736d202696626bdfd2
A plugin to warn about and rewrite null pointer constants that are not written
as nullptr (in C++11 code) resp. NULL (in C and C++03 code). It is not
activated for the following reasons:
* At least the call to
pImpl->aFmtNms.insert(pImpl->aFmtNms.begin() + nPos, nullptr);
in svx/source/items/clipfmtitem.cxx would require
<https://svn.boost.org/trac/boost/ticket/10540> "missing std::nullptr_t
support in boost/type_traits/is_pointer.hpp" to be fixed first.
* Additions of code that violate the plugin would probably be frequent, causing
unnecessary grief for those building with plugins enabled.
* It did not find anything interesting, apart from the above Boost bug and the
mildly interesting 1da153b617b80887680be65c1854ef8080c2e1c9 "Consistently use
APP_WRITER as an integer, never as a nullptr."
Anyway,
until make -O -j4 -k check; do make -O -j1 -k check \
COMPILER_PLUGIN_TOOL=nullptr UPDATE_FILES=all; done
sucessfully executed on a recent master and resulted in
6798 files changed, 60919 insertions(+), 60919 deletions(-)
Change-Id: I1260227949868e73fcb63fda13d83e79fde685d7
It's boring and a waste of time to have to keep registering in
include/sal/log-areas.dox new log areas that other people have introduced.
We don't really have a uniform policy for logging anyway, so why bother trying
to enforce a such for the log areas? Anybody uses whatever log areas and log
output style and formatting they want in the code they happen to be working
on. And that's fine with me. We were supposed to be the project that avoids
unnecessary process, rules and bureaucracy, right?
Change-Id: I6bddcb56b58edcd885e5dc743c8730878de0036d
since it only contains a single sal_Bool site now, and we want
to leave that alone since it's a copy of similar stuff in cppuhelper.
Change-Id: I3cf4cf5f67e95d5b6f70371181f77c5451fcbf50
...that would not lead to silent changes of the code. That is, it does not warn
about sal_Bool parameters of virtual functions, so that (not yet rewritten)
overrides do not silently become overloads instead.
The plugin is in store/ for now, because not all of the code has been cleaned up
yet.
Change-Id: I6e9b3847eb26c3090f375045188d38097052defe