summaryrefslogtreecommitdiff
path: root/sdext
AgeCommit message (Collapse)Author
2021-04-08update PCHsLuboš Luňák
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-08lok: remove event listener when disposingHenry Castro
In order to prevent that the event listener holds the object reference count when removed, ensure they are removed when disposing the object. Change-Id: I7cb4cb7d87acfc9610c2498760ade531456fe22e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113493 Tested-by: Jenkins Reviewed-by: Henry Castro <hcastro@collabora.com>
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein
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-01lok: remove frame action listener when disposingHenry Castro
In order to prevent that the frame action listener holds the object reference count when removed, ensure they are removed when disposing the object. Change-Id: If83574e31230d9c683adaf36af36485650fd2c50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113389 Tested-by: Jenkins Reviewed-by: Henry Castro <hcastro@collabora.com>
2021-03-26loplugin:flattenNoel
Change-Id: Ib7a895fba66f8dc9b6501e61631c02694053b7fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113157 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-03-25loplugin:unusedvarsglobalNoel
Change-Id: Ie73c8bec0196c680311b0959f3a17c3af900ce88 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113084 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-03-25const OUString -> const OUStringLiteralMike Kaganski
Mostly automated rewrite Change-Id: Ie020a083f898bc126b8fb039d4ecb2e687172da1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112965 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-03-24Using .md extension/Markdown syntax for modules READMEHossein
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-21cid#1474243 Uninitialized scalar variableCaolán McNamara
and cid#1473901 Uninitialized scalar variable Change-Id: I6a1d0784865c1a77eacbe25497b97ea63cf3705c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112849 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-03-20cid#1474176 Unchecked return value from libraryCaolán McNamara
Change-Id: Iaba514e372ff9892bb2901b967cfd4a5a71e6fbf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112779 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-03-09Make sal/config.h the first in pchMike Kaganski
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-02-21loplugin:refcounting in sdNoel
Change-Id: Ic95aa7a3c1fdab1baef744ec85ffc9c98dee5f1e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111272 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-18loplugin:referencecasting in sdextNoel
Change-Id: I24514eefb96d04576eed45608c259b2f8dbeda7b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111078 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-08update pchesCaolán McNamara
Change-Id: Icf55ddda055d11b649e7607c2cdd8b6d6ddfefbc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110483 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-02-08Improve loplugin:cppunitassertequal for CPPUNIT_ASSERT(a && b)Stephan Bergmann
...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-05Revert "Fix typo in code"Stephan Bergmann
This reverts commit 3ed9bba283a6a67864c0928186e277240be0d9ba. osl_Pos_Absolut (include/osl/file.h) is part of the stable URE interface; it must not be changed. Change-Id: I1f49923a9351e4be5aee39b10720d38b424feb9b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110435 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-04Fix typo in codeAndrea Gelmini
Change-Id: Ib8b306a27d25a34e784aeeb72708b0d5d1511f3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110394 Tested-by: Jenkins Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
2021-02-02tdf#134281 [API-CHANGE] Add keyboard shortcut for UsePen and EraseInkGabor Kelemen
As suggested by UX meeting: - Remove P and N keys from previous/next slide - Assign them to Pen (on=off) and erase ink commands Do this for presenter console as well. Modify help text of the presenter console to reflect these changes. Change-Id: I28d2178f7391739d4f8f5e8f63ab54714fcc97c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109108 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-01-28simplify code, use more subView()Noel
Change-Id: I569c7f34acbdf8451cd5c9acf1abd334637072d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110051 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-26loplugin:passstuffbyrefNoel
Change-Id: I330e0ab6c9955939dad313f9d472f93e39dbd313 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109924 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-25PresenterSlideSorter::mouseMoved: Merge identical ifDr. David Alan Gilbert
cppchecker spotted a pair of neighbouring if's with identical conditions; merge them. Change-Id: I29e13eb5eeca157d06f98c94587167c1a2ddec12 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109850 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2021-01-13Silence Boost bind deprecation warningStephan Bergmann
> In file included from sdext/source/pdfimport/pdfparse/pdfparse.cxx:35: > In file included from external/boost/include/boost/bind.hpp:30: > workdir/UnpackedTarball/boost/boost/bind.hpp:36:1: warning: The practice of declaring the Bind placeholders (_1, _2, ...) in the global namespace is deprecated. Please use <boost/bind/bind.hpp> + using namespace boost::placeholders, or define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior. [-W#pragma-messages] > BOOST_PRAGMA_MESSAGE( > ^ since e0f1b5bd94550835c639efda4e4c9a801c78dbe9 "Upgrade external/boost to latest Boost 1.75.0". boost/bind/bind.hpp and boost::placeholders appear to date back to before our Boost 1.66 baseline. Change-Id: I766be46fca02693fe0114c7c5855e6d94f7860a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109228 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-09fix coverity parse errorsCaolán McNamara
Change-Id: I3a1179947704452e3ffec02be59d0f7bf0b75ab0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109017 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-01-04loplugin:stringviewparam: operator +=Stephan Bergmann
Change-Id: I30ce1b5bd8fb168da7067c1967c5af2569df2653 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108512 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-26tdf#88205: Adapt uses of css::uno::Sequence to use initializer_list ctorBayram Çiçek
Change-Id: Id4034a57580f37fd71f841deec9edfe9b7c26a67 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108286 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-12-26New loplugin:stringliteralvarStephan Bergmann
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for details. (Turned some affected variables in included files into inline variables, to avoid GCC warnings about unused variables.) Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-20No longer need to worry about ambiguous operator== in loplugin:stringviewparamStephan Bergmann
...after 46c5de832868d2812448b2caace3eeaa9237b9f6 "make *String(string_view) constructors explicit" Change-Id: I6e884c762a2fc91f5dd6fbb197a596fd60f17cae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108043 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann
...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-12-04update pchesCaolán McNamara
Change-Id: I3e22c2000da03f6f3345353846213203993aa865 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107192 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-01tdf#42949 Fix new IWYU warnings in directories s*Gabor Kelemen
Except recently checked sc, sd, svx, sw Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ice1b86628e4f22a39f307b9c5fa567b6ab9d5acb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106917 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-30loplugin:stringviewparam include comparisons with string literalsNoel
Change-Id: I8ba1214500dddaf413c506a4b82f43d63cda804b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106559 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-24loplugin:stringviewparam extend to comparison operatorsNoel
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-22tdf#123936 Formatting files in module sdext with clang-formatPhilipp Hofer
Change-Id: Ibfed67a0f772ea0c02bf0e7267e9ed46517e2018 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105704 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
2020-11-16replace std::min(std::max()) with std::clampNoel
Change-Id: I76e34e8020d98292e8ffde387542b7029f85a42d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105754 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11loplugin:stringviewNoel
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-11disable O(U)String::concat for internal codeNoel Grandin
in favour of the more widely used, and better optimised, operator+ Change-Id: I6a1b37e0f3d253af1f7a0892443f59b620efea63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105523 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-13sdext: fix use-after-free on global AccessibleFocusManagerMichael Stahl
The problem is that the destructor of the vector maFocusableObjects ends up dispose()-ing every element, which calls back into AccessibleFocusManager to remove the element from the vector, which invokes its destructor a 2nd time. Move it to the stack so it doesn't double-free itself. ERROR: AddressSanitizer: heap-use-after-free on address 0x612001571c00 at pc 0x7fc5e723ca72 bp 0x7fffbaa8d6d0 sp 0x7fffbaa8d6c8 READ of size 1 at 0x612001571c00 thread T0 #0 0x7fc5e723ca71 in cppu::WeakComponentImplHelperBase::release() cppuhelper/source/implbase.cxx:84:9 #1 0x7fc595211b27 in cppu::PartialWeakComponentImplHelper<com::sun::star::accessibility::XAccessible, com::sun::star::accessibility::XAccessibleContext, com::sun::star::accessibility::XAccessibleComponent, com::sun::star::accessibility::XAccessibleEventBroadcaster, com::sun::star::awt::XWindowListener>::release() include/cppuhelper/compbase.hxx:86:36 #2 0x7fc5952093e4 in rtl::Reference<sdext::presenter::PresenterAccessible::AccessibleObject>::~Reference() include/rtl/ref.hxx:113:22 #3 0x7fc59522acd4 in void std::_Destroy<rtl::Reference<sdext::presenter::PresenterAccessible::AccessibleObject> >(rtl::Reference<sdext::presenter::PresenterAccessible::AccessibleObject>*) /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/stl_construct.h:140:19 0x612001571c00 is located 64 bytes inside of 312-byte region [0x612001571bc0,0x612001571cf8) freed by thread T0 here: #0 0x4be997 in free (instdir/program/soffice.bin+0x4be997) #1 0x7fc5ea2a5104 in rtl_freeMemory sal/rtl/alloc_global.cxx:51:5 #2 0x7fc5952097f4 in cppu::WeakComponentImplHelperBase::operator delete(void*) include/cppuhelper/compbase_ex.hxx:66:11 #3 0x7fc595211e07 in sdext::presenter::PresenterAccessible::AccessibleObject::~AccessibleObject() sdext/source/presenter/PresenterAccessibility.cxx:67:28 #4 0x7fc5e74a11b4 in cppu::OWeakObject::release() cppuhelper/source/weak.cxx:233:9 #5 0x7fc5e723cb05 in cppu::WeakComponentImplHelperBase::release() cppuhelper/source/implbase.cxx:86:18 #6 0x7fc595211b27 in cppu::PartialWeakComponentImplHelper<com::sun::star::accessibility::XAccessible, com::sun::star::accessibility::XAccessibleContext, com::sun::star::accessibility::XAccessibleComponent, com::sun::star::accessibility::XAccessibleEventBroadcaster, com::sun::star::awt::XWindowListener>::release() include/cppuhelper/compbase.hxx:86:36 #7 0x7fc5e7194115 in com::sun::star::uno::Reference<com::sun::star::uno::XInterface>::~Reference() include/com/sun/star/uno/Reference.hxx:110:22 #8 0x7fc5e71f3944 in com::sun::star::lang::EventObject::~EventObject() workdir/UnoApiHeadersTarget/udkapi/comprehensive/com/sun/star/lang/EventObject.hdl:18:27 #9 0x7fc5e723d395 in cppu::WeakComponentImplHelperBase::dispose() cppuhelper/source/implbase.cxx:118:5 #10 0x7fc595211e27 in cppu::PartialWeakComponentImplHelper<com::sun::star::accessibility::XAccessible, com::sun::star::accessibility::XAccessibleContext, com::sun::star::accessibility::XAccessibleComponent, com::sun::star::accessibility::XAccessibleEventBroadcaster, com::sun::star::awt::XWindowListener>::dispose() include/cppuhelper/compbase.hxx:90:36 #11 0x7fc5e723c6e9 in cppu::WeakComponentImplHelperBase::release() cppuhelper/source/implbase.cxx:79:13 #12 0x7fc595211b27 in cppu::PartialWeakComponentImplHelper<com::sun::star::accessibility::XAccessible, com::sun::star::accessibility::XAccessibleContext, com::sun::star::accessibility::XAccessibleComponent, com::sun::star::accessibility::XAccessibleEventBroadcaster, com::sun::star::awt::XWindowListener>::release() include/cppuhelper/compbase.hxx:86:36 #13 0x7fc5952093e4 in rtl::Reference<sdext::presenter::PresenterAccessible::AccessibleObject>::~Reference() include/rtl/ref.hxx:113:22 #14 0x7fc59522acd4 in void std::_Destroy<rtl::Reference<sdext::presenter::PresenterAccessible::AccessibleObject> >(rtl::Reference<sdext::presenter::PresenterAccessible::AccessibleObject>*) /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/stl_construct.h:140:19 Change-Id: I95151807e9182ed5f43b63792fba86f83ee0bad8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104208 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-10-06loplugin:const& make some params and methods constNoel
Change-Id: I2973128a9c6c53187e1da400d1a5df763d515596 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104020 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-04loplugin:reducevarscope in sdextNoel
Change-Id: I92f57e803ebf47e77b5c1990984d0dee1cdd2c73 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103837 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-22OUStringLiteral/OStringLiteral coverity PARSE_ERROR workaroundCaolán McNamara
do more like commit 121771e37f7e2de41cd5643475861062bf25627b Date: Mon Sep 21 09:17:54 2020 +0200 Make some OUStringLiteral vars constexpr cause coverity can live with that Change-Id: I9efd7f848289c4865997a44c6780373068422227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann
...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-09improve loplugin:unusedvarsglobalNoel Grandin
to find any global variable, was checking the wrong property of VarDecl Change-Id: I454b4e0c1701bb0771768a1ee10cd738c4ab0726 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102278 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-08Remove some unused const variablesStephan Bergmann
Change-Id: Ida4f482c6477d73728c49302af19a4c9e73a9aae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102203 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-30Goodbye O[U]StringView, welcome O[U]String::ConcatStephan Bergmann
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 33ecd0d5c4fff9511a8436513936a3f7044a775a "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>
2020-08-29Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: I8d393bf42be181fad18829a46393714a95f32000 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101607 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-29Directly use OUStringBuffer::indexOfStephan Bergmann
Change-Id: I455a7857294a136a515bb68cc8321ede0e5d1c85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101575 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-29Simplify OUStringBuffer to OUString conversionStephan Bergmann
Change-Id: I9bd7722ebe7e29a1b68037c80e8d1c2c49d7984c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101572 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann
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-26[API CHANGE] Drop OSL_THIS_FUNC, directly use C++11 __func__Stephan Bergmann
It had been documented as "the macro OSL_THIS_FUNC is intended to be an office internal macro for now", so take the liberty of removing it, even if technically that can be considered an incompatible API change. Change-Id: I7580a932e1da54845934378a650e894f3f3a9062 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101406 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2025-01-01 17:33:40 +0000