...to special member function declarations that were left undefined. Helps
compilers do a better job at identifiying unused class members. This plugin
uses heuristics and whitelists do identify applicable declarations, but is not
appropriate for "unattended" use so is placed into store/.
The following commits contain the results of running this plugin, per module:
* Declarations of undefined special member functions are mmarked
SAL_DELETED_FUNCTION (aka "= delete", which is deemed superior to deriving the
class from boost::noncopyable, cf. Howard Hinnant's reply to
<http://stackoverflow.com/questions/7823990/what-are-the-advantages-of-boostnoncopyable>.
* Any redundant "explicit" or SAL_DLLPRIVATE markers are removed from the
deleted definitions.
* Some redundant declarations of undefined default ctors are simply removed;
smelled like clueless cargo-cult to have them declared at all.
* Some declarations of undefined operator == etc. are left in (and marked
SAL_DELETED_FUNCTION) for now, to be on the safe side, though they are likely
clueless cargo-cult, too.
* Most "static-only" classes are replaced with namespaces (and some where that
would be non-trivial due to private members are marked TODO for later).
* Newly identified unused class members are removed.
Change-Id: Ibeaae4fd579d7a0971a2c2a654a2263acd13414a
we don't need to run them on an ongoing basis, and the current code
does not compile with older versions of clang.
Change-Id: I07ccacf7ff7b00e8e2453fff91a3f487dd5abed9
Where we can prove that the virtual method is never overriden.
In the case of pure-virtual methods, we remove the method entirely.
Sometimes this leads to entire methods and fields being
eliminated.
Change-Id: I138ef81c95f115dbd8c023a83cfc7e9d5d6d14ae
Stumbled across such redundant visibility re-specifications when looking at the
odd case of cppu_unsatisfied_iquery_msg declared CPPU_DLLPUBLIC in
cppu/source/cppu/cppu_opt.cxx and used in inline code in
include/com/sun/star/uno/Reference.hxx with only a declaration lacking
CPPU_DLLPUBLIC visible, and wondering how that actually works on Windows.
However, this plugin is probably not worth it being run all the time, so
committing it to compilerplugins/clang/store/.
Change-Id: Ibc3c4e7499213de1b419ce7eb85455cb832e1510
...some paths trough clang::Expr::isIntegerConstantExpr (esp. if
non-CPlusPlus11) assert the assumption that the given expr is not
value-dependent, so it appears to be a prereq
Change-Id: Ibc5fe472ea3f91b31c8cb7f06c4b7c7f4d6831a3
(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
...and is apparently a leftover from temporary debug output in
e36badb98d "Fix workaround for bug in Clang 3.2
FunctionDecl::isInlined."
Change-Id: I3213981c5d236a7b67083014692566f75a2bcd51
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 1da153b617 "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
