Similar to what is done in bootstrap_expandUri, expandUnoRcUrl,
UrlReference::expand, JavaLoader.expand_url, and is documented
in XVndSunStarExpandUrl interface.
Change-Id: I65349b52734f212e6a04e615d39fa2563f62d472
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146840
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
SfxObjectShell::Current() can return null, it's based on the equally
vile SfxViewFrame::Current()
Change-Id: Ia5c7783680e9d8e5d3075078f16a2c15cb6f7a47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144339
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
As reported by the user, if you go to Tools - Macro - Run Macro and select the InsertText macro (under Application Macros), you'll get an error.
The reason for this is that the InsertText macro is not meant to be called from the Macro Selector since it requires 1 positional argument.
Therefore, this patch creates a simple callable Python macro that uses the InsertText funcion, so that this error message no longer happens.
Change-Id: I63f766795bda2d2ae1b95a7c0d8110f41f9fbea2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140384
Tested-by: Jenkins
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
...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 local variables that can be std::move'd to parameters
off by default, since it doesn't do proper data flow analysis
Change-Id: I3403a0fcffd165bdea6a772528bc53995c5fdb40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135527
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This reverts commit 418533f0af. Turned out that
closing the given URLClassLoader once the script's main class has been loaded
prevents the script from loading further classes located next to that main
class. So abandon the Coverity suggestion that such class loaders should be
closed promptly to avoid resource leaks.
Change-Id: I1bcf83117836cfe317eac9850d413f2c3767bd8e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135158
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Since commit 506173a7f4
Date Mon Nov 19 13:07:20 2018 +0300
tdf#112536 related: make soffice.bin a proper console application on Win
and commit ab09422405
Date Wed Jan 22 22:13:25 2020 +0300
Make unopkg.com proper launcher for unopkg.bin on Windows
there *is* stderr on Windows, so we can revert commits
a34c9a8065
Date Tue Aug 02 09:52:37 2011 +0100
can't use set_debuglevel under windows
and a1775d69e8
Date Tue Aug 02 09:57:59 2011 +0100
make logging less painful under windows
Change-Id: I5698a69130e55094508d5ca22411e861ffeeed8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131877
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(*) make all the methods that require an external mutex take a
std::unique_lock as a parameter, so that call sites cannot forget
(*) make the forEach method drop the lock when firing listener methods,
to reduce the odds of deadlock
Change-Id: I0a80e3b3d1c1c03b7de4a658d31fcc2847690903
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128415
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
SbxValue::Clear happens to not error out on clearing string and some
other types of objects, but for the rest, it calls SbxValue::Put, and
the latter errors out if not CanWrite(). The original test implemented
in commit 24d24debef only checked string
return value, so happened to miss this problem.
See similar code in SbiRuntime::FindElement.
Change-Id: I7c17137cc9e7ee3133ee86a9f701559df66e53b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127248
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@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>
Unfortunatly we cannot add --disable-scripting to
sub_conf_defaults, because Java currently has no
equivalent to the PYTHON_FOR_BUILD setting.
Change-Id: I89938a17307a363f5de808200914940503312829
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126186
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
...from interface to abstract class, in 1c42afc194
"Respect DisableMacrosExecution option in javascript editor". It caused 3rd-
party code like ScriptProviderForooRexx.oxt to fail to install.
Change-Id: I532f27fdce806e471a8551646adbb3aecf80bcee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123745
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
... to avoid hidden cost of multiple COW checks, because they
call getArray() internally.
This obsoletes [loplugin:sequenceloop].
Also rename toNonConstRange to asNonConstRange, to reflect that
the result is a view of the sequence, not an independent object.
TODO: also drop non-const operator[], but introduce operator[]
in SequenceRange.
Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The scenarios are:
1. Calling sequence's begin() and end() in pairs to pass to algorithms
(both calls use getArray(), which does the COW checks)
2. In addition to #1, calling end() again when checking result of find
algorithms, and/or begin() to calculate result's distance
3. Using non-const sequences in range-based for loops, which internally
do #1
4. Assigning sequence to another sequence variable, and then modifying
one of them
In many cases, the sequences could be made const, or treated as const
for the purposes of the algorithms (using std::as_const, std::cbegin,
and std::cend). Where algorithm modifies the sequence, it was changed
to only call getArray() once. For that, css::uno::toNonConstRange was
introduced, which returns a struct (sublclass of std::pair) with two
iterators [begin, end], that are calculated using one call to begin()
and one call to getLength().
To handle #4, css::uno::Sequence::swap was introduced, that swaps the
internal pointer to uno_Sequence. So when a local Sequence variable
should be assigned to another variable, and the latter will be modified
further, it's now possible to use swap instead, so the two sequences
are kept independent.
The modified places were found by temporarily removing non-const end().
Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
In sc/qa/unit/ucalc_formula.cxx, dropping the capture-default from the
lExpectedinF lambda revealed that MSVC in C++17 mode (i.e., when building
without --with-latest-c++) requires ROW_RANGE (a local const int variable from
the enclosing TestFormula::testTdf97369) to be captured, even though all uses of
that variable within the lambda body are constant expressions. That is still
true at least for the latest Visual Studio 2019 version 16.11.1. (This is not
an issue for the lExpectedinH and lExpectedinI lambdas a few lines further down,
as they, in addition to using that ROW_RANGE, also use the local const double
variables SHIFT1 and SHIFT2, whose uses are not constant expressions, so
they are implicitly captured and loplugin:unusedcapturedefault does not suggest
dropping those lambdas' capture-defaults in the first place.)
Change-Id: Iee7efb485187cbe8eba6a2d470afca4993eb1816
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120693
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Otherwise the function keeps a copy of its return value, which may be
used in an upcoming call.
Change-Id: I4977c39e1ce48cfd5ab067a4df4783f10505a9ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119905
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Mike Kaganski