SbxValue::SetType clears the original value. We need to use the Get/Put
cycle, asking for a specific type in Get, and then making sure that the
variable is not fixed on Put.
Change-Id: I0a6c106d511e8491c89a5a2153f47a708f83ee1e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162664
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The "ehlo" calls look redundant, smtplib will do these implicitly if
required (checked in Python 3.5.9); it will also check that the STARTTLS
is successful which very old versions of Python didn't do.
Change-Id: Ice8b24bc2c9773c1171e856f1aefb191b1e2e947
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159078
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
This reverts commit 7fc6063914.
sberg noticed that there is a difference now:
there's a subtle difference now, in that if y was null originally, it would have thrown a (caught) exception, whereas now it will crash in the y.query<X>() call.
Change-Id: Idbb5a08d635d15b5ca63f4822eddf05fb0a5afa0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156002
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The vnd.sun.star.expand: payload must be URL-decoded prior to passing
it to expandMacros; the protocol must be checked case-insensitively.
Use startsWithIgnoreAsciiCase for that.
Change-Id: I2be993a0400a27cb7dc57207cd0824b4505afd2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146855
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
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>
...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>
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>
... 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