and
cid#1546284 Using invalid iterator
cid#1546275 Using invalid iterator
cid#1546049 Using invalid iterator
cid#1545929 Using invalid iterator
cid#1545870 Using invalid iterator
cid#1545668 Using invalid iterator
cid#1545420 Using invalid iterator
Change-Id: I3ad3000631b4be5917b9c5f49f21b8cc003a309c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159056
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
and :
cid#1545537 Using invalid iterator
cid#1545508 Using invalid iterator
cid#1545494 Using invalid iterator
cid#1545478 Using invalid iterator
cid#1545427 Using invalid iterator
cid#1545420 Using invalid iterator
cid#1545400 Using invalid iterator
cid#1545300 Using invalid iterator
cid#1545258 Using invalid iterator
cid#1545257 Using invalid iterator
cid#1545200 Using invalid iterator
cid#1545183 Using invalid iterator
Change-Id: Ibf3a41902f34286967195c5c3b22e337a4b06809
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160322
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
https://en.cppreference.com/w/cpp/compiler_support says that this is
supported in
GCC >= 11
CLANG >= 16
Visual Studio >= VS 2019 16.10
And our Visual Studio baseline is now 2019.
We still need to make the ifdef conditional check clang, because
__has_include will happily return true even if the current clang
does not support the necessary builtins.
Change-Id: I5f2743e204b8ed22d4651053f3ae579a4a192a45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157515
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
A rough implementation of uno bindings for LOWA using embind.
Adds new parameter '-W' to cppumaker to generate _embind.cxx
files alongside .hdl & .hpp.
For usage examples see static/README.wasm.md
Change-Id: Iee5d05e37bfba8e101c08212b15c05f7f2fa6c33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156273
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
...and revert e1c6f36d8b "Add a to_string()
function to the code generated for UNO IDL constant groups". (But keep the
constants groups the latter had added to cppu/qa/cppumaker/types.idl, and use
them in the newly added CppunitTest_stoc_dump, for better or worse.)
Change-Id: I56e9eaeb1e45b83a72a25eceef13e719dc6f3a1e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149281
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Jenkins
If the inpt matches one of the constants exactly, the result is the
name of that constant. If the input matches some combination of
constant values that are single bits, the result is the sequence of
the names of those constants joined with plus signs.
For instance, if the IDL has:
constants Constants {
const byte BIT0 = 1;
const byte BIT1 = 2;
const byte BIT2 = 4;
const byte BIT3 = 8;
}
The result of Constants::to_string(5) is "BIT0+BIT2", and the result
of Constants::to_string(17) is "17".
I am sure there are corner cases that aren't handled as would be
intuitive, especially with types that include unsigned values.
Correspondingly, the semantics of the generated to_string() functions
is not formally defined.
Also add a unit test for the new functionality.
Change-Id: I14aa826d0989ac6dfe97dd5c09119b1601c65643
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148995
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
When 485c9d4f0e "Clarify the use of
untools::WeakReference" introduced cppu::detail::isUnoInterfaceType and its use
in the requires-clause of unotools::WeakReference::get, its commit message
argued that while isUnoInterfaceType only works if the given type is complete,
that would already be taken care of via the use of std::is_convertible_v in the
implementation of unotools::WeakReference::get. But while std::is_convertible_v
nominally requires its argument types to be complete (unless they are void, or
arrays of unknown bound), typical implementations like recent libc++ or
libstdc++ do not seem to enforce that (and just return false in such a case).
So better make isUnoInterfaceType explicitly require that the given type is
complete. Which turned up one case where it isn't at the point where
unotools::WeakReference<SdrTextObj>::get is called. (And while the resulting
call to dynamic_cast<SdrTextObj*>(...) in the implementation of that function
would cause an error when SdrTextObj is not complete, compilers happened to
instantiate that template specialization only at the end of the TU, by which
time SdrTextObj happened to be a complete type in the TUs including that
sd/source/ui/inc/futext.hxx. So all happened to work out OK.)
Change-Id: I704b8b437fa836e290245d1727e4d356128ef63c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143667
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which had been introduced in 78040af9ac
"loplugin:refcounting in sc" as a variation on css::uno::WeakReference from
include/cppuhelper/weakref.hxx, but without giving much of a rationale.
And, at least for --with-latest-c++ builds using a capable C++20 compiler,
ensure that the given interface_type is such that the static_cast and
dynamic_cast in the implementation of unotools::WeakReference::get are actually
sound: If interface_type could be a UNO interface type, that would imply that
the xInterface obtained from the underlying WeakReferenceHelper::get() could be
a proxy from the C++ UNO bridge, which could (a) be a proxy for only a subtype
of interface_type (e.g., just for XInterface), so that the static_cast would be
broken, and (b) be a proxy for which the vtable's RTTI slot is not set up (see
e.g. the ENABLE_RUNTIME_OPTIMIZATIONS code in
bridges::cpp_uno::shared::VtableFactory::initializeBlock in
bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx), so that the dynamic_cast
could crash. (These issues can even happen when the given interface_type is a
C++ implementation class type, but the given object has been bridged over some
C++ to C++ UNO ("purpose") bridge, but lets leave it at that...)
This required adding some cppu::detail::isUnoInterfaceType predicate to the
include files generated by cppumaker, which can be useful in other places too.
(For the call to isUnoInterfaceType in the requires-clause of
unotools::WeakReference<interface_type>::get to give the correct answer, it is
important that interface_type is a complete type---i.e., the corresponding
codemaker-generated .hpp having been included if interface_type actually were a
UNO include type. But that is already nicely required by the call to
std::is_convertible_v in the implementation of that function, anyway.)
Change-Id: Ia5efd70085d2d6d45fa0995d00dc8def564bbe5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143601
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit 9463550eab.
Reason for revert: The codemaker::UnoType::decompose was previously mostly returning the same OString it receives, so this change is likely a pessimisation
Change-Id: Ie1b41889d0a6af9247b8683075d4edd1163fecc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133492
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
since we now have o3tl versions of those that work on
string_view.
Also improve those o3tl functions to support both string_view
and u16string_view
Change-Id: Iacab2996becec62aa78a5597c52d983bb784749a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132755
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
For example, in de3898aecb "Add missing test
dependency" it would have output
> warn:svx:680849:680849:svx/source/unodraw/unoshape.cxx:1779: DBG_UNHANDLED_EXCEPTION in setPropertyValues exception: com.sun.star.beans.UnknownPropertyException message: "URL at svx/source/unodraw/unoshape.cxx:1600"
rather than
> warn:svx:680849:680849:svx/source/unodraw/unoshape.cxx:1779: DBG_UNHANDLED_EXCEPTION in setPropertyValues exception: com.sun.star.beans.UnknownPropertyException message: URL svx/source/unodraw/unoshape.cxx:1600
making it slightly clearer that what follows "URL" is not the value of that URL
but rather the source location where the exception was thrown.
Change-Id: Ia3abd232fce3d95a8b66ff4ed5bab2fcc248df2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128788
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...instead of going via raw `char const *`. (This changes the code's semantics
if buffer can contain embedded NULs, but it is unlikely that the original code
using getStr() was even meant to stop comparison at the first embedded NUL.)
Change-Id: I00a0a08b3ba8c318e3b898548ef185efa3f93ef2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115713
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for
operator call arguments. (The "rather than copy, pass subView()" diagnostic is
already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly
for operator call arguments.)
(And many call sites don't even require an explicit [u16]string_view, esp. with
the recent ad48b2b02f "Optimized OString operator
+= overloads". Just some test code in sal/qa/ that explicitly tests the
O[U]String functionality had to be excluded.)
Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The legacy `throw()` dynamic exception specification is gone for good from C++20
(even if compilers typically still accept it, but e.g. Clang has
-Wdeprecated-dynamic-exception-spec to at least warn about it).
Introduce SAL_NOEXCEPT for use in URE interface include files. (For both the
existing SAL_THROW_EXTERN_C and the new SAL_NOEXCEPT, base usage of `noexept`
not on LIBO_INTERNAL_ONLY, but on the actual compiler C++ version, so that e.g.
building CppunitTest_cppu_any-external, which uses
gb_CppunitTest_set_external_code but not gb_CXX03FLAGS, will not potentially
complain about those macros expanding to the legacy `throw()`, like when
building with Clang -Wdeprecated-dynamic-exception-spec manually enabled.)
Change-Id: I7e5c7f8d5f0fd622cfc9987d656b1f68541375aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114908
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
...from which an OString can cheaply be instantiated.
The one downside is that OStringLiteral 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 containers 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::string_view, without loss of efficiency
compared to the original OStringLiteral, and without loss of expressivity (esp.
with the newly introduced OString(std::string_view) ctor).
The new OStringLiteral 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 OStringLiteral is in all cases where an
object that shall itself not be an OString (e.g., because it shall be a
global static variable for which the OString ctor/dtor would be detrimental at
library load/unload) must be converted to an OString instance in at least one
place. Other string literal abstractions could use std::string_view (or just
plain char const[N]), but interestingly OStringLiteral might be more efficient
than constexpr std::string_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.
sal/qa/rtl/strings/test_ostring_concat.cxx documents some workarounds for GCC
bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". Those places, as
well as uses of OStringLiteral in incodemaker/source/javamaker/javaoptions.cxx
and i18npool/source/breakiterator/breakiterator_unicode.cxx, which have been
replaced with OString::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).
This change also revealed a bug in at least recent Clang 12 trunk
CastExpr::getSubExprAsWritten (still to be reported to LLVM), triggered at least
in some calls from loplugin code (for which it can be fixed for now in the
existing compat::getSubStringAsWritten).
A similar commit for OUStringLiteral is planned, too.
Change-Id: Ib192f4ed4c44769512a16364cb55c25627bae6f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101814
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
O[U]StringView had an odd mixture of uses. For one, it was used like
std::[u16]string_view, for which directly using the latter std types is clearly
the better alternative. For another, it was used in concatenation sequences,
when neither of the two leading terms were of our rtl string-related types.
For that second use case introduce O[U]String::Concat (as std::[u16]string_view
can obviously not be used, those not being one of our rtl string-related types).
Also, O[U]StringLiteral is occasionally used for this, but the planned changes
outlined in the 33ecd0d5c4 "Change OUStringLiteral
from char[] to char16_t[]" commit message will make that no longer work, so
O[U]String::Concat will be the preferred solution in such use cases going
forward, too.
O[U]StringView was also occasionally used to include O[U]StringBuffer values in
concatenation sequences, for which a more obvious alternative is to make
O[U]StringBuffer participate directly in the ToStringHelper/O[U]StringConcat
machinery.
Change-Id: I1f0e8d836796c9ae01c45f32c518be5f52976622
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101586
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Clang and gcc have moved this out of experimental and into std::source_location,
but only in their very latest releases.
Change-Id: I9d9d9155788ee4240455ac4628b298dface4ad24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93868
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Caolán McNamara