This may be important with static empty sequence cppu::g_emptySeq, that is
common for sequences of different types.
The changes in sd/qa/unit/data/xml/*.xml fix places where anys with empty
Sequence<OUString> used to wrongly take 'if(aAny >>= aPropSeq)' branch in
dumpPropertyValueAsElement (drawinglayer/source/dumper/XShapeDumper.cxx).
Change-Id: I5b0544ca94b30437c01dd46f376408f91510bcb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124167
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...compared to a full-blown O[U]String, for temporary objects holding an
O[U]StringConcat result that can then be used as a std::[u16]string_view.
It's instructive to see how some invocations of operator ==, operator !=, and
O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit
materialization of an O[U]String temporary, and how that expensive operation has
now been made explicit with the explicit O[U]StringConcatenation ctor.
(The additional operator == and operator != overloads are necessary because the
overloads taking two std::[u16]string_view parameters wouldn't even be found
here with ADL. And the OUString-related ones would cause ambiguities in at
least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with
RTL_STRING_UNITTEST, so have simply been disabled for that special test-code
case.)
Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This is clang-cl's equivalent of -fvisibility-inlines-hidden,
and it seems to be also sort of the equivalent of MSVC's
-Zc:inline. So it saves build time and disk space.
Clang docs say that this is binary compatible in only one
direction, so our public C++ code shouldn't be using this,
as external C++ code could try to use exported inlines
that are no longer there.
Change-Id: Ie6217808f8ee4a15344183abfc65038e1558d1b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122352
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
no need to delay-init something we always need, and laying
out a std::unordered_map is something we can normally do at
link time anyway.
Change-Id: Ide791d20394580bca615aa3ad564c154037e0816
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119137
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
In commit b33fbd55d6, many getMutex() have been replaced by an equivalent
maMutex.
Only in place, the use of a mutex have been simply removed.
Restore it as done in all the other places
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Change-Id: Id85e74e166ec57dd37f8913f8ecf19e2b6465f8f
---
This patch is completely speculative. The removal of this mutex was maybe
done on purpose.
This only looks spurious to me.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117402
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/
Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Renaming all README files for all top level modules to README.md,
applying no content change at this stage to be able to track history
of the files. These files should be edited to use correct Markdown
syntax later.
Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
...by re-enabling the code temporarily #if'ed-out in
a528392e71 "Fixed/improved
loplugin:cppunitassertequals" (and which then triggers lots of other
lopglugin:cppunitassertequal CPPUNIT_ASSERT -> CPPUNIT_ASSERT_EQUAL warnings).
For two css::uno::Reference equality comparisons in cppu/qa/test_any.cxx, it
was more straightforward to rewrite them with an explicit call to operator ==
(which silences loplugin:cppunitassertequal) than to adapt them to
CPPUNIT_ASSERT_EQUAL's requirement for arguments of identical types.
In sc/qa/unit/ucalc_pivottable.cxx, ScDPItemData needs toString, which has been
implemented trivially for now, but might want to combine that with the
DEBUG_PIVOT_TABLE-only ScDPItemData::Dump.
Change-Id: Iae6d09cf69bd4e52fe4411bba9e50c48e696291c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110546
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit 0752de6850, as it causes
initialization-order-fiasco, e.g. when building Gallery_backgrounds:
> ==913067==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x7fee04a01ba0 at pc 0x7fee0467257e bp 0x7ffd678aaa30 sp 0x7ffd678aaa28
> READ of size 8 at 0x7fee04a01ba0 thread T0
> #0 in osl::Mutex::acquire() at include/osl/mutex.hxx:57:37 (instdir/program/libuno_cppu.so.3 +0x32957d)
> #1 in osl::Guard<osl::Mutex>::Guard(osl::Mutex&) at include/osl/mutex.hxx:138:17 (instdir/program/libuno_cppu.so.3 +0x316a4e)
> #2 in typelib_typedescriptionreference_new at cppu/source/typelib/typelib.cxx:2130:16 (instdir/program/libuno_cppu.so.3 +0x3e2d9a)
> #3 in typelib_static_type_getByTypeClass at cppu/source/typelib/static_types.cxx:266:17 (instdir/program/libuno_cppu.so.3 +0x3c04af)
> #4 in cppu::detail::getTypeFromTypeClass(_typelib_TypeClass) at include/cppu/unotype.hxx:110:9 (instdir/program/libxolo.so +0x2e87e61)
> #5 in cppu::detail::cppu_detail_getUnoType(signed char const*) at include/cppu/unotype.hxx:136:12 (instdir/program/libxolo.so +0x2e902dd)
> #6 in cppu::UnoType<signed char>::get() at include/cppu/unotype.hxx:296:16 (instdir/program/libxolo.so +0x2e90278)
> #7 in com::sun:⭐:uno::Type const& cppu::getTypeFavourUnsigned<signed char>(signed char const*) at include/cppu/unotype.hxx:321:12 (instdir/program/libxolo.so +0x2e90218)
> #8 in com::sun:⭐:uno::Type const& cppu::getTypeFavourUnsigned<signed char>(com::sun:⭐:uno::Sequence<signed char> const*) at include/com/sun/star/uno/Sequence.hxx:292:14 (instdir/program/libxolo.so +0x2e9001a)
> #9 in com::sun:⭐:uno::Sequence<signed char>::Sequence() at include/com/sun/star/uno/Sequence.hxx:59:26 (instdir/program/libxolo.so +0x2e8ff58)
> #10 in __cxx_global_var_init at xmloff/source/core/fasttokenhandler.cxx:35:48 (instdir/program/libxolo.so +0x3455d3f)
> #11 in _GLOBAL__sub_I_fasttokenhandler.cxx at xmloff/source/core/fasttokenhandler.cxx (instdir/program/libxolo.so +0x3455da4)
> #12 in call_init.part.0 at <null> (/lib64/ld-linux-x86-64.so.2 +0x108dd)
> #13 in _dl_init at <null> (/lib64/ld-linux-x86-64.so.2 +0x109c7)
> #14 at <null> (/lib64/ld-linux-x86-64.so.2 +0x10c9)
>
> 0x7fee04a01ba0 is located 0 bytes inside of global variable '(anonymous namespace)::s_Mutex' defined in 'cppu/source/typelib/typelib.cxx:286:12' (0x7fee04a01ba0) of size 8
> registered at:
> #0 in __asan_register_globals at ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_globals.cpp:360:3 (instdir/program/gengal.bin +0x28698d)
> #1 in asan.module_ctor at <null> (instdir/program/libuno_cppu.so.3 +0x42649b)
Change-Id: Iab673f048bfb76165de2c47c2db63e339069fd17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110228
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>
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
...introduced with 5d8f0fad50 "Adapt
CPPUNIT_ASSERT to C++20 deleted ostream << for sal_Unicode (aka char16_t)" (see
there for details) but erroneously removed with
7bdbb50a50 "tdf#42949 Fix new IWYU warnings in
directories c*"
Change-Id: I32880a719525915f397fc65979265b67189ec604
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105397
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
current attempt isn't working, try a different approach to
silence these warnings
Change-Id: I0cc97df0897abc665dfbb683d7aa0df55f8affb2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103387
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
bDesctructorCalled doesn't exist in the code anymore.
I guess we can delete the comment.
Change-Id: I551efe2298422e5139f1dd07a6b3bf4728763026
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100774
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
