summaryrefslogtreecommitdiff
path: root/cppuhelper
AgeCommit message (Collapse)AuthorFilesLines
2021-04-08update PCHsLuboš Luňák1-1/+1
Change-Id: Ia9d04447f927e270a55500e7f35723a729bc01dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113801 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.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-06update pchesCaolán McNamara1-1/+1
Change-Id: I835c8fcc237ece5cf9d7a3b261645139d022e9b4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113652 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@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-03-21update pchesCaolán McNamara1-1/+1
Change-Id: I60e61133c305673bb305e41957f5414820c7c358 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112790 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-03-12use std::unordered_map in cppuhelper ServiceManagerLuboš Luňák1-4/+4
It's faster and I do not see any reason for the map to be sorted. cppuhelper::ServiceManager::findServiceImplementation() may be called quite often e.g. during text layout by i18npool::BreakIterator. Change-Id: If8c77c506b88a0a3eac29e0d20d43d2110eed4ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112280 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-03-11cppu:OWeakObject zombie debuggingNoel1-0/+9
add some logic to catch re-animating objects early Change-Id: I42b13eaddbc227d8b0a4e786e86ced8fbb406cae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112268 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-03-09Make sal/config.h the first in pchMike Kaganski1-2/+2
By convention, it should be the first include in C/CXX files; so use of pch should not break that. Change-Id: Ic329c5f39e8f48ad1778724368e262e48972342b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112123 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-03-06update pchesJulien Nabet1-2/+1
I just used ./bin/update_pch.sh Change-Id: I06a7f36eb4c511b8d6c6477fd87e57f0d9702457 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112097 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-03-03update pchesCaolán McNamara1-1/+2
Change-Id: Ide49c48738ecd537d4eb69390d22807561d3b4e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111828 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-02-19update pchesCaolán McNamara1-2/+1
Change-Id: Ic4586057346b6de700c1bb6ff4cd759a11bb3e4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111231 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-02-17loplugin:referencecasting in cppuhelperNoel2-4/+4
Change-Id: Ie19f01a35ef656f5532c5ec41dbed1c0e4cf77d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111026 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann3-11/+13
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-04update pchesCaolán McNamara1-2/+1
Change-Id: I3e22c2000da03f6f3345353846213203993aa865 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107192 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-13tdf#123936 Formatting files in module cppu with clang-formatPhilipp Hofer2-10/+10
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-12loplugin:stringview (macOS)Stephan Bergmann1-1/+1
Change-Id: Ie3a6db501328e787d7b87dfd1aef73d9d79a49ae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105608 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-10new loplugin:reducevarscopeNoel Grandin1-1/+1
Change-Id: Iefe922c2e0d605114d54673d63eccc5e4abd545d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102143 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-06tdf#42949 Fix new IWYU warnings in directories c*Gabor Kelemen3-4/+11
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-10-01Add single-instance attribute for *.compoonent <implementation>sStephan Bergmann2-28/+88
...to ease the implementation in C++ code of constructor-based <implementation>s that shall be single-instance (and which would have been implemented with e.g. cppu::creaetOneInstanceFactory for non--constructor-based <implementation>s). See e.g. 6e35794cad555485955c3b43593497dcdbf29840 "terminate XDesktop properly in unit tests" and 6362ebab298549e8616c32cafd75cb3959ba7d65 "dbaccess: create instances with uno constructors" for the clumsy approach used until now, where the C++ constructor function uses a static instance that is cleared in dispose(), adding fake <singleton> entries to <implementation>s where necessary so that the ServiceManager will call those XComponent::dispose() functions when it itself gets disposed. For every <implementation>, the ServiceManager already holds an Implementation data structure, so it can easily hold a singleInstance there and clear it when the ServiceManager gets disposed. (One consequence is that single-instance implementations are now created with their Instance.mutex locked, but that should not cause problems in practice, given that the construction of a single- instance implementation should not recursively request its own construction anyway.) The new single-instance="true" attribute is mostly useful in combination with the constructor attribute (see above), but it can also be used for non-- constructor-based <implementation>s, at least in theory. (The single-instance="true" attribute is orthogonal to <singleton> elements. There are existing single-instance services---even if those should arguably have been defined as singletons in the first place---that can benefit from single-instance="true". And there are <implementation>s that support one or more <singleton>s alongside one or more <service>s, where the latter are not single-instance.) This new single-instance="true" attribute in *.component files should not interfere with the lo_get_constructor_map machinery in the DISABLE_DYNLOADING branch of cppuhelper::detail::loadSharedLibComponentFactory (cppuhelper/source/shlib.cxx) used by Android, iOS and some fuzzer code. AFAIU, the lo_get_constructor_map machinery should only ever come into play after the ServiceManager has decided whether or not to create a new instance based on the single-instance attributes in the *.component files. This commit only provides the new single-instance="true" attribute. Actual changes of <implementation>s and their C++ constructor functions are delegated to a series of follow-up commits. (So that they can easily be reverted individually should the need arise.) Change-Id: Iea6c0fc539d74477b7a536dc771b198df6b0510e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103734 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-21update pchesCaolán McNamara1-1/+2
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann1-16/+17
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "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>
2020-09-13tdf#124176 Use #pragma once in cppu, cppuhelperGeorge Bateman5-20/+5
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-09-04TabPage no longer needs to inherit from VclBuilderContainerCaolán McNamara1-2/+1
Change-Id: Iaab26ade1109daf732e58a2f3741cc43243e374c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102023 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02move Edit into toolkit only headersCaolán McNamara1-1/+2
Change-Id: If51bf7143116721e8f16272cf8aff797651d5ed1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101880 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann1-15/+15
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>
2020-08-27remove some unused includes and update pchesCaolán McNamara1-2/+1
Change-Id: I786548bef39fa711aabcff32b592b3fdc4a6f9fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101486 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-19Fix typosAndrea Gelmini1-1/+1
Change-Id: I58c510121a9f535b2a31854f10b5f6535554d379 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100988 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-14loplugin:simplifybool moreNoel Grandin1-1/+1
look for expressions like !(a && !b) which can be expanded out Change-Id: I72515a9638762b050f9a258c08da39ebfa2ef8e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100579 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-12SvTreeListBox can move into toolkit headers nowCaolán McNamara1-1/+2
Change-Id: I6b3b6ef1530a192f4b6bf87aa9688687063683ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100591 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-12-Werror,-Wuninitialized (apparently new in Clang 12 trunk)Stephan Bergmann1-1/+1
> cppuhelper/source/typemanager.cxx:1571:47: error: field 'entity_' is uninitialized when used here [-Werror,-Wuninitialized] > ServiceBasedSingletonDescription_Base(entity_->isPublished()), > ^ The code was like that ever since it was introduced in fa559f1c416884015d1d83d0a7ac8803e745d9df "WIP: Experimental new binary type.rdb format". Odd that that never caused an issue, but the code appears to at least never be executed during `make check`. Change-Id: I19fe78162c7c4a9211c380648595df9aa54bf4d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100554 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-10Make the C++/UNO bridge work to some extent on macOS on arm64Tor Lillqvist1-3/+3
Use the same code as for Linux on aarch64, with minor additional hacks. But that will not actually work in all cases, as there are slight differences in the ABI. See https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html Thus we can drop the use of the lo_mobile_throwException() hack that was very temporarily used. The run-time code generation requires use of a new API on macOS to work: See the use of pthread_jit_write_protect_np() in bridges/source/cpp_uno/shared/vtablefactory.cxx. For some reason, with the Xcode 12 betas, when compiling for arm64-apple-macos, the symbols for the type_infos for the UNO exception types (_ZTIN3com3sun4star3uno16RuntimeExceptionE etc) end up as "weak private external" in the object file, as displayed by "nm -f darwin". We try to look them up with dlsym(), but that then fails. So use a gross hack: Introduce separate real variables that point to these typeinfos, and look up and dereference them instead. If this hack ends up needing to be permanent, instead of having a manually edited set of such pointer variables, we should teach codemaker to generate corresponding functions, and look up and invoke them to get the std::type_info pointer. When compiling for x86_64-apple-macos, the type_info symbols end up as "weak external" which is fine. With this, LibreOffice starts and seems to work to some extent, and many unit tests succeed. Change-Id: I05f46a122a51ade1ac7dccd57cb90e594547740e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100408 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-08-07Use the lo_mobile_throwException() thing on macOS on arm64 for nowTor Lillqvist1-3/+3
Change-Id: I58720d25c4838f1f4ee79a2586a61cc7d03ef853 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100281 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-07-23Remove no longer relevant assertStephan Bergmann1-2/+0
...that was apparently meant to guard the following &context_values[0] that got changed to context_values.data() in c18e2ea2a52fc171c50fcb22d431e94c6aececc5 "New loplugin:data" Change-Id: Ic63d8e775f3b75cca7df2b08665cccc0b4c3ec3e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99316 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-12update pchesCaolán McNamara1-2/+1
Change-Id: I75602277a5a26b012a12f2c4f4b7ff5bb663b0b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98474 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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-06-05tdf#88205 Adapt uses of css::uno::Sequence to use initializer_list ctornienzu2-4/+2
Change-Id: Ic61c1d5829b510a71b8d444f29ffed36ee540ea8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94717 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-06-03loplugin:simplifypointertobool improveNoel Grandin1-11/+11
to look for the x.get() != null pattern, which can be simplified to x I'll do the x.get() == nullptr pattern in a separate patch, to reduce the chances of a mistake Change-Id: I45e0d178e75359857cdf50d712039cb526016555 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95354 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-20use for-range on Sequence in cppuhelper,cuiNoel Grandin4-58/+57
Change-Id: I482d48e29ddc9690d9c671cde2f6b0c611ec378d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94550 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-08compact namespace in canvas..cuiNoel Grandin6-13/+11
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-17loplugin:flatten in cppuhelperNoel Grandin5-501/+504
Change-Id: I814a109b7822d7a6cd23b5aa4220d496a4da2fb8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92425 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-14loplugin:buriedassign in c*Noel Grandin1-6/+10
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-10Fix typoAndrea Gelmini1-1/+1
Change-Id: Id3fe1d66cb1d3cb57f8aa5e652bf1c9ad6346091 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90286 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-03-05tdf#127781 Android Viewer: aarch64: Avoid throwing exceptions through bridgesMichael Weghorn1-4/+4
This basically extends what commit eb15ac837e06087fb8148330e9171d6697d89ee6 ("android: Avoid throwing exceptions through the bridges.", 2019-11-29), amended by f2f8a2ec10d87ffb23949338a9e4da1e1d704644 ("android: Actually let's avoid the exceptions via bridges only on aarch4.", 2019-12-02) did for the online-based Android app to cover the Android Viewer case as well. This makes Android Viewer work on aarch64, which previously crashed whenever trying to load a document. Change-Id: Id8b30e1dced583159cc4d81aaa18f4c25b901cff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90047 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-02-11android: Actually let's avoid the exceptions via bridges only on aarch4.Jan Holesovsky1-4/+6
Change-Id: Id2830f09ca6afd11f6f866565f37bdb7ba45bfb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84205 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-02-01make update_pch also consider files in <module>/src/**/incLuboš Luňák1-1/+4
With --enable-pch=full there's not much difference between a "public" header in <module>/inc and a private one in <module>/src/somewhere/inc . And since the script searches recursively, this apparently helps to find even more headers for lower pch levels. Change-Id: I8483d0aa5b4fea5a59107c20a8aa5f1ef694af0a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87799 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-01-28New loplugin:unsignedcompareStephan Bergmann1-3/+4
"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 0288c8ffecff4956a52b9147d441979941e8b87f "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>
2020-01-26simplify InterfaceContainerHelper::clearNoel Grandin1-7/+6
instead of relying on side-effects from instantiating an iterator Change-Id: Ie66b9e7ceeb3c4a0f4243fdd0a5ac37af77e98ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87412 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-24loplugin:makeshared in connectivity..cppuhelperNoel Grandin1-3/+3
Change-Id: Id8064e961a64bb03bc0fb61e375cdcf769b340cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87276 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-17Use std::vector in OInterfaceContainerHelper instead of SequenceNoel Grandin1-56/+31
instead of fighting the fact that Sequence is intended to be immutable getSequence() will become a little slower, but since getSequence() is called 5k times during 'make check', while add/remove are called 3M times, I think it's safe to say mutation is dominant. Change-Id: I23d127c93c589050d6c06c0da47871e1ebe7b52d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86929 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-15improve "convert OSL_ASSERT to assert"Noel Grandin1-2/+3
this fixes commit 3a0c4574449fc2313306c4e0e39bb7416cc20657, by converting the assert in removeInterface() to SAL_WARN_IF, and similarly for the related addInterface() method Comment from sberg on the original commit: This leaves OInterfaceContainerHelper::add-/removeInterface in somewhat inconsistent state (as addInterface OSL_ASSERTs non-null but then also explicitly checks for null, i.e., effectively supports null). css.lang.XComponent::add-/removeEventListener do not explicitly specify whether or not their arg may be null. I /think/ we traditionally supported null; asserting non-null thus might cause issues for 3rd-party code. Change-Id: I1e28cc03aa7dfe662125c573d60b447309009448 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86827 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-30 23:02:42 +0000