During the creation of the parameter list of a method, explicitly grant
write access to the method which will used as a variable. Otherwise, the
name of the method can't be used in certain statements, i.e., index in a
for loop or as a dimension in ReDim.
Change-Id: I3e4c49c21fd3345d5ddd69bc31a5823b5de5b8e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104696
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The Split function sets the datatype of the array to SbxVARIANT instead
of SbxSTRING preventing any subsequent assignments to the array and to
the elements itself.
Change-Id: Ib099eee7bfd222c97520ac8970352bcf2b44bc3e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104039
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This will need a real implementation to do system calls, but for
the initial compilation the dummy is sufficient.
Change-Id: Ia16e47fdb8fbf4855f7c5abb0d36d9c922cd1de7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102860
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
...and in turn add OUString::operator = and OUString::operator +=
overloads that take a std::u16string_view. Without making the ctors explicit,
the operator overloads would have caused ambiguities when called with raw
sal_Unicode pointers/non-const arrays, as those can convert to both OUString and
to std::u16string_view.
But the std::u16string_view operator overloads will generally be useful when
changing OUStringLiteral similarly to 4b9e440c51
"Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which
point many existing uses of OUStringLiteral will be replaced with uses of
std::u16string_view.
Implementing this change turned up a need for an operator = overload for
OUStringNumber, which has thus been added. No such need turned up for a
corresponding operator += overload, but which can easily be added when the need
arises.
It also revealed that the operator == overloads between an OUString and a raw
sal_Unicode pointer/non-const array were implemented rather inefficiently,
creating a temporary OUString from the raw argument. Those have been improved.
Preceding commits have already taken care of many dubious or simply unnecessary
implicit uses of the now-explicit OUString ctors. This commit makes explicit
the few remaining reasonable uses. (And in some cases needed to change variable
initialization syntax from using parentheses to using curly braces, to avoid the
most vexing parse issue. And needed to explicitly add OUString ctors from
char16 const[2] string literal lvalues in a conditional expression in
writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary
because MSVC apparently still insists on doing array-to-pointer decay there.)
All of this only affects LIBO_INTERNAL_ONLY.
Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Using option base, every array should start at index 1. Previously, it
needed option VBASupport too. Without option compatible, the upper bound
of an array is increased as well in order to preserve the specified
size.
Change-Id: I52885f14914a4636b98258aa428c2123f62482a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101269
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
In order to prevent type conversion errors, reset a variable of type
SbxERROR to not fixed. Variable will be of type SbxERROR, but can be
converted to any requested type.
Change-Id: Ic856376e3f8232577a5e894a2adb2545c8723033
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101419
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The check should prevent error in case when the variable has
wrong type. IsObject returns false e.g. for arrays, which are
valid iterables. So proper check is using GetFullType, which
will give SbxOBJECT for any variable for which GetObject does
not set error.
"Next" should also generate an error for uninitialized loops.
Regression after 5760c94b88
Change-Id: Ib58e1cc76ef63aa1ff8a86c9d5dc956e4780fb49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100258
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
another change I am working on slightly tweaks the shutdown ordering
and exposes this problem where two classes both think they own
the same object.
Change-Id: I7477cf7eda5b5729ee3861cb4a1be43bb34d9ea6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99724
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...that are helpfully deleted in C++20, as now implemented at least by VS 2019
16.6.4 when using --with-latest-c++
Change-Id: Iaf80f793e73fc90768bb146c9cf3d300d6747c8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99170
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
1. In SbiRuntime::PushForEach, always initialize SbiForStack::eForType
to avoid handling the loop as simple For loop in SbiRuntime::StepNEXT.
2. In SbiRuntime::PushForEach, just like in SbiRuntime::PushFor, don't
set error, but imitialize the loop properly. This allows to proceed to
SbiRuntime::StepTESTFOR, where the error will be handled gracefully.
3. In SbiRuntime::StepTESTFOR, check for the proper initialization of
the iteration, and set the error.
4. In SbiRuntime::StepTESTFOR, on error, modify the type of iteration
into Error - to make sure that loop ends on next iteration (so only a
single iteration happens inside the Resume Next).
Change-Id: Idd0bab79fb0099fa3ad295b7fc6ab2eb6173f7b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98537
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
E.g., when we redim a copy of an array, the other copy would still have
its old dimensions, so shallow copy would share some array elements
between the now different arrays.
The other possible approach would be to try to modify the original array
to have the ByRef semantics.
Change-Id: Iab272ecbf4ade67048d6a126f17322441c5aa808
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98481
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
.. and a few cases of instead doing blacklist->excludelist where that
made more sense.
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
[API CHANGE] officecfg::Office::Canvas::DeviceBlacklist -> DeviceDenylist
[API CHANGE] officecfg::Office::Canvas::BlacklistCurrentDevice -> DenylistCurrentDevice
[API CHANGE] officecfg::Office::Common::Misc::OpenCLBlackList -> OpenCLDenyList
Change-Id: Ia35e25496bf0cc0692d5de4cb66bfc232d3a869e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98180
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
During the loading of numeric constants in StepLOADNC, create variables
of type Variant and convert them to the requested type, i.e.
Variant/Type in order to prevent type conversion errors, when they are
passed to a method with variant parameter types.
Change-Id: I2ab0111b5b53dd2de9523ba7cf12bd2519d050b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96402
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
During the construction of the parameter list of a method,
convert parameters of type SbxEMPTY to their requested type,
since missing parameters are handled differently in StepEMPTY,
where separate parameter information (SbxMISSING) is added.
Change-Id: Ie1e027cfdd652404ec29bd3d05e7daf533468936
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96088
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
It should not convert strings to uppercase each loop; it should use
OUStringBuffer to avoid extra allocations.
This reduces tick count for the code in the bug from ~6000 to ~30.
Change-Id: I89ea062fc6d012464bb461b6a8ef321f8cc62fe6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92884
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
If a particular parameter type is requested during the
construction of a parameter list, don't convert missing
parameters to avoid implicit casting to the specified
data type and value of the method.
Missing parameters are handled in StepEMPTY, where
additional information about missing parameters is added.
Change-Id: Ia413b2996d7d1feecedc1dfefaf6baf0fd9d917e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90215
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
In order to load numeric values, generate SbiOpcode::NUMBER_ opcodes
including the numeric value and its data type instead of SbiOpcode::CONST_.
The numeric value and its data type will be restored in
SbiRuntime::StepLOADNC. When the new compiled code is stored in documents,
e.g. password-protected libraries, leagcy LO versions will just read up to
non-numeric characters, thus correctly obtaining number value and ignoring
the type, so the change is backward-compatible.
To interpret legacy compiled code, old treatment of SbiRuntime::StepLOADI
is restored, reverting commit 0b4f8bf571.
This change reimplements the fix for tdf#129596.
Change-Id: I46ebfc77f9bea69479968950c0fb7264e4a7ab27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90858
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Initialize default values of optionals in function headers.
In LO Basic, optional parameters are allowed, but without
any default values. Missing parameters will not be initialized
to their respective default values of its datatype, either.
With option Compatible, optional parameters are allowed
with default values. Missing optional parameters that
don't have explicit default values will not be initialized
to their default values of its datatype.
With option VBASupport, optional parameters are allowed with
default values. Missing optional parameters that don't have
explicit default values will be initialized to their default
values of its datatype.
Change-Id: I57aabae5f70d1cf6c4e8feb95ce0db6af753383c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87550
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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>
found using 'git grep', I tried using clang-tidy, but it only
successfully found a tiny fraction of these
Change-Id: I61c7d85105ff7a911722750e759d6641d578da33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86526
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
During the generation of CONST_ expressions, distinguish between
integer and long and load the correct value in the immediate load step.
Change-Id: Ib4eb65d7fae3163043899ad8234816b1ebd7316b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85779
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Andreas Heinisch