summaryrefslogtreecommitdiff
path: root/cppuhelper
AgeCommit message (Collapse)AuthorFilesLines
2021-12-21loplugin:flatten in canvas..cuiNoel Grandin1-31/+32
Change-Id: I208767eaa60d913fe2882403f1f9351eb08256f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127224 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-19use more cppu::BaseMutexNoel Grandin1-17/+11
Change-Id: I7ac096acfde05aa58a48fb76e895e880e27225d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127085 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-17Remove empty docpp doxygen comments around namespacesMiklos Vajna1-2/+0
I assume this was originally added to work around some broken doc generator, but we don't enforce comments for namespaces today, so this is no longer needed. Change-Id: Ia2311658516be84b26ae69e09362af560d793a7f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126963 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-12-02Fix clang-cl -Zc:dllexportInlines- buildStephan Bergmann1-1/+1
That flag is only supported by clang-cl, not by MSVC, and c7c9f3f57a2feae5d3bc3c47104786883ed09e44 "use clang-cl's -Zc:dllexportInlines- for clang-cl builds" apparently naively assumed that it would work to build LO with clang-cl and that flag without actually trying it out, and 1040228c356d75c5228cde4d6103f9b446848e4b "My clang-cl build does not work with -Zc:dllexportInlines-" effectively disabled it completely. The way to avoid unresolved external symbols during linking of URE libraries (see the 1040228c356d75c5228cde4d6103f9b446848e4b commit message) is apparently to also build libraries that the URE libraries depend on with the flag, hence the change from gb_Library_set_is_ure_library to gb_Library_set_is_ure_library_or_dependency. For now, I only marked those additional libraries (unoil and xmlreader) that actually caused issues when linking the URE libraries. Change-Id: I3a85c73246250981cd86b7ee41f87b41f393a4b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126012 Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2021-10-29Prepare for removal of non-const operator[] from Sequence in cppuhelperMike Kaganski4-41/+69
Change-Id: I692f1faf0b6ebe26771f3b8c5be1aa548ebd8515 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124355 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-15Simplify vector initialization in cppuhelperJulien Nabet1-8/+7
Change-Id: I1c1e36932673fe26fdd9daf21925fb952dbbfa73 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123663 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-15Remove non-const Sequence::begin()/end() in internal codeMike Kaganski1-1/+1
... to avoid hidden cost of multiple COW checks, because they call getArray() internally. This obsoletes [loplugin:sequenceloop]. Also rename toNonConstRange to asNonConstRange, to reflect that the result is a view of the sequence, not an independent object. TODO: also drop non-const operator[], but introduce operator[] in SequenceRange. Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-15Simplify OTypeCollection ctorsMike Kaganski1-198/+122
Change-Id: I775e0a425abcf616a6d61570edfdfd99c7b9d46a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123526 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-14Avoid COW overhead using css::uno::SequenceMike Kaganski1-1/+1
The scenarios are: 1. Calling sequence's begin() and end() in pairs to pass to algorithms (both calls use getArray(), which does the COW checks) 2. In addition to #1, calling end() again when checking result of find algorithms, and/or begin() to calculate result's distance 3. Using non-const sequences in range-based for loops, which internally do #1 4. Assigning sequence to another sequence variable, and then modifying one of them In many cases, the sequences could be made const, or treated as const for the purposes of the algorithms (using std::as_const, std::cbegin, and std::cend). Where algorithm modifies the sequence, it was changed to only call getArray() once. For that, css::uno::toNonConstRange was introduced, which returns a struct (sublclass of std::pair) with two iterators [begin, end], that are calculated using one call to begin() and one call to getLength(). To handle #4, css::uno::Sequence::swap was introduced, that swaps the internal pointer to uno_Sequence. So when a local Sequence variable should be assigned to another variable, and the latter will be modified further, it's now possible to use swap instead, so the two sequences are kept independent. The modified places were found by temporarily removing non-const end(). Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-11cppuhelper: suppress unhelpful warning C4996Michael Stahl1-0/+9
... that happens while implementing the class declared as deprecated with MSVC 2019. cppuhelper/source/typeprovider.cxx(33): warning C4996: 'cppu::OImplementationId': Uses broken double checked locking Change-Id: I469fe38bd276a554b1ef006d3da270b85f26554b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123422 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-10-11loplugin:moveparam in cppuhelperNoel Grandin2-7/+7
Change-Id: Idb6b4794e542791b5cf38b611c5d70a34fbe23b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123382 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-11In O[U]StringBuffer, make string_view params replacements for OUString onesStephan Bergmann1-1/+2
...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 1250aecd71fabde4dba990bfceb61bbe8e06b8ea "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>
2021-09-28Warn harder about unknown constructors and factories on iOS in XcodeTor Lillqvist2-0/+18
Use NSLog() and not just SAL_WARN(). There are so many irrelevant SAL_WARN() warnings displayed that these ones that can be extremely relevant are easily missed. I typically run the app in Xcode with SAL_LOG=-WARN. (Such warnings are typically caused by something missing from the solenv/bin/native-code.py.) Change-Id: I4ab16f4f652ac34319021c9427e2e9f911ee29e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122721 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122756 Tested-by: Jenkins
2021-09-20use MSVC's /Zc:inline option to reduce binary sizeLuboš Luňák1-2/+2
If I'm getting it right, MSVC has a non-conforming feature that allows to declare a function as inline without defining its body in the header, and it'll work if the function is actually emitted elsewhere, and the linker will sort it out. This seems to be implemented by forcing emitting of out-of-line copies of all inline functions, which is wasteful. /Zc:inline disables this useless feature, which seems to save quite some space (optimized build, starmath's .o files 350k->220k, smlo.dll 2.5M->2.2M). The docs don't say anything about binary compatibility, but treat it the same way as -Zc:dllexportInlines, just in case. This change also may help avoid the tdf#144598 problem for our AVX/etc. code, such as in Calc. Change-Id: I73cc5d46ba1e4245e8d3b6688804c2b9684d2f9a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122334 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-20use clang-cl's -Zc:dllexportInlines- for clang-cl buildsLuboš Luňák1-0/+2
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>
2021-08-15rtl::Static -> thread-safe static localNoel Grandin1-16/+5
Change-Id: Iac0501e6aa35cc3d8e62f6b6e68b76cf70233aae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120459 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-03Consolidate on C++17 std::scoped_lock instead of std::lock_guardNoel Grandin4-10/+10
as in commit 9376f65a26240441bf9dd6ae1f69886dc9fa60fa Change-Id: I3ad9afd4d113582a214a4a4bc7eea55e38cd6ff9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119927 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-02convert #defines to OUStringLiteralNoel Grandin2-6/+6
mostly by doing $ git grep -l '#define.*\"' -- *.cxx | xargs perl -pi -e 's/^#define\s+(\w+)\s+(\".*\")/constexpr OUStringLiteral \1 = u\2;/g' Change-Id: Idface893449b0ef2a3c5254865a300585d752fbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119669 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-18better to use a std::vector hereNoel Grandin1-1/+1
Change-Id: Ibd875907bc0618df3b27ed77625ff62c352019ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119109 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-18osl::Mutex->std::mutex in EnumerationNoel Grandin1-2/+3
Change-Id: I1f4e99e4a3619b1381d01a16b98128ae9bbbce07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119108 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-18osl::Mutex->std::mutex in ContentEnumerationNoel Grandin1-3/+4
Change-Id: I79457a4ffc957f6de47880fdc888648ab69d1349 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119107 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-17osl::Mutex->std::mutex in PropertySetMixinImplNoel Grandin1-8/+8
Change-Id: I45ae292e95efc57a125807d15c6c259533dd5f92 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119106 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-17osl::Mutex->std::mutex in OWeakConnectionPointNoel Grandin1-24/+23
it is at least a little bit cheaper than osl::Mutex (since it's not recursive) Change-Id: I4ecbbf33045888b9f5111c4224346341e71d4b05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119066 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-14cppuhelper : use std::mutex and remove useless rtl::StaticArnaud Versini1-15/+4
Change-Id: Idb272e664c4b745c4db96e505b60905c93937900 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116746 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-02throw() -> noexcept, part 2/3: Automatic loplugin:noexcept rewriteStephan Bergmann7-30/+30
Change-Id: I076f16d0536b534abf0ced4d76051eadb4c0e033 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114949 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 06:50:51 +0000