for
commit 27352b8163 (origin/master, origin/HEAD)
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Mon Feb 21 16:00:52 2022 +0200
Add XWeak constructor and operator= to uno::WeakReference
I accidentally created a new gerrit change for this, and thus managed to
miss sorting out various review comments.
(*) Fix version number in gcc3.map
(*) Narrow the interface (i.e. assume non-null parameter) in
WeakReferenceHelper
(*) Remove cargo-cult catch and OSL_ASSERT in WeakReferenceHelper
(*) Remove accidental indentation
Change-Id: I8d1b22dd42216e9293959032d92df65405fb054c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130349
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Guess in all the fixing when upstreaming all the WASM changes,
that hunk got lost. This actually makes the WASM build run, not
just compile.
Change-Id: Ided621af284e62961eb47957d74b31871a30a2bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129105
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
... and use the same fake exception rethrowing code then the
mobile platforms.
Change-Id: Ic90de1cfd1e0092d6064d041a613d60d9f5f76b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128596
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
...to 76e04aef4b "Rename LO-specific uno ini-file
(Linux: program/unorc) to 'louno'". (And yes, the original comment guessed
right: it is the URE uno ini-file that we look for here.)
Change-Id: I3006a5169ae066b984e415d17841f69db338b68b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128325
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
That flag is only supported by clang-cl, not by MSVC, and
c7c9f3f57a "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
1040228c35 "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 1040228c35 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
... 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>
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>
... 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>
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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
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>
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>
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/
Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Renaming all README files for all top level modules to README.md,
applying no content change at this stage to be able to track history
of the files. These files should be edited to use correct Markdown
syntax later.
Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
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>
Mike Kaganski