summaryrefslogtreecommitdiff
path: root/cppu
AgeCommit message (Collapse)AuthorFilesLines
2021-05-02throw() -> noexcept, part 2/3: Automatic loplugin:noexcept rewriteStephan Bergmann2-8/+8
Change-Id: I076f16d0536b534abf0ced4d76051eadb4c0e033 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114949 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein1-3/+7
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>
2021-04-06cppu : use std::mutex in threadpoolArnaud Versini3-21/+21
Change-Id: I559a2c533accfe95740c29d726833d0bbab210fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112460 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-03-24Using .md extension/Markdown syntax for modules READMEHossein1-0/+0
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>
2021-02-08sal_Unicode is always char16_t in LIBO_INTERNAL_ONLY code nowStephan Bergmann1-29/+8
...since 9ac98e6e3488e434bf4864ecfb13a121784f640b "Finally switch MSVC to sal_Unicode = char16_t, too" Change-Id: I0df169307618aba3f609400312737c6e1e1d3aaf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110581 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-08Improve loplugin:cppunitassertequal for CPPUNIT_ASSERT(a && b)Stephan Bergmann1-359/+804
...by re-enabling the code temporarily #if'ed-out in a528392e71bc70136021be4e3d83732fccbb885e "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>
2021-02-01Revert "Don't use global mutex here for local mutex initialization"Stephan Bergmann1-23/+32
This reverts commit 0752de6850e4396a0138428d7ced2287a4902874, 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::star::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::star::uno::Type const& cppu::getTypeFavourUnsigned<signed char>(com::sun::star::uno::Sequence<signed char> const*) at include/com/sun/star/uno/Sequence.hxx:292:14 (instdir/program/libxolo.so +0x2e9001a) > #9 in com::sun::star::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>
2021-01-31Don't use global mutex here for local mutex initializationMike Kaganski1-32/+23
Change-Id: I06b0856ac5559aca472daf241771a2ef57b44912 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110147 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-01-30Don't use global mutex here for static initializationMike Kaganski1-43/+6
Change-Id: I3fa0cd7e31a8c89b5fb1eba7b36636e02a785df8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110140 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-01-29Simplify the ctorMike Kaganski1-18/+9
Change-Id: Iad9b007f8a67353343813a44f46a8a0b88b555fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110136 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-01-29loplugin:stringviewparam extend to new..Noel1-3/+3
O[U]StringBuffer methods Change-Id: I0ffbc33d54ae7c98b5652434f3370ee4f819f6f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110090 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann1-2/+2
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann3-4/+7
...for LIBO_INTERNAL_ONLY. These had been missed by 1b43cceaea2084a0489db68cd0113508f34b6643 "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>
2020-11-24loplugin:stringviewparam extend to comparison operatorsNoel1-4/+4
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>
2020-11-13tdf#123936 Formatting files in module cppu with clang-formatPhilipp Hofer2-7/+12
Change-Id: I98281fce06c2a8c094db9e80c1f6bdf35ce70ccd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105657 Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-11-11loplugin:stringviewNoel2-3/+3
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>
2020-11-06Reinstate o3tl/cppunittraitshelper.hxx uses for C++20Stephan Bergmann2-0/+2
...introduced with 5d8f0fad50f90195a11873c70ddab4644f5839ea "Adapt CPPUNIT_ASSERT to C++20 deleted ostream << for sal_Unicode (aka char16_t)" (see there for details) but erroneously removed with 7bdbb50a507df4c419f68d2ae453dd482267f168 "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>
2020-11-06tdf#42949 Fix new IWYU warnings in directories c*Gabor Kelemen4-4/+0
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Iac1e7802dbe1efa01c2befdd10406231788d4fc1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105315 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-25cid#1448292 coverity has difficulty with css::uno::SequenceCaolán McNamara1-2/+1
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>
2020-09-13tdf#124176 Use #pragma once in cppu, cppuhelperGeorge Bateman15-60/+15
This commit was carried out by a Python script, source of which is at https://bugs.documentfoundation.org/show_bug.cgi?id=124176#c97. Change-Id: I0b7c5bec8e56bd21e719c8889fe263e377f3b8ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102547 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-17Remove dead commentStephan Bergmann1-1/+0
...which had been dead ever since b525a3115f54576017a576ff842dede5e2e3545d "initial import" and whose removal has already been suggested in 04bb20f5ad182fd1aa8a4e2e7f569043be8405c1 "Fix typo" Change-Id: I57d1e284e9c38836dca620fd3d0058fc5c6f098e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100854 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-15Fix typoAndrea Gelmini1-1/+1
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>
2020-08-05Avoid warnings about unused Char4Stephan Bergmann1-5/+6
Change-Id: Ibcb256552ee03b14a76463be3d9b7ce53213fa7a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100124 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-03loplugin:flatten in configmgr..i18nutilNoel Grandin1-45/+45
Change-Id: Idaeed33df4f1dd1b2acbdaf8a895c5d56c3ca14c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99980 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-10replace usage of blacklist with excludelist for IWYUThorsten Behrens1-1/+1
Background and motivation: https://tools.ietf.org/html/draft-knodel-terminology-02 Change-Id: I2f22d455d2a936a85750eaab1fda215ebb6d9d48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98182 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-01Upcoming improved loplugin:staticanonymous -> redundantstatic: cppuStephan Bergmann3-4/+4
Change-Id: Iac1bd5cb1ff1a1786471b2d8b8a3c500a2e15c5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97546 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-26Handle uno_threadpool_dispose in parallel with uno_threadpool_putJobStephan Bergmann2-3/+8
While tracking down the issue discussed in the commit message of 78dc7d982b65c1843a288b80da83f8766e85d0cf "Remove a potentially already enqueued response when a bridge is disposed", it occurred to me that there should be a race in those uno_threadpool_putJob( bridge_->getThreadPool(), ...); calls in binaryurp/source/reader.cxx, when the bridge gets disposed (through some other thread) between the time the bridge_->getThreadPool() call checks for the bridge being disposed (in which case it would throw a DisposedException) and the actual uno_threadpool_putJob call. I tried to catch that with a previous incarnation of this change (<https://gerrit.libreoffice.org/c/core/+/96120/1> "Jenkins Slides Through the Tiny Window"), but couldn't---presumably because this race would be very rare after all, and the issue I was chasing turned out to be caused by something different anyway. Nevertheless, I wanted to address this potential race now. We can only reliably check for disposed'ness after having locked ThreadPool's m_mutex in uno_threadpool_putJob -> ThreadPool::addJob, but at which time we can no longer indicate this condition to the caller---uno_threapool_putJob is part of the stable URE interface, has a void return type, and should not throw any exceptions as it is a C function. However, if the bridge gets disposed, any threads that would wait for this job (in cppu_threadpool::JobQueue::enter, either from cppu_threadpool::ORequestThread::run waiting to process new incoming calls, or from a bridge's call to uno_threadpool_enter waiting for a respose to an outgoing call) should already learn about the bridge being disposed by falling out of cppu_threadpool::JobQueue::enter with a null return value. So it should be OK if uno_threadpool_putJob silently discards the job in that case. Change-Id: I36fe996436f55a93d84d66cc0b164e2e45a37e81 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96120 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-16Use the saner std::condition_variable semantics for JobQueue::m_cndWaitStephan Bergmann3-51/+39
This avoids the need for the tricky osl::Condition::reset calls. For example, the first one (in the "disposed !" case) had been added with 2a3ed89284890615ad4bce57be55ba558351cde1 "sb132: #i112448# proper clean up in JobQueue::enter (patch by olistraub)" as > if( 0 == m_lstCallstack.front() ) > { > // disposed ! > + if( m_lstJob.empty() ) > + { > + osl_resetCondition( m_cndWait ); > + } > break; > } > and then change to > if( 0 == m_lstCallstack.front() ) > { > // disposed ! > - if( m_lstJob.empty() ) > + if( m_lstJob.empty() > + && (m_lstCallstack.empty() > + || m_lstCallstack.front() != 0) ) > { > osl_resetCondition( m_cndWait ); > } with cba3ac1eab7acaf8e6efd7a00eee7c5e969fc49b "Avoid deadlocks when disposing recursive JobQueue::enter", which prevented the reset from ever hapening (because m_lstCallstack.front() cannot both be zero and non-zero here at the same time). The std::condition_variable semantics nicely avoid any reasoning whether or not a reset would be necessary here. Change-Id: Ic9b57b836bb6679829f4aa3b68679256726acf60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96406 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-15Model the dispose tokens as `void const *` instead of `sal_Int64`Stephan Bergmann5-30/+26
...which avoids the sal_IntPtr casts Change-Id: I518fcefc66d297b56c9bd94f7826a44715acb5f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96392 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-15Remove a potentially already enqueued response when a bridge is disposedStephan Bergmann1-0/+7
...while a remote call is in progress. Otherwise, if the same thread later makes another remote call (through another bridge), it would erroneously pair the repsonse for the disposed call with the second call. UITest_calc_demo started to fail that way occasionally, presumably after 77445e201c45e5593761e8399c32f80eea2178a4 "Make Chart Creation Wizard async", but for reasons rather unrelated to the contents of that commit. What apparently happened is that in one test's tearDown, the bridge between the Python and the soffice process happened to be disposed during the XDesktop::terminate call from Python's main thread, so that the response (of type BOOLEAN) remained in the JobQueue. Then during the next test's setUp, XUnoUrlResolver::resolve from Python's main thread would internally make a remote queryInterface call for the initial StarOffice.ComponentContext object, which returns an ANY of either VOID or XInterface type. But that call was then mis-matched with the leftover BOOLEAN response, causing failure. I was able to reproduce that reliably on Linux with a local hack of > diff --git a/cppu/source/threadpool/jobqueue.cxx b/cppu/source/threadpool/jobqueue.cxx > index 6c9324521f40..a87770bf8935 100644 > --- a/cppu/source/threadpool/jobqueue.cxx > +++ b/cppu/source/threadpool/jobqueue.cxx > @@ -71,6 +71,7 @@ namespace cppu_threadpool { > } > > m_cndWait.wait(); > + timespec ms{0, 1000000}; nanosleep(&ms, nullptr); > > struct Job job={nullptr,nullptr}; > { introducing a sleep, so that other threads have a higher chance to dispose the bridge (when the call being processed here is that XDesktop::dispose) after the successful wait() but before the response is processed. UITest_calc_demo then failed with [...] > Execution time for create_chart.CalcChartUIDemo.test_activate_chart: 6.520 > tearDown: calling terminate()... > caught while TearDown: > Traceback (most recent call last): > File "uitest/libreoffice/connection.py", line 127, in tearDown > xDesktop.terminate() > libreoffice.connection.com.sun.star.lang.DisposedException: Binary URP bridge disposed during call binaryurp/source/bridge.cxx:611 > > ok > test_cancel_immediately (create_chart.CalcChartUIDemo) ... [...] > warn:sal.osl.pipe:423851:425076:sal/osl/unx/pipe.cxx:442: recv() failed: ECONNRESET > warn:binaryurp:423851:425076:binaryurp/source/bridge.cxx:843: undisposed bridge "" in state 2, potential deadlock ahead [...] > ====================================================================== > ERROR: test_cancel_immediately (create_chart.CalcChartUIDemo) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "uitest/uitest/framework.py", line 25, in setUp > self.connection.setUp() > File "uitest/libreoffice/connection.py", line 176, in setUp > conn.setUp() > File "uitest/libreoffice/connection.py", line 57, in setUp > self.xContext = self.connect(socket) > File "uitest/libreoffice/connection.py", line 107, in connect > xContext = xUnoResolver.resolve(url) > uno.com.sun.star.uno.RuntimeException: initial object queryInterface for OID "StarOffice.ComponentContext" returned ANY of type boolean binaryurp/source/bridge.cxx:883 [...] Change-Id: Icf9aadbb38e7aafffff844fe8e9ae99e165c1f33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96326 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-24inline some use-once typedefsNoel Grandin1-3/+2
Change-Id: Idddba2f3fd05265b08dbc88edb6152d34a166052 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94730 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-08compact namespace in canvas..cuiNoel Grandin2-5/+3
Change-Id: I7bd0c2a55b936896fcfe7e1a374871008a18618f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93706 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-28tdf#115399: Don't kill pre-existing typelib_TypeDescription membersStephan Bergmann4-16/+415
...in typelib_typedescription_register, in case they are already being referenced from elsewhere. Instead, only move from *ppNewDescription to pTDR->pType those members that were not yet initialized in the latter. Change-Id: I7620219d137f8dd7f24a0f4a04eda30669b6c5a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93062 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-28Fix printing rtl_uString*Stephan Bergmann1-1/+3
...broken with ef513fd4b049b214a03fbe6e62a5ea43680a7a9b "remove unnecessary use of OString::getStr" Change-Id: I85f5ccb6c5114ea5e3eab43a3c1821292cf4e994 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92993 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-23cid#1462311 silence Use after freeCaolán McNamara1-48/+48
etc. revert this hunk of commit 11785217594d863efb518aa8b8f2910cdcb9c59d Date: Tue Apr 14 14:55:22 2020 +0200 loplugin:buriedassign in c* just to silence coverity Change-Id: I6d8819a0ab073a56ab46944b170ef4ae3a28e4d0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92552 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-04-23Related tdf#115399: Reorder code slightlyStephan Bergmann1-4/+4
...in preparation of a forthcoming fix for the issue Change-Id: I6611778dfbc090eb869bf653cf7f61574a81b4f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92823 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-18loplugin:flatten in cppuNoel Grandin5-409/+409
Change-Id: I202698a0310bd26b98c1f744c8f21288f87643f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92450 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-14loplugin:buriedassign in c*Noel Grandin5-35/+52
Change-Id: Id14fed7e5c0f588ad3c927f12251432d12c1a7c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92190 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-06Make TYPELIB_TYPEDESCRIPTIONREFERENCE_ISREALLYWEAK constexprStephan Bergmann2-11/+10
...and make dynamic verifications static where applicable Change-Id: I3fb7ebe6885ee70e493ec1365601a1177d181347 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90002 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-03-04Remove redundant local reallyWeak functionStephan Bergmann1-17/+12
Change-Id: Ica26c0b5a839ebb2ca8ed1e2fa61b70cd08a9278 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89974 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-24Fix typoAndrea Gelmini1-2/+2
to complete: https://gerrit.libreoffice.org/c/core/+/89082 Change-Id: I8363f05f15c8d4ef032ccc8d469dc29231d74ca7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89360 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-01-15clang-tidy modernize-concat-nested-namespace in cppcanvas..cppuhelperNoel Grandin5-11/+11
Change-Id: I0bb4ea91288a15fb590d077fb390c53be8b50400 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86801 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-07Replace a CPPUNIT_ASSERT_EQUAL with a static_assertStephan Bergmann1-4/+5
Change-Id: I8382aa13eb9c65ae61fc0dbfe440df6718133c18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86352 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-18sal_Char->char in cppcanvas..cuiNoel Grandin4-13/+13
Change-Id: I7e9fa7011f1e0bf143f86055718c772caebf8ee6 Reviewed-on: https://gerrit.libreoffice.org/85397 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-03Adapt CPPUNIT_ASSERT to C++20 deleted ostream << for sal_Unicode (aka char16_t)Stephan Bergmann2-0/+2
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r3.html> "char8_t backward compatibility remediation", as implemented now by <https://gcc.gnu.org/ git/?p=gcc.git;a=commit;h=0c5b35933e5b150df0ab487efb2f11ef5685f713> "libstdc++: P1423R3 char8_t remediation (2/4)" for -std=c++2a, deletes operator << overloads that would print an integer rather than a (presumably expected) character. But for simplicity (and to avoid issues with non-printing characters), keep printing an integer here. Change-Id: I751b99ee32d418eb488131ffa130d6f7d6d38dc7 Reviewed-on: https://gerrit.libreoffice.org/84348 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-23cppcheck: performing init in init list (comphelper/connectivity/cppu/cui)Julien Nabet1-2/+3
Change-Id: I786c2c10e8b37b48adf6d619c0fa6a905de1bf7f Reviewed-on: https://gerrit.libreoffice.org/83584 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-22Extend loplugin:external to warn about classesStephan Bergmann12-0/+72
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-08Avoid repeated calls cppu::detail::loadModule -> osl_getModuleURLFromAddressStephan Bergmann1-2/+27
...where the latter are reportedly expensive. Both <https://gerrit.libreoffice.org/#/c/75162/> "tdf#121740 related, cache external mapping in cppu::loadExternal" and <https://gerrit.libreoffice.org/#/c/82261/> "tdf#121740 add cache to win osl_getModuleURLFromAddress" attempted to reduce the costs observed when loading one specific document by introducing caches below cppu::detail::loadModule's call to osl::Module::loadRelative. On the other hand, this change reduces the number of calls to osl_getModuleURLFromAddress by computing the base URI in cppu::detail::loadModule only once. For my local Linux --enable-dbgutil build, for `instdir/program/soffice '109340 class14.ppt'` and then exiting LO again (with the document attached at <https://bugs.documentfoundation.org/show_bug.cgi?id=121740#c0>), this reduces the number of calls to osl_getModuleURLFromAddress from 3775 to 22. (Many of those calls originated from cppu::getCaughtException or cppu::throwException, as in osl_getModuleURLFromAddress osl_getModuleURLFromFunctionAddress osl::Module::getUrlFromAddress osl_loadModuleRelative osl::Module::loadRelative cppu::detail::loadModule cppu::loadModule cppu::loadExternalMapping uno_getMapping com::sun::star::uno::Mapping::Mapping cppu::throwException .) Unfortunately, this needs to duplicate functionality from osl_loadModuleRelative (sal/osl/all/loadmodulerelative.cxx) somewhat, as the stable SAL interface only offers functionality to load relative to a given function, not relative to a given base URI. (And extending the stable SAL interface for this one use is not worth the maintenance costs.) Change-Id: Ib58814136d11c67d1419b0224d12e30bb710e613 Reviewed-on: https://gerrit.libreoffice.org/82290 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-28loplugin:stringadd improve detectionNoel Grandin1-2/+1
if one side of the expression is a compile-time-constant, we don't need to worry about side-effects on the other side Change-Id: Iee71ea51b327ef244bf39f128f921ac325d74e2b Reviewed-on: https://gerrit.libreoffice.org/81589 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-17Remaining loplugin:bufferaddStephan Bergmann3-21/+9
...that had been missing because the plugin didn't implement postRun, so it didn't report anything when run as part of the shared plugin. (But did report the expected warnings when run as a standalone plugin during CompilerTest_compilerplugins_clang.) Most fixes are straightforward. A noteworthy one is PreparedStatement::setBytes in connectivity/source/drivers/postgresql/pq_preparedstatement.cxx: The old preallocation of a 20 character OStringBuffer might have prevented buf.append( reinterpret_cast<char *>(escapedString), len -1 ); from potentially throwing std::bad_alloc, which would have caused escapedString to be leaked. Even though that 20-character preallocation was likely just random junk and not meant to address the potential leak, lets address it now. Change-Id: Ib506332d061684a22a74e5e39e591539fd2c4900 Reviewed-on: https://gerrit.libreoffice.org/80925 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>