...of <http://llvm.org/viewvc/llvm-project?view=revision&revision=331155>
"PR37189 Fix incorrect end source location and spelling for a split '>>' token",
changing (among others) the return type of getImmediateExpansionRange from a
std::pair of token locations to CharSourceRange (which will typically also
represent token locations, but might also represent char locations).
For now, map the return value of getImmediateExpansionRange back to a std::pair
(as expected by our compilerplugins code in its current form), and mark the
char location case with a TODO (which will need to be addressed if any of our
plugins starts to produce wrong results due to not handling that char location
case). In the long run, we should instead adapt our code to use the new return
type of getImmediateExpansionRange directly.
Change-Id: Idc2f5dc43830af4798b55bf605976c4ab146c522
Reviewed-on: https://gerrit.libreoffice.org/53817
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 189abcf0db "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 9578741684 "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
...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
