...that had been missing because the plugin didn't implement postRun, so it
didn't report anything when run as part of the shared plugin. (But did report
the expected warnings when run as a standalone plugin during
CompilerTest_compilerplugins_clang.)
Most fixes are straightforward. A noteworthy one is PreparedStatement::setBytes
in connectivity/source/drivers/postgresql/pq_preparedstatement.cxx: The old
preallocation of a 20 character OStringBuffer might have prevented
buf.append( reinterpret_cast<char *>(escapedString), len -1 );
from potentially throwing std::bad_alloc, which would have caused escapedString
to be leaked. Even though that 20-character preallocation was likely just
random junk and not meant to address the potential leak, lets address it now.
Change-Id: Ib506332d061684a22a74e5e39e591539fd2c4900
Reviewed-on: https://gerrit.libreoffice.org/80925
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It started out as a wrapper around character literals, but has by now become a
wrapper around arbitrary single characters. Besides updating the documentation,
this change is a mechanical
for i in $(git grep -Fl OUStringLiteral1); do sed -i -e s/OUStringLiteral1/OUStringChar/g "$i"; done
Change-Id: I1b9eaa4b3fbc9025ce4a4bffea3db1c16188b76f
Reviewed-on: https://gerrit.libreoffice.org/80892
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
and extend O*StringView to have a constructor that takes a pointer and a
length
Change-Id: I6120e96280f030757e855a6596efdae438b7e1e8
Reviewed-on: https://gerrit.libreoffice.org/80872
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...after 9b5dad13b56bdde7c40970351af3da3a2c3c9350 "loplugin:stringadd look for
unnecessary temporaries". There was no reason to check for implicit
MaterializeTemporaryExpr instead of explicitly written CXXFunctionalCastExpr,
and checking for the latter makes it easier to report the casted-from type,
which gives useful information how to change code that exhibits the warning.
See the comments at <https://gerrit.libreoffice.org/#/c/80724/>
"loplugin:stringadd look for unnecessary temporaries" for details.
(And while at it, remove some commented-out debug code that is probably no
longer relevant now.)
Change-Id: I7d4cab85432885d617dd7114c75163c1eb376fc2
Reviewed-on: https://gerrit.libreoffice.org/80823
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This currently supports only building with Clang on Linux, as
I'm lazy to handle the other cases (and Clang should be usually
self-built anyway). The main compile time cost is in optimizing
the code, but this still saves few seconds per source.
Change-Id: Ib6c0fd874820af737ee1257cb5234fb78bc63ad8
Reviewed-on: https://gerrit.libreoffice.org/80810
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
look for OUStringBuffer append sequences that can be turned
into creating an OUString with + operations
Change-Id: Ica840dc096000307b4a105fb4d9ec7588a15ade6
Reviewed-on: https://gerrit.libreoffice.org/80809
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...to find matches of
... << s.getStr()
(for the rtl string classes) that can be written as just
... << s
Some notes:
* The OUStringToOString(..., RTL_TEXTENCODING_UTF8) is left explicit in
desktop/source/app/crashreport.cxx (even though that would also be done
internally by the "<< OUString" operator) to clarify that these values are
written out as UTF-8 (and not as what that operator << happens to use, which
just also happens to be UTF-8).
* OUSTRING_TO_CSTR (include/oox/helper/helper.hxx) is no longer used now.
* Just don't bother to use osl_getThreadTextEncoding() in the SAL_WARN in
lingucomponent/source/hyphenator/hyphen/hyphenimp.cxx.
* The toUtf8() in the SAL_DEBUG in pyuno/source/module/pyuno_module.cxx can just
go, too.
Change-Id: I4602f0379ef816bff310f1e51b57c56b7e3f0136
Reviewed-on: https://gerrit.libreoffice.org/80762
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which defeat the *StringConcat optimisation.
Also make StringConcat conversions treat a nullptr as an empty string,
to match the O*String(char*) constructors.
Change-Id: If45f5b4b6a535c97bfeeacd9ec472a7603a52e5b
Reviewed-on: https://gerrit.libreoffice.org/80724
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Required a workaround for loplugin:indentation, until
<https://reviews.llvm.org/D68581> "Include leading attributes in DeclStmt's
SourceRange" lands in Clang.
Change-Id: I7192969d40fa4c50bbd603d059532b9344865248
Reviewed-on: https://gerrit.libreoffice.org/80596
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...when the get member function is implemented in a base class, as happens for
std::shared_ptr in libstdc++ (where it is implemented in base __shared_ptr; see
also 7d361e96c9ea822790db21806e9fc05279423833 "loplugin:redundantpointerops").
And while at it, check for precisely the classes we are interested in (for which
we know the semantics of get and operator*), rather than any classes whose
unqualified names happen to match.
Change-Id: I0c85ba46f191a2ee038c8175d979aa0c1be765cd
Reviewed-on: https://gerrit.libreoffice.org/80585
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
as well as unique_ptr
Change-Id: I54842bca161ee460fb96c46ca31b6f9c0a7dbbdf
Reviewed-on: https://gerrit.libreoffice.org/80455
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The function is not just about a spelling location.
Change-Id: I96e9e9ef7e27a9763397b4b86473c1c30d0e3eeb
Reviewed-on: https://gerrit.libreoffice.org/80381
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
...to complement and improve upon GCC's -Wclass-memaccess. See the comment at
the head of compilerplugins/clang/classmemaccess.cxx for details. (It is not
yet clear to me whether we would want to get this upstreamed into Clang.)
35d21e4bf6f66b3bbc7a44fcf184cb721b524a94 "Remove redundant memsets" was a case
that benefited from looking through toplevel casts to void*. (Though the code
in include/basic/sbxvar.hxx needs a slightly more verbose way to deliberately
silence the warning now.)
d03041e19215592f21ba1222d3cfa29e1f94260a "Drop bogus memsets" is one example of
various cases that GCC -Wclass-memaccess failed to catch due to the use of array
instead of pointer types.
Change-Id: I6a9bfc34e3536834af35fdf4fb7ceeb31f31f8c0
Reviewed-on: https://gerrit.libreoffice.org/80421
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Instead of having a lot of it hardcoded, which brings problems like:
- Clang-to-be-10 has switched to -std=c++14, so our hardcoded c++11
makes the build fail
- I cannot compile with my openSUSE-shipped clang, because it ships
only libclang-cpp and not the other libClangSomething libs
The possibility to explicitly set the necessary variables is still there.
Change-Id: I58d401d4584fa064f1c1351a8a06ff4e29643063
Reviewed-on: https://gerrit.libreoffice.org/80300
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
These are triggered when using llvm-config --cxxflags for building,
and sometimes there's -Werror. The warnings were mostly unused
variables because of being used only in assert(), or default case
in switch that covers all enums (it's better to not handle default
to get warning if a case is not handled).
Change-Id: I0ecdd1f27390aadf033852b0d1ee0ca424ae3c37
Reviewed-on: https://gerrit.libreoffice.org/80317
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This is a continuation of ff002524c12471668e63837a804b6006f9136a34.
When compiling with icecream, its -frewrite-includes merges
all #include's into one .cxx file and marks them with with line
markers. But SourceManager::getFilename() doesn't take those
into account and so it reports all of those as <stdin>.
So use getFileNameOfSpellingLoc(), which explicitly handles this
case.
And we should probably never ever use SourceManager::getFilename().
Change-Id: Ia194c2e041578e1e199aee2df2f885922ef7e31a
Reviewed-on: https://gerrit.libreoffice.org/80326
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
There is nothing catching the exception anyway, and this fails
to compile if compiling the plugin with Clang's CXXFLAGS (which
include -fno-exceptions).
Change-Id: Iad9316ad9613e4fd66d0e5a16fd71bbb8066cc2b
Reviewed-on: https://gerrit.libreoffice.org/80299
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
and filter out the weld fields, since we're not touching them yet
Change-Id: I3cc23c46d2650f13cb29c7d381687939d23e2882
Reviewed-on: https://gerrit.libreoffice.org/80104
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
look for places where we can replace sequential additions to
OUString/OString with one concatentation (i.e. +) expression, which is
more efficient
Change-Id: I64d91328bf64828d8328b1cad9e90953c0a75663
Reviewed-on: https://gerrit.libreoffice.org/79406
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which can happen for function templates with clang-cl, leading to false
warnings like
> [build CXX] codemaker/source/commoncpp/commoncpp.cxx
> In file included from codemaker/source/commoncpp/commoncpp.cxx:25:
> In file included from include\codemaker/typemanager.hxx:28:
> include\rtl/ref.hxx(126,5): error: move operator= can be noexcept [loplugin:noexceptmove]
> Reference<reference_type> &
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: I541c7c3d86d05964834e3e5cf678c8f1145ea132
Reviewed-on: https://gerrit.libreoffice.org/79956
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(which appears to be unused and caused compilation failure on Windows)
Change-Id: Ice6882d98da3bac1f53e869b73ab179df93280fa
Reviewed-on: https://gerrit.libreoffice.org/79925
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Apply the constmethod plugin, but only to accessor-type methods, e.g.
IsFoo(), GetBar(), etc, where we can be sure of that
constifying is a reasonable thing to do.
Change-Id: Ibc97f5f359a0992dd1ce2d66f0189f8a0a43d98a
Reviewed-on: https://gerrit.libreoffice.org/74269
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
