...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>
This reverts commit 9f0484c2bc.
Reason for revert: this patch was unnecessary, the operator<< for css::uno::Exception alreadys logs the message, I got confused
Change-Id: I45932be060059eac92d460a70c944e1b19b5c375
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116706
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/
Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Renaming all README files for all top level modules to README.md,
applying no content change at this stage to be able to track history
of the files. These files should be edited to use correct Markdown
syntax later.
Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
760980b0b5 "Fix typos" had, IMO incorrectly,
removed one "that" from
..., so that that asynchronous request would...
Lets rephrase the original comment in a less problematic way.
Change-Id: Ic13ffaad43e2777eb36425363851b53f2f641865
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97087
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Abandoned <b9ecec7c74687ed5a9470cffb7d02e0e6e83107e> "Don't call out to UNO with
SolarMutex locked" documents a deadlock where a synchronous
documentEventOccurred call made with SolarMutex locked evokes an asynchronous
release call back (serviced on a different physical thread, but which blocks the
original thread) that then wants to acquire the SolarMutex. While we usually
appear to get away with wrapping those UNO calls in SolarMutexReleaser (though
knowing all too well that that is nothing but a bad hack that may well cause
crashes and deadlocks at least in theory), the place in
SfxBaseModel::postEvent_Impl was obviously too sensitive for that hack: It did
cause enough different crashes (e.g., hitting
assert(pSchedulerData == pMostUrgent);
in Scheduler::ProcessTaskScheduling, vcl/source/app/scheduler.cxx) and deadlocks
(e.g., different threads now taking the SolarMutex and JobExecutor's mutex in
framework/source/jobs/jobexecutor.cxx in different orders) to make me search for
a different "fix", so I came up with this hack instead.
Change-Id: Icd26926279cb86ce529edb4544a3ec0bc9a8b108
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96946
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
<https://wiki.openoffice.org/wiki/Uno/Remote/Specifications/Uno_Remote_Protocol#
The_queryInterface_Message> specifies that this shall return an ANY either of
type VOID (so handle that) or of type css.uno.XInterface with non-null value (so
throw exceptions for any other kinds of return values).
Various Linux Jenkins builds had recently started to sporadically fail during
UITest_calc_demo, hitting the
assert(
type.get()->eTypeClass == typelib_TypeClass_ANY ||
type.equals(css::uno::TypeDescription(data_.pType)));
in the call to binaryurp::BinaryAny::getValue (binaryurp/source/binaryany.cxx),
e.g. <<https://ci.libreoffice.org/job/lo_tb_master_linux_dbg/29831/>. While it
is unclear why those failures happen, they highlight that this code did not
properly handle all possible (valid or invalid) input.
Change-Id: I95db574aa102ff75fa22fd24c697a0cfa24b7aff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95527
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
"Find explicit casts from signed to unsigned integer in comparison against
unsigned integer, where the cast is presumably used to avoid warnings about
signed vs. unsigned comparisons, and could thus be replaced with
o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx)
o3tl::make_unsigned requires its argument to be non-negative, and there is a
chance that some original code like
static_cast<sal_uInt32>(n) >= c
used the explicit cast to actually force a (potentially negative) value of
sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the
cast to avoid a false "signed vs. unsigned comparison" warning in a case where
n is known to be non-negative. It appears that restricting this plugin to non-
equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=)
is a useful heuristic to avoid such false positives. The only remainging false
positive I found was 0288c8ffec "Rephrase cast
from sal_Int32 to sal_uInt32".
But which of course does not mean that there were no further false positivies
that I missed. So this commit may accidentally introduce some false hits of the
assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan
--enable-dbgutil) `make check && make screenshot`.
It is by design that o3tl::make_unsigned only accepts signed integer parameter
types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses
which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in
include/oox/helper/helper.hxx is used with both signed and unsigned types, so
needs a little oox::detail::make_unsigned helper function for now. (The
ultimate fix being to get rid of the macro in the first place.)
Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
comment from sberg:
aren't these changes broken in general, when the called function
may throw an exception before it takes ownership of the passed-in pointer?
So revert, except for
(a) PlainTextFilterDetect::detect, which was definitely a leak
(b) SwCursor::FindAll, where unique_ptr was being unnecessarily used
This reverts commit 7764ae70b0.
Change-Id: I555e651b44e245b031729013d2ce88d26e8a357e
Reviewed-on: https://gerrit.libreoffice.org/60301
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
most of these changes just make the change of ownership when using
std::unique_ptr clearer, but there is one definite leak fix in
PlainTextFilterDetect::detect
Change-Id: I8282a68007222a4fee84004f394bde0cca8569e9
Reviewed-on: https://gerrit.libreoffice.org/60159
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
where used directly, since rtl_allocateMemory now just calls into std::malloc
Change-Id: I59f85bdb7efdf6baa30e8fcd2370c0f8e9c999ad
Reviewed-on: https://gerrit.libreoffice.org/59685
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Arnaud Versini