...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>
to look for virtual methods where all of the implementations of that
method do nothing useful
Change-Id: I623456ade1c55fe8048d23f69cb692540378daa4
Reviewed-on: https://gerrit.libreoffice.org/79579
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
"make range var const" sounded to me like it talked about the variable declared
in the for-range-declaration, not a variable referenced in the for-range-
initializer
Change-Id: Ie777e1374ead7f37c8efb022cd87e980d2ee9810
Reviewed-on: https://gerrit.libreoffice.org/79563
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
When I did the fast string concatenation, I didn't add any support
for number(), which simply returned a O(U)String, and so it did
the extra allocation/deallocation, although that could be avoided.
In order to support this, number() now returns a special temporary
return type, similarly to O(U)StringConcat, which allows delaying
the concatenation the same way.
Also similarly, the change of the return type in some cases requires
explicit cast to the actual string type. Usage of OString::getStr()
is so extensive in the codebase that I actually added it to the helper
class, after that it's only relatively few cases.
Change-Id: Iba6e158010e1e458089698c426803052b6f46031
Reviewed-on: https://gerrit.libreoffice.org/78873
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Something like auto str = "string" + OUString::number( 10 ); will
not be OUString but actually rtl::OUStringConcat (which gets implicitly
converted to OUString, but not with auto). Since those refer to temporaries
from the expression, they should not outlive the expression.
Change-Id: Ib4cde4b38befb3d49927d0cf01c52ebb2d36df89
Reviewed-on: https://gerrit.libreoffice.org/78830
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Testcase: Remove any reference to LO_CLANG_SHARED_PLUGINS from e.g.
blockblock.cxx, sharedvisitor.cxx should get regenerated.
Change-Id: Iddff3cf41c223cfdf161060d29bde9df1df7b702
Reviewed-on: https://gerrit.libreoffice.org/79194
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Where the problem was benign and the class was not extended, I marked
the class as final.
Where the problem was benign and the class was extended, I marked the
relevant callee methods as final.
Other cases were excluded in the plugin.
Change-Id: Idb762fb2206af4e8b534aa35ff77f8368c7909bc
Reviewed-on: https://gerrit.libreoffice.org/79089
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
as pointed out by mike kaganski:
the 'aCellStr + u"\x0001"' expression gives an OUStringConcat which
holds the references to the strings and doesn't allocate any memory; the
OUStringBuffer has a dedicated overload of append() for the
OUStringConcat, which allocates only once for the combined concat length
and then copies everything from the concat, instead of doing the append
twice for each element... why the strange warning for a more efficient
method?
Change-Id: I6492e99c335e2375cfe78547a87b3079a86890f0
Reviewed-on: https://gerrit.libreoffice.org/79036
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...in the same spirit as how COMPILER_PLUGINS_TOOLING_ARGS had been introduced
with ad7e2af4ed "Allow to pass additional options
into generator's clang::tooling": For one,
ceb26770b3 "split clangplugins sharedvisitor
generator into two steps" should have passed COMPILER_PLUGINS_TOOLING_ARGS only
into the analyzer and not into the generator executable, while for another, at
least my local build failed with
> [PCH] compilerplugins/clang/sharedvisitor/clang.pch
> In file included from /Users/stephan/Software/lo/core/compilerplugins/clang/sharedvisitor/precompiled_clang.hxx:12:
> In file included from /Users/stephan/Software/lo/core/compilerplugins/clang/sharedvisitor/../plugin.hxx:15:
> In file included from /Users/stephan/Software/llvm/inst/include/clang/AST/ASTContext.h:18:
> In file included from /Users/stephan/Software/llvm/inst/include/clang/AST/ASTTypeTraits.h:19:
> In file included from /Users/stephan/Software/llvm/inst/include/clang/AST/Decl.h:16:
> In file included from /Users/stephan/Software/llvm/inst/include/clang/AST/APValue.h:16:
> In file included from /Users/stephan/Software/llvm/inst/include/clang/Basic/FixedPoint.h:19:
> In file included from /Users/stephan/Software/llvm/inst/include/llvm/ADT/APSInt.h:17:
> In file included from /Users/stephan/Software/llvm/inst/include/llvm/ADT/APInt.h:18:
> In file included from /Users/stephan/Software/llvm/inst/include/llvm/Support/Compiler.h:21:
> In file included from /Users/stephan/Software/llvm/inst/bin/../include/c++/v1/new:90:
> In file included from /Users/stephan/Software/llvm/inst/bin/../include/c++/v1/exception:81:
> In file included from /Users/stephan/Software/llvm/inst/bin/../include/c++/v1/cstdlib:85:
> /Users/stephan/Software/llvm/inst/bin/../include/c++/v1/stdlib.h:97:15: fatal error: 'stdlib.h' file not found
> #include_next <stdlib.h>
> ^~~~~~~~~~
after dc79dc76f1 "make clangplugin analyzer use internally a PCH to speed things up".
Change-Id: I4aa925049dbc145c672cad7cab2043a0f13780fa
Reviewed-on: https://gerrit.libreoffice.org/79028
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This generally makes the sharedvisitor performance reasonable.
The only costly thing that remains is compiling the large sharedvisitor.cxx,
which with optimizations takes quite some time, but there's ccache for that.
Change-Id: Iffa5fc9df34cdb5edf1cde34fc558fd007ef8263
Reviewed-on: https://gerrit.libreoffice.org/78569
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Analysing all the plugin sources using just one process takes a lot of time,
so split out a separate analyzer tool that'll analyse one source and
print out the data to a .plugininfo file. The generator then will read
all of these and generate sharedvisitor.cxx . This allows parallelising
the expensive analysis.
With this commit sharedvisitor.cxx is no longer included in the repository,
as this and the next commit should make the generation fast enough.
Change-Id: Idfc33c4ea6ccfd84f829b51001c8ddeb0be09961
Reviewed-on: https://gerrit.libreoffice.org/78568
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
...for reliable results across Clang versions. Also, there appears to be no
need to check for CXXTemporaryObjectExpr both before and after IgnoreImplicit.
Change-Id: Ib804591b6d50073c99680d0933e21f32bba29342
Reviewed-on: https://gerrit.libreoffice.org/78640
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which required including config_host in generator, which in turn
required adapting the makefile
Change-Id: Icafa3b59816f52c349fbbd76ce71305856c9ce33
Reviewed-on: https://gerrit.libreoffice.org/78293
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
idea from mike kaganski
look for places where we can mark move operators as noexcept, which
makes some STL operations more efficient
Change-Id: Id732b89d1fcadd5ceb0ea2b9d159fed06136330f
Reviewed-on: https://gerrit.libreoffice.org/78251
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...finding dubious additions to namespace std (concentrating on functions for
now). C++17 [namespace.std]/1: "The behavior of a C ++ program is undefined if
it adds declarations or definitions to namespace std or to a namespace within
namespace std unless otherwise specified."
This found
ad4c7b9775 "Avoid declaring function templates in
namespace std"
042e30a3dc "Avoid adding a function template
declaration to namespace std"
cae9240a76 "Avoid adding a function declaration to
namespace std"
Change-Id: Ic2ba54e2a8bf931d5c58cedf499c0d1229eb2166
Reviewed-on: https://gerrit.libreoffice.org/78220
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
