and
cid#1660344 Variable copied when it could be moved
cid#1660343 Variable copied when it could be moved
cid#1660341 Variable copied when it could be moved
cid#1660339 Variable copied when it could be moved
cid#1660337 Variable copied when it could be moved
cid#1660335 Variable copied when it could be moved
cid#1660334 Variable copied when it could be moved
Change-Id: I3758a4228d5e848750b4ef37296b4d38b5d3e31c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188850
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
assertion:
5 0x00007f0f5578cf2a in ByteGrabber::ByteGrabber (this=0x558123967710, xIstream=uno::Reference to (chelp::XInputStream_impl *) 0x558124099a20)
at /home/julien/lo/libo_perf/package/source/zipapi/ByteGrabber.cxx:44
6 0x00007f0f557a0793 in ZipFile::ZipFile
(this=0x558123967640, aMutexHolder=empty rtl::Reference, xInput=uno::Reference to (chelp::XInputStream_impl *) 0x558124099a20, xContext=uno::Reference to (cppu::(anonymous namespace)::ComponentContext *) 0x558121aacc48, bInitialise=true, bForceRecovery=false, checks=ZipFile::Checks::Default) at /home/julien/lo/libo_perf/package/source/zipapi/ZipFile.cxx:90
7 0x00007f0f5580208d in std::_Construct<ZipFile, rtl::Reference<comphelper::RefCountedMutex>&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream>&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool, bool&, ZipFile::Checks> (__p=0x558123967640) at /usr/include/c++/14/bits/stl_construct.h:119
8 0x00007f0f557ffb2d in std::_Optional_payload_base<ZipFile>::_M_construct<rtl::Reference<comphelper::RefCountedMutex>&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream>&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool, bool&, ZipFile::Checks> (this=0x558123967640) at /usr/include/c++/14/optional:274
9 0x00007f0f557fd87d in std::_Optional_base_impl<ZipFile, std::_Optional_base<ZipFile, false, false> >::_M_construct<rtl::Reference<comphelper::RefCountedMutex>&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream>&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool, bool&, ZipFile::Checks> (this=0x558123967640) at /usr/include/c++/14/optional:455
10 0x00007f0f557f9186 in std::optional<ZipFile>::emplace<rtl::Reference<comphelper::RefCountedMutex>&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream>&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool, bool&, ZipFile::Checks> (this=0x558123967640) at /usr/include/c++/14/optional:916
11 0x00007f0f557e63f3 in ZipPackage::initialize (this=0x558123967510, aArguments=uno::Sequence of length 2 = {...}) at /home/julien/lo/libo_perf/package/source/zippackage/ZipPackage.cxx:893
12 0x00007f0f876d6b87 in cppuhelper::ServiceManager::Data::Implementation::doCreateInstanceWithArguments
(this=0x558121b4fd80, context=uno::Reference to (cppu::(anonymous namespace)::ComponentContext *) 0x558121aacc48, arguments=uno::Sequence of length 2 = {...})
at /home/julien/lo/libo_perf/cppuhelper/source/servicemanager.cxx:728
13 0x00007f0f876d6884 in cppuhelper::ServiceManager::Data::Implementation::createInstanceWithArguments
(this=0x558121b4fd80, context=uno::Reference to (cppu::(anonymous namespace)::ComponentContext *) 0x558121aacc48, singletonRequest=false, arguments=uno::Sequence of length 2 = {...})
at /home/julien/lo/libo_perf/cppuhelper/source/servicemanager.cxx:690
14 0x00007f0f876d9860 in cppuhelper::ServiceManager::createInstanceWithArgumentsAndContext
(this=0x558121ab2c10, ServiceSpecifier="com.sun.star.packages.comp.ZipPackage", Arguments=uno::Sequence of length 2 = {...}, Context=uno::Reference to (cppu::(anonymous namespace)::ComponentContext *) 0x558121aacc48) at /home/julien/lo/libo_perf/cppuhelper/source/servicemanager.cxx:1015
15 0x00007f0f5552856d in chelp::Databases::jarFile (this=0x55812318ee80, rGuard=..., jar=u"shared.jar", Language="fr") at /home/julien/lo/libo_perf/xmlhelp/source/cxxhelp/provider/databases.cxx:842
16 0x00007f0f5552c519 in chelp::JarFileIterator::nextJarFile (this=0x7ffc4d067e80, rGuard=..., o_xParentPackageBundle=empty uno::Reference, o_pExtensionPath=0x0, o_pExtensionRegistryPath=0x0)
at /home/julien/lo/libo_perf/xmlhelp/source/cxxhelp/provider/databases.cxx:1593
See almost full bt here:
https://bugs.documentfoundation.org/attachment.cgi?id=200590&action=edit
The way to retrieve the zip content (Jar is a zip) since the stream didn't implement comphelper::ByteReader.
Instead of changing XInputStream_impl to implement it, I thought it could be interesting to copy a bulletproof way
from by using ZipPackageHelper in unotools/source/misc/ZipPackageHelper.cxx
m_aZipFileTable is now completely useless (BTW compilerplugins/clang/unusedfields.writeonly.results already indicated
that the member was only written)
If if it works well, we could get rid of xmlhelp/source/cxxhelp/provider/inputstream.hxx and cxx associated.
Change-Id: Ie9c3b5808c835206830e87b129efcdf98ba505af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184732
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
found by a little plugin I created.
Plugin parked into store/ folder because it needs hand-holding
when run.
Change-Id: I2b4da7378f0becbc5f020ac9e78cd765aa0119b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181768
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
we can just take a "const &".
(found by running clang-tidy with the
performance-unnecessary-copy-initialization warning)
Change-Id: I20fd208c65303da78170b1ac06c638fdf3aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176267
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
This code does not appear to be handling the case where there
is no anchor correctly, all the way back to
commit c5718b9414
Author: Andreas Bille <abi@openoffice.org>
Date: Wed Oct 31 12:08:14 2001 +0000
#83054#
Now reading the necessary variables( provider.cxx ),
Change-Id: Ia8f514a95ca2e3ae17129b34f0ed444cd9d0ade8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174122
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Add new overloads to OUString methods that have a
"OUString* rest" style parameter.
Instead return a view, which does not require allocation.
To avoid overload ambiguity, split the methods into
different variants that do not use default parameters.
Change-Id: I1aa366115750f1f7ea4fe665804195f59f7c4b69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167632
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Most of these don't use boost themselves, nor do they need
it transitively since the use of boost::optional was removed
Change-Id: Ic9dee1c4e160b313ec5b91677b02ffdea6c5779d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164440
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
OStringLiteral represent read-only memory for string literal while
OUString is a dynamic string class with reference counting
hence use OUString when you need reference counting, string
manipulation along with _ustr suffix.
Change-Id: Ib566df156d81c7527f5650bcc6bd5db6509128cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162911
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
(which also makes readInt32 report failure, instead of running into UB, when the
read value is out of range)
Change-Id: I8449e4fe696c9b0ab5b868127ef517dc080c31ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158489
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
look for call sequences that can use string_view and the new o3tl
functions in o3tl/string_view.hxx
Also add a few more wrappers to said #include file
Change-Id: I05d8752cc67a7b55b0b57e8eed803bd06bfcd9ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132840
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
It's used only for the ConfigurationWrapper singleton, so it's used
only the first time and then ignored. It also causes calls to
comphelper::getProcessComponentContext() for every single invocation
despite the value not being needed, and the calls may not be cheap
(it's ~5% CPU during ODS save because relatively frequent calls
to officecfg::Office::Common::Save::ODF::DefaultVersion::get()).
Change-Id: I02c17a1a9cb498aeef220ddd5a0bde5523cb0ffb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131056
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
...instead of by listing the content somewhat redundantly in the Rdb_*.mk
files, to avoid duplication of logic for components that are only built
conditionally (and thus should only be included conditionally in the
corresponding Rdb). To achieve that, add an "rdb" parameter to
gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros
that internally call gb_ComponentTarget_ComponentTarget), which is used to make
the appropriate gb_Rdb_add_component call internally from within
gb_ComponentTarget_ComponentTarget. (As a special case,
gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that
has already been done by the corresponding gb_Library_set_componentfile call, so
allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to
support that special case.)
Most Rdb_*.mk files are thus mostly empty now. One exception is
i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as
needed during the build in CustomTarget_i18npool/localedata.
1c9a40299d "gbuild: create services.rdb from built
components" had already tried to do something similar (in addition to other
things) under a new --enable-services-rdb-from-build option. However, that
approach had four drawbacks that this approach here addresses (and which thus
partly reverts 1c9a40299d):
1 Rdb_services shall not contain the component files of all libraries that are
built. While that commit filtered out the component files that go into
Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files
that go into others like Rdb_postgresql-sdbc
(connectivity/Rdb_postgresql-sdbc.mk).
2 The code added by that commit to Makefile.gbuild codified the knowledge that
there is an Rdb_services, which is brittle.
3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge
(for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle.
4 Introducing an --enable-services-rdb-from-build option needlessly provided
two different ways how the content of Rdb_services is assembled.
The changes done here would leave --enable-services-rdb-from-build as a
misnomer, as it no longer controls how Rdb_services is assembled. I thus
renamed it to --enable-customtarget-components, as that is apparently what it
still does now.
Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Caolán McNamara