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
e36badb98d0bb5866a297cb51c3e95cdce62d8da "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 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
First stage of new VCL widget reference checker
Change-Id: I63a2108a26b3c0e0a896d13672b1daa6f8e60b3a
Reviewed-on: https://gerrit.libreoffice.org/10427
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
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
...where prior to r183883 "Implement core issue 903: only integer literals with
value 0 and prvalues of type std::nullptr_t are null pointer constants from
C++11 onwards," Expr::isNullPointerConstant with NPC_NeverValueDependent could
go into an llvm_unreachable case.
Change-Id: I29cf093f18ece4cd83fd759e30f72c2a71f69554
Find "missing headers," where a function is declared directly in the
.cxx (as extern) and not defined, and should arguably instead be declared
in an include file.
Change-Id: I6d83ee432b2ab0cd050aec2b27c3658d32ac02a2