...after a31267be1bb42e8a5f80a3b660bbf969eeb5b647 "Fix isSalCallFunction so it
also works on Windows", so that it actually does work on Windows.
Change-Id: I0218fb41b3e1000e2325967a18dfaafaa95fe415
Reviewed-on: https://gerrit.libreoffice.org/46193
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Consistently use the #include "..." form for exactly those cases where the
included file is located next to the including file, see the mail thread
starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-October/078601.html>
"C[++]: Normalizing include syntax ("" vs <>)". (For UNO API include files,
see 189abcf0db61c41a565bd355294bf6e712fc3e5a "loplugin:includeform: UNO API
include files".)
(Some of the commits done earlier with messages containing "Change done in
preparation of loplugin:includeform" etc. were based on a somewhat different
earlier version of this plugin and would not be necessary with the current form.
But they are harmless and reverting them would probably cause more noise than
benefit, so just leave them in.)
Change-Id: I9fe9268ed84d31b5df71857a2e535972b11254ce
Reviewed-on: https://gerrit.libreoffice.org/43730
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
<http://reviews.llvm.org/D22128> "Make CastExpr::getSubExprAsWritten look
through implicit temporary under CK_ConstructorConversion" was biting me again.
(I had originally developed loplugin:stringcopy against a Clang build that
includes my local fix for that issue. I really need to see to get that resolved
upstream...)
(And while 957874168491f4b030fda85c65dd969aae82a670 "loplugin:stringcopy" was
actually a false positive, it doesn't hurt either, so just keep it.)
Change-Id: I726956adfbe67681005173cfdfed2e4b4cd6253d
"SourceManager::isMacroArgExpansion has only one param in older Clang", which
caused false positives like warning about sal_False in
CPPUNIT_ASSERT_EQUAL(guard.p->m1, sal_False);
in cppu/qa/cppumaker/test_cppumaker.cxx
Change-Id: I1c5a67527aef381e336d71cb8fefbb87961bbf96
Fix errors that occur in build with clang 3.7.0
Change-Id: I0e8743f2b6a288d10b4e78e884ce34cfca4dd77c
Reviewed-on: https://gerrit.libreoffice.org/18738
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
introduced by commit c15b4cf39a74176cee64795129d76f411d2c0a69
"Adapt to current Clang trunk towards 3.7"
Change-Id: I00f58d3bc79e641df9bba4e9b1d5c8463b87dc42
...which appears to be a good heuristic to identify functions that are either
unused or should better be declared just once in an include file. (It also
filters out SAL_DLLPUBLIC extern "C" function definitions, which are most likely
meant to be referenced dynamically via dlsym.)
Change-Id: I7fb78cb836b971791704851535dcfbda2b2f5bc0
...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
