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>
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>
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>
To complete this:
https://gerrit.libreoffice.org/#/c/78312/
This is a massive replace for lines ending with
".." instead of "..."
It passed "make check" on Linux.
Change-Id: I07fa7b2e30ba9ea17a1f9a5e21c57216ba958efe
Reviewed-on: https://gerrit.libreoffice.org/78356
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
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
ad4c7b97752b4da73808402604d6f96b39d920f5 "Avoid declaring function templates in
namespace std"
042e30a3dc057aef4a02d95960e4dd4fb8d083ae "Avoid adding a function template
declaration to namespace std"
cae9240a76cdb0eeed92421930d3b4cbef0ac201 "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>
...from
> sfx2/source/appl/shutdowniconaqua.mm:416:13: error: use std::as_const, or make range var const, to avoid creating a copy of the Sequence [loplugin:sequenceloop]
> for ( auto const & newMenuProp : aNewMenu )
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
to
> sfx2/source/appl/shutdowniconaqua.mm:416:46: error: use std::as_const, or make range var const, to avoid creating a copy of the Sequence [loplugin:sequenceloop]
> for ( auto const & newMenuProp : aNewMenu )
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
Change-Id: I1eabe80abeed1784a246a6e3c9b7036f664ee681
Reviewed-on: https://gerrit.libreoffice.org/77989
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(but when targeting older versions of LLVM/Clang, COMPILER_PLUGINS_CXX can still
specify -std=c++11)
Change-Id: I1b91f2817516d015bc12b6a3faf1874ab938a3ae
Reviewed-on: https://gerrit.libreoffice.org/77866
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...<https://github.com/llvm/llvm-project/commit/
0a42fe70a566f22599e04a6f1344ca2dc5565e17> "[AST] Treat semantic form of
InitListExpr as implicit code in traversals"
Change-Id: Ifd17009fcc6933abf0e9178dbe47fb9c14b274b7
Reviewed-on: https://gerrit.libreoffice.org/77595
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
look for places we should be using std::as_const on for-range
loops over uno::Sequence, to avoid triggering a copy
Change-Id: I7efb641bf09d37c87946f03428ee4eec90298c8a
Reviewed-on: https://gerrit.libreoffice.org/77441
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which caused failures like
> [GEN] compilerplugins/clang/sharedvisitor/sharedvisitor.cxx
> In file included from /data/sbergman/lo/core/compilerplugins/clang/badstatics.cxx:14:
> In file included from /data/sbergman/lo/core/compilerplugins/clang/check.hxx:15:
> In file included from /data/sbergman/llvm/inst/include/clang/AST/DeclBase.h:18:
> In file included from /data/sbergman/llvm/inst/include/clang/AST/DeclarationName.h:16:
> In file included from /data/sbergman/llvm/inst/include/clang/AST/Type.h:48:
> /data/sbergman/llvm/inst/include/llvm/Support/TrailingObjects.h:252:24: error: no member named 'is_final' in namespace 'std'
> static_assert(std::is_final<BaseTy>(), "BaseTy must be final.");
> ~~~~~^
[...]
However, unconditionally using -std=c++14 in generator.cxx would cause failures
for builds against older Clang (and with COMPILER_PLUGINS_CXX specifying
-std=c++11) on machines that have an old C++11-only system libstdc++. Those
machines typically use --gcc-toolchain to use a newer non-system libstdc++ (cf.
e.g. setting CC and CXX in lode's bin/linux_clang_dbgutil_64.env), so one
solution could be to propagate such an option from CXX through to generator.cxx.
But the easier fix appears to be to instead propagate the -std option.
Change-Id: Ib081754ce8ad567305d1520e3a1ff6700fb22755
Reviewed-on: https://gerrit.libreoffice.org/77502
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
these don't need to use std::unique_ptr
Change-Id: I03140c7957fd59443db932c37890a6742c6d3bec
Reviewed-on: https://gerrit.libreoffice.org/76800
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
