...0bf61855164af5751e78ca8626c10d604b1ab13b, which should be obsolete now: It
speculated why 05a337e297 "loplugin:useuniqueptr
look for deleting in loops with iterators" had introduced Foo24 in
compilerplugins/clang/test/useuniqueptr.cxx wrapped in
#if CLANG_VERSION >= 50000
and came to the conclusion that "either the old compiler lacked Clang's recent
<https://reviews.llvm.org/D50666> "Fix Stmt::ignoreImplicit" (and the above
initialization expression happens to include a CXXBindTemporaryExpr, at least
with libstdc++), or an even older compiler was used in pre-C++17 mode". But
both of those potential reasons should be moot now, as the Clang fix got
introduced towards Clang 8, and LO requires C++17 now (except for 3rd-party
code).
Change-Id: I307afbbecc5f031bca2319c4b22d54bd467eac81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130116
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(as discussed in the commit message of ce1d8e20a7
"Adapt to '[ADT] Make StringRef's std::string conversion operator explicit'";
there are more of those that cannot easily be dropped, though).
Change-Id: Ib2e223f7de96ad8859eab165daa759b480326c7b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88582
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...<https://github.com/llvm/llvm-project/commit/
777180a32b61070a10dd330b4f038bf24e916af1>. This is just a quick fix to get
copmilerplugins buiding again with latest LLVM/Clang trunk. Ideally, we should
get rid of as many of those (potentially expensive) conversions from
llvm::StringRef to std::string as possible.
Change-Id: I18e185e0022a06fd8e3b983a3c4f80e1f3b96746
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87682
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...where it failed with
> error: 'error' diagnostics expected but not seen:
> File C:/lo-clang/core/compilerplugins/clang/test/useuniqueptr.cxx Line 266: rather manage this var with std::some_container<std::unique_ptr<T>> [loplugin:useuniqueptr]
> File C:/lo-clang/core/compilerplugins/clang/test/useuniqueptr.cxx Line 275: rather manage this member with std::some_container<std::unique_ptr<T>> [loplugin:useuniqueptr]
apparently due to differences in how some std types are implemented.
Change-Id: Ib81ed1a1da867359e7f22bb6fb6ceb3e610e2b41
Reviewed-on: https://gerrit.libreoffice.org/67226
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...where CompilerTest_compilerplugins_clang failed in
compilerplugins/clang/test/useuniqueptr.cxx due to Foo24's
HTMLAttrs::const_iterator it = m_aSetAttrTab.begin();
and either the old compiler lacked Clang's recent
<https://reviews.llvm.org/D50666> "Fix Stmt::ignoreImplicit" (and the above
initialization expression happens to include a CXXBindTemporaryExpr, at least
with libstdc++), or an even older compiler was used in pre-C++17 mode, so the
above initialization expression happens to include an elidable CXXConstructExpr
copy constructor call.
Change-Id: I757a9ad76829e399b4fe2da1c82863909b8c9657
Reviewed-on: https://gerrit.libreoffice.org/61531
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...after 05a337e297 "loplugin:useuniqueptr look
for deleting in loops with iterators", where it didn't emit the warning for
Foo24 in compilerplugins/clang/test/useuniqueptr.cxx during
CompilerTest_compilerplugins_clang, because in the initialization of
HTMLAttrs::const_iterator it = m_aSetAttrTab.begin();
the HTMLAttrs::const_iterator CXXConstructExpr happens to have a second,
defaulted argument.
Change-Id: I882a6dfb5cab1b147f790072f2545b13172c0f9a
Reviewed-on: https://gerrit.libreoffice.org/61530
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
I seem to have missed quite a few in
commit 9f4d23c151
filter out some of the AST in the plugins
This nets me another 14% improvement
Change-Id: I39b980b49ced560f768045dbedd3ddfef29306c1
Reviewed-on: https://gerrit.libreoffice.org/59501
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which first added alternative names to and then deprecated getLocBegin/End
Change-Id: Iaefb8ce259057abfa6cd20f0b63c0ef2949a96b2
Reviewed-on: https://gerrit.libreoffice.org/58820
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
There are some problems here, this should fix one of them: the
getFilename function returns "<stdin>" for spelling locations, because
the input to clang is sort of preprocessed via -frewrite-includes if
icecream is used and the file is built on a remote host (whereas it's
apparently not preprocessed if the file is compiled locally by icecream).
Using getPresumedLoc() uses the #line directives in the preprocessed
input, which avoids the problem but is more expensive, so try to use it
only when necessary.
The getFileEntry(getMainFileID())->getName() pattern will also result
in "<stdin>", but fortunately icecream passes -main-file-name,
which oddly enough isn't used by the SourceManager's spelling locations,
but is available separately via CodeGenOptions.
This builds everything successfully with clang version 6.0.0:
ICECC_PREFERRED_HOST=myremote make check gb_SUPPRESS_TESTS=t
Change-Id: Ic121511683e5302d7b9d85186c8b9c4a5443fa1b
Reviewed-on: https://gerrit.libreoffice.org/54993
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
which is often a useful indicator that the callers can be made to use
std::unique_ptr
Change-Id: Idb1745d1f58dbcf389c9f60f1a5728d7d092ade5
Reviewed-on: https://gerrit.libreoffice.org/56238
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
