Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
move IsShowOutlineContentVisibilityButton out of header to
avoid having to add extra include paths to all the unit
test makefiles.
Change-Id: I2763390e07cd85b8f09b6f2ad7702039daecb22f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105100
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
...from which an OUString can cheaply be instantiated. This is the OUString
equivalent of 4b9e440c51 "Turn OStringLiteral into
a consteval'ed, static-refcound rtl_String". Most remarks about that commit
apply here too (this commit is just substantially bigger and a bit more
complicated because there were so much more uses of OUStringLiteral than of
OStringLiteral):
The one downside is that OUStringLiteral now needs to be a template abstracting
over the string length. But any uses for which that is a problem (e.g., as the
element type of a container that would no longer be homogeneous, or in the
signature of a function that shall not be turned into a template for one reason
or another) can be replaced with std::u16string_view, without loss of efficiency
compared to the original OUStringLiteral, and without loss of expressivity.
The new OUStringLiteral ctor code would probably not be very efficient if it
were ever executed at runtime, but it is intended to be only executed at compile
time. Where available, C++20 "consteval" is used to statically ensure that.
The intended use of the new OUStringLiteral is in all cases where an
object that shall itself not be an OUString (e.g., because it shall be a
global static variable for which the OUString ctor/dtor would be detrimental at
library load/unload) must be converted to an OUString instance in at least one
place. Other string literal abstractions could use std::u16string_view (or just
plain char16_t const[N]), but interestingly OUStringLiteral might be more
efficient than constexpr std::u16string_view even for such cases, as it should
not need any relocations at library load time. For now, no existing uses of
OUStringLiteral have been changed to some other abstraction (unless technically
necessary as discussed above), and no additional places that would benefit from
OUStringLiteral have been changed to use it.
Global constexpr OUStringLiteral variables defined in an included file would be
somewhat suboptimal, as each translation unit that uses them would create its
own, unshared instance. The envisioned solution is to turn them into static
data members of some class (and there may be a loplugin coming to find and fix
affected places). Another approach that has been taken here in a few cases
where such variables were only used in one .cxx anyway is to move their
definitions from the .hxx into that one .cxx (in turn causing some files to
become empty and get removed completely)---which also silenced some GCC
-Werror=unused-variable if a variable from a .hxx was not used in some .cxx
including it.
To keep individual commits reasonably manageable, some consumers of
OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat
odd state for now, where they don't take advantage of OUStringLiteral's
equivalence to rtl_uString, but just keep extracting its contents and copy it
elsewhere. In follow-up commits, those consumers should be changed
appropriately, making them treat OUStringLiteral like an rtl_uString or
dropping the OUStringLiteral overload in favor of an existing (and cheap to use
now) OUString overload, etc.
In a similar vein, comparison operators between OUString and std::u16string_view
have been added to the existing plethora of comparison operator overloads. It
would be nice to eventually consolidate them, esp. with the overloads taking
OUStringLiteral and/or char16_t const[N] string literals, but that appears
tricky to get right without introducing new ambiguities. Also, a handful of
places across the code base use comparisons between OUString and OUStringNumber,
which are now ambiguous (converting the OUStringNumber to either OUString or
std::u16string_view). For simplicity, those few places have manually been fixed
for now by adding explicit conversion to std::u16string_view.
Also some compilerplugins code needed to be adapted, and some of the
compilerplugins/test cases have become irrelevant (and have been removed), as
the tested code would no longer compile in the first place.
sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". That place, as well
as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and
i18npool/source/localedata/localedata.cxx, which have been replaced with
OUString::Concat (and which is arguably a better choice, anyway), also caused
failures with at least Clang 5.0.2 (but would not have caused failures with at
least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile
been fixed).
Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...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>
Abort scan of a string beginning with a hashtag, if a comma is found. Otherwise, the compiler raises a syntax error. If
the string ends with a hashtag too, it will be parsed later checking for
a date literal.
Change-Id: I078a2302f5c65206367a00fbc584ffa7b9ede031
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102099
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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>
This is a prerequisite for making conversion from OUStringLiteral to OUString
more efficient at least for C++20 (by replacing its internals with a constexpr-
generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount,
conditionally for C++20 for now).
For a configure-wise bare-bones build on Linux, size reported by `du -bs
instdir` grew by 118792 bytes from 1155636636 to 1155755428.
In most places just a u"..." string literal prefix had to be added. In some
places
char const a[] = "...";
variables have been changed to char16_t, and a few places required even further
changes to code (which prompted the addition of include/o3tl/string_view.hxx
helper function o3tl::equalsIgnoreAsciiCase and the additional
OUString::createFromAscii overload).
For all uses of macros expanding to string literals, the relevant uses have been
rewritten as
u"" MACRO
instead of changing the macro definitions. It should be possible to change at
least some of those macro definitions (and drop the u"" from their call sites)
in follow-up commits.
Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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>
tackle some read-only vars.
Mark some of them const to make it obvious they are not really used, and
to make the constantparam plugin see more data.
Change-Id: Ia25927745866746aa1aa9d5affd5857ad9f9ee24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100895
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Otherwise it will fail assertion in SbxValue::Clear, because
SvRefBase::ReleaseRef would check that its current count is
not zero. In release builds, not doing this would leak.
Change-Id: I80dfc815f8a2b651ff290af10808212281abf246
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100879
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This requires to reset Fixed flag temporarily, as in SbiParser::DefType
for non-image case.
And save the dimensions of the arrays in the custom types correctly:
the dimensions are numbered from 1, not from 0.
The existing unit test (that happened to not test anything actually)
was fixed.
Change-Id: I48c6b6d5d735d9972a2c0dd40345d5db75f87f39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100877
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>
As discussed at <https://gerrit.libreoffice.org/c/core/+/99724> "fix shutdown
crash in basic" the code was added in error, and at least clang-cl with latest
MSVC standard library and C++20 mode gives a helpful
> basic/source/sbx/sbxbase.cxx(53,5): error: ignoring return value of function declared with 'nodiscard' attribute [-Werror,-Wunused-result]
> std::move(m_Factories);
> ^~~~~~~~~ ~~~~~~~~~~~
now.
Change-Id: I052efe51d4415838b50de06bb308692fa937b7b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100076
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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>
Stephan Bergmann