| Age | Commit message (Collapse) | Author |
|---|
|
And use an overloaded helper function with a better (?) unified name
to show that the result is not an O(U)String.
Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
At least for me, this was needed when I added --without-system-cairo
--without-system-fontconfig --without-system-freetype
--without-system-harfbuzz to my otherwise fairly normal autogen.input
on Linux.
Change-Id: I149a57c24d6c11d710298125e53cb9524cb3dcaa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140001
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Fixes CVE-2022-38784
Add external/poppler/disable-freetype.patch.1 to get rid of some new
code that unconditionally requires freetype, to avoid building that on
WNT/MACOSX.
Change-Id: I854d1865286b6fb4112cdf37898cda0203c52f2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139941
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
need to move it, because modules "below" vcl want
to use the debug output method
Change-Id: Ibcaf4089a1e0b3fcc0b5189c7ebf1aae90f50b48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139791
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
With Poppler 22.09.0, LO fails to build with:
```
/var/tmp/portage/app-office/libreoffice-7.3.5.2/work/libreoffice-7.3.5.2/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.cxx:682:36: error: too many arguments to function call, expected single argument 'start', have 3 arguments
state->getLineDash(&dashArray, &arrayLen, &startOffset);
~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~
/usr/include/poppler/GfxState.h:1506:32: note: 'getLineDash' declared here
const std::vector<double> &getLineDash(double *start)
^
1 error generated.
```
Poppler changed the getLineDash interface:
```
- void getLineDash(double **dash, int *length, double *start)
+ const std::vector<double> &getLineDash(double *start)
```
Signed-off-by: Sam James <sam@gentoo.org>
Change-Id: I29e18f20d7650a7fcac1bc8ab4aaa04aaa2ab8fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139249
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
With 16k column support in Calc enabled by default in
commit 4c5f8ccf0a2320432b8fe91add1dcadf54d9fd58
Date: Tue Mar 8 12:44:49 2022 +0100
change default Calc number of columns to 16384 (tdf#50916)
, the number of Calc cells in a spreadsheet is larger than
SAL_MAX_INT32, meaning that a 32-bit a11y child index is no more
enough and using it resulted in integer overflows in
methods handling corresponding Calc cells in the a11y layer.
This e.g. had the effect of the Orca and NVDA screen readers
not announcing focused or selected cells properly when their
a11y child index was out of the 32-bit integer range.
Switch the internal a11y child indices to 64 bit to
be able to handle this properly internally.
Since the platform APIs (at least AT-SPI on Linux and
IAccessible2 on Windows; from what I can see LO's macOS
a11y bridge doesn't directly expose the child index)
are still restricted to 32 bit, larger child indices
still cannot be exposed via the platform APIs.
As a consequence, use of the the IAccessible2 and
AT-SPI methods that use the child index remains
problematic in those cases where the child index
is larger. However, as an alternative to using the
AT-SPI Table interface and the IAccessibleTable/
IAccessibleTable2 interfaces with the child index
to retrieve information about a specific cell,
both AT-SPI and IAccessible2 also provide interfaces
to retrieve that information directly
from the cell object (TableCell interface for AT-SPI,
IAccessibleTableCell for IAccessible2).
Those interfaces are already implemented/exposed
for winaccessibility (s. `CAccTable`) and the
qt5/qt6/kf5 VCL plugins (s. the `QAccessibleTableCellInterface`
methods implemented in `QtAccessibleInterface`).
With the switch to 64-bit internal a11y child indices,
these now behave correctly for cells with a child
index that doesn't fit into 32 bit as well.
NVDA on Windows already uses the IAccessibleTableCell
interface and thus announcing focused cells works fine
with this change in place.
Orca on Linux currently doesn't make use of the AT-SPI
TableCell interface yet, but with a suggested change to
do so [1], announcement of selected cells works
with the qt6 VCL plugin with a current qtbase dev branch
as well - when combined with the suggested changes
to implement support for the AT-SPI TableCell interface
in Qt [2] [3] and the LO change based on that [4] and
a fix for a nullptr dereference [5].
The gtk3 VCL plugin doesn't expose the AT-SPI
TableCell interface yet, but once it does so
(via `AtkTableCell`), it also works with the
suggested Orca change [1] in place.
(Adding that is planned for an upcoming change,
works with a local WIP patch.)
For handling return values that are larger than what
platform APIs support, the following approach has
been chosen for now:
1) When the return value is for the count of
(selected) children, the maximum value N
supported by the platform API is returned.
(This is what `ScAccessibleTableBase::getAccessibleChildCount`
did previously.)
The first N elements can be accessed by their
actual (selection) indices.
2) When the return value is the child/cell index,
-2 is returned for objects whose index is greater
than the maximum value supported by the platform
API.
Using a non-negative value would mean that the
index would refer to *another* actually existing
child. A child index of -1 on the other hand
tends to be interpreted as "child is invalid" or
"object isn't actually a child of its (previous)
parent any more)". For the Orca case, this would
result in objects with a child index of -1
not being announced, as they are considered
"zombies" [6].
What's still somewhat problematic is the case where
more than 2^31 children are *selected*, since access
to those children still happens by the index into
the selection in the platform APIs, and not all
selected items are accessible this way.
(Screen readers usually just retrieve
the first and last element from the selection and
announce those.)
Orca already seems to apply different handling for the
case for fully selected rows and columns, so
"All cells selected" or "Columns ... to ... selected"
is announced just fine even if more than 2^31
cells are selected.
(Side note: While Microsoft User Interface
Automation - UIA - also uses 32-bit indices, it also
has specific methods in the ISelectionProvider2
interface that allow to explicitly retrieve the
first and last selected item,
`ISelectionProvider2::get_FirstSelectedItem` and
`ISelectionProvider2::get_LastSelectedItem`, but
we currently don't support UIA on Windows.)
Bound checks at the beginning of the methods from the
`XAccessibleContext`, `XAccessibleSelection` and
`XAccessibleTable` interfaces that take a child index
(or in helper methods called by those) should generally
already prevent too large indices from being passed to
the methods in the lower layer code that take smaller
integer types. Such bound checking has been
been added in various places where it wasn't present yet.
If there any remaining issues of this
kind that show after this commit, they can probably be
solved in a similar way (s.e.g. the change to
`AccessibleBrowseBox::getAccessibleChild` in this
commit).
A few asserts were also added at
places where my understanding is that values shouldn't
be larger than what is supported by a called method
anyway.
A test case will be added in a following change.
[1] https://gitlab.gnome.org/GNOME/orca/-/merge_requests/131
[2] https://codereview.qt-project.org/c/qt/qtbase/+/428566
[3] https://codereview.qt-project.org/c/qt/qtbase/+/428567
[4] https://gerrit.libreoffice.org/c/core/+/138750
[5] https://codereview.qt-project.org/c/qt/qtbase/+/430157
[6] https://gitlab.gnome.org/GNOME/orca/-/blob/82c8542002e36e0d3d918088d583162d25136143/src/orca/script_utilities.py#L5155
Change-Id: I3af590c988b0e6754fc72545918412f39e8fea07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139258
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib186c453aafc9bc29fd5c7d82578ca4157aed31e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138345
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3b80d0f5b6d39c071242bc6ccc1e4333886c835d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137309
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8539dd5d9490a14ebac0520486a8322ff86a6cb6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137081
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3d892319f4af0c187455bc9c13b6edb0d52ac023
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137079
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I61deb7d5271bf87ac1bb3aad54c430ace8fd3f9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136975
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
which is internal API, unused (as far as I can tell) by external
users.
This state is purely a bitset
(as implemented by utl::AccessibleStateSetHelper)
so we can just return it as a 64-bit value.
This shaves significant time off the performance profiles
of code that loads very complex shapes, because this state
is frequently used, and we no longer need to allocate a return
value on the heap for every call.
Change-Id: Icf1b3bd367c256646ae9015f9127025f59459c2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136786
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
casting to TextElement is very hot here
Change-Id: I3195da6f09edb270eebdc6f38a1bbb2405b74de6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136659
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I05af862137666606e557dc3fabe1c3ea249ee10a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136656
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
when opening complex pdf
Change-Id: I67146a60d016964c96a3994c5a0334287f7bab0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136654
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I549947ad9ab93ed02049f7be5afad6be5ed69a52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136633
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ieded279152946830b2619ac80c4a9639d616557a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136398
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8ee9f1a53cc4389e6a4d44e9765b478b5edfffd4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136342
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I8ee9f1a53cc4389e6a4d44e9765b478b5edfffd3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136261
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
for UX compatibility with PP: Ctrl-A turns off 'mouse as pen' mode
Change-Id: I0379580f4034f07f044dc1079c14898f3014face
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135579
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
|
|
look for local variables that can be std::move'd to parameters
off by default, since it doesn't do proper data flow analysis
Change-Id: I3403a0fcffd165bdea6a772528bc53995c5fdb40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135527
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
As reported by Julien, once the mediawiki extension is installed, the
xHandler in framework::DispatchProvider::implts_searchProtocolHandler()
points to an UNO component implemented in Java, and we crash in
dynamic_cast<>(), at least on Linux with gcc 7.5 and libstdc++.
This dynamic_cast<>() call was added in commit
c0fa456436947a5c167c652d19a884064b43c03d (tdf#149261 sdext: fix crash on
starting the presenter console for the 2nd time, 2022-05-26), to allow
the presenter console to opt out from protocol handler caching. It was
expected that the proxy object created for a Java UNO component would
simply return nullptr when we try to dynamic_cast<>() it down to a C++
interface.
Fix the problem by moving the interface to an UNO one: this side-steps
the dynamic_cast<>() crash at the price of introducing an UNO interface,
which is not meant to be part of the public UNO API (but at least it's
not published).
It may still make sense to improve the bridges/ code at some stage to
not crash in dynamic_cast<>() on generated Java proxy objects.
Change-Id: Iaac44515339e0dc15dddc3be45ef7dee7331e47a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135114
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
This started with commit 3f768cddd28a2f04eb1ffa30bed4474deb6fbfc4
(framework: avoid re-creating protocol handler instances all the time,
2022-05-02). In case there are 2 monitors, then one monitor shows the
slideshow, the other shows the presenter console. The presenter
console's protocol handler in
sdext::presenter::PresenterProtocolHandler::Dispatch::Dispatch() has
mpPresenterController->GetWindowManager() as an empty reference on the
2nd time the presentation starts.
The above commit started to cache protocol handler instances at a frame
level for performance reasons, and this is meant to be safe in general,
but the presenter console's window manager is re-created between
slideshow runs, so it depends on framework/ code to re-create the
protocol handler all the time, which is problematic here.
Fix the problem by introducing a framework::CacheInfo interface that
allows protocol handler implementations to signal if they want to avoid
being cached.
This should be good enough for now, but if later it turns out that there
are too many broken protocol handlers out there, then we can consider
flipping the default and only cache handlers which explicitly opt in for
this behavior. This is not done in this commit.
Change-Id: Ic159813b1b339540bc8c4e780c4d6d7d2d4d2445
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135020
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I06456afa84314b3348bce177c939f510e00aa743
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134993
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...where a signed and an unsigned value are compared, and the signed value has
just been proven to be non-negative here
Change-Id: I20600d61a5d59d739bc1bee838c0038e4611aec2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134875
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I78f6972f0fe94423e00f2c3766df694d8e118439
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133784
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
found by examining uses of OUString::copy() for likely places
Change-Id: I6ff20e7b273ad6005410b82719183c1122f8c018
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133617
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
for which we have o3tl:: equivalents
Change-Id: I4670fd8b703ac47214be213f41e88d1c6ede7032
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
where we can convert that to
o3tl::toInt32(o3tl::getToken(
and avoid the heap allocation of a temporary string
Change-Id: Ib11c19c6e6cdc0de3e551affd3578d181e292de4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132810
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
since we now have o3tl versions of those that work on
string_view.
Also improve those o3tl functions to support both string_view
and u16string_view
Change-Id: Iacab2996becec62aa78a5597c52d983bb784749a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132755
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we can use it in places where we cannot include comphelper
Change-Id: Iba0ba3e4c0dcf0f9d1f09092a77c3b2010ec4f6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132732
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icf42e00575edf8fc847bccf9c9505cd9710fc9b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132509
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#42949 for motivation
Change-Id: I97c1a0e8c7f26807b12e6062581066d09ea13086
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130114
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I8f2dd2049a70dde809a1b1afb1f67d5feaf60d8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130222
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
It was like this ever since 969aac0edf437ec0cad0baadfde46188c4822161
"INTEGRATION: CWS pdf25", but the single caller of encodeBase64 passes a
sal_Int32 value, and all use of i_nBufferLength in encodeBase64 are in
sal_Int32-based computations.
Change-Id: I2963a05bf5a83aaee25cdd71c11d28481b28061a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130067
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...values from the embeded 'PS' font names.
Change-Id: I8465a6b1d845ce626848112f0a735a9ee3696e5c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129136
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
SAL_WARN should be some message which showns where the program
runs abnormally. Normal debugging output code should be SAL_INFO,
and if you have set it to SAL_WARN for easy debugging you should
set it back to SAL_INFO or delete those lines when submit.
Otherwise our dbgutil terminal will be flood with unrelated
messages
Change-Id: I0767bfbeb7a21f208be12208009ccda8b6c72bab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118763
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...instead of by listing the content somewhat redundantly in the Rdb_*.mk
files, to avoid duplication of logic for components that are only built
conditionally (and thus should only be included conditionally in the
corresponding Rdb). To achieve that, add an "rdb" parameter to
gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros
that internally call gb_ComponentTarget_ComponentTarget), which is used to make
the appropriate gb_Rdb_add_component call internally from within
gb_ComponentTarget_ComponentTarget. (As a special case,
gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that
has already been done by the corresponding gb_Library_set_componentfile call, so
allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to
support that special case.)
Most Rdb_*.mk files are thus mostly empty now. One exception is
i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as
needed during the build in CustomTarget_i18npool/localedata.
1c9a40299d328c78c035ca63ccdf22c5c669a03b "gbuild: create services.rdb from built
components" had already tried to do something similar (in addition to other
things) under a new --enable-services-rdb-from-build option. However, that
approach had four drawbacks that this approach here addresses (and which thus
partly reverts 1c9a40299d328c78c035ca63ccdf22c5c669a03b):
1 Rdb_services shall not contain the component files of all libraries that are
built. While that commit filtered out the component files that go into
Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files
that go into others like Rdb_postgresql-sdbc
(connectivity/Rdb_postgresql-sdbc.mk).
2 The code added by that commit to Makefile.gbuild codified the knowledge that
there is an Rdb_services, which is brittle.
3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge
(for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle.
4 Introducing an --enable-services-rdb-from-build option needlessly provided
two different ways how the content of Rdb_services is assembled.
The changes done here would leave --enable-services-rdb-from-build as a
misnomer, as it no longer controls how Rdb_services is assembled. I thus
renamed it to --enable-customtarget-components, as that is apparently what it
still does now.
Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
slot was introduced with
commit 27452a082237065ac4cf475c8398241907164b2c
Date: Wed Oct 10 14:32:04 2007 +0000
INTEGRATION: CWS pppopt02 (1.24.74); FILE MERGED
2007/09/28 14:52:06 sj 1.24.74.1: added slot to be able to clear the undomanager
as 27115, but got renumbered to 27118 with
commit 35fe915b7cf508356a88897d520b89fc986407fb
Date: Wed Jun 10 15:47:52 2015 +0200
Fix sd ID conflicts and duplicates
using its name is verified to call the expected handler for it
Change-Id: I656d91937612b0807353455930328aa37d5eecb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126581
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Seems the first poppler including poppler-cpp.pc.in and also
cpp/poppler-version.h.in was 0.14.0.
So this also increases the minimal system poppler dependency from
* poppler 0.12.0 (Wed Sep 9, 2009)
to
* poppler 0.14.0 (Tue Jun 8, 2010)
Compiling the internal poppler, we're up-to-date anyway.
Change-Id: Iee07cfeb43f4320fd596c772eeb26662505d0daf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125778
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
which results in lots of nice string_view improvements picked up by the
plugins
Change-Id: Ib0ec3887816b3d4436d003b739d9814f83e244b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125657
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I10ff73f89c965beb3cfb5fc3a40dd959d8f77aaa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124600
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1992d1ffbbc80efe9749ebd254971a0a92a10019
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124386
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
since it needs 2 allocations instead of one
This partially reverts commit d64a6e2245169e5e4a3f8bc5388b4fff4984e5f4 .
Change-Id: Iadd8193a02bd922105c082fe3bbcc6f8e9f96b22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124069
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...by making the OUString's pData point to the OUStringLiteral, instead of
copying the contained characters. This is one of the improvements that had not
been done as part of e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn
OUStringLiteral into a consteval'ed, static-refcound rtl_uString": "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." (Simply
dropping the OUStringLiteral overload was not possible in this case, though, as
that would have lead to ambiguities among the various OUString and
std::u16string_view overloads.)
The now-deleted OUStringLiteral rvalue reference overload means that some
existing assignments from ternary-operator OUStringLiteral<N> to OUString no
longer compile and had to be replaced with uses of std::u16string_view. Those
had not already been replaced in e6dfaf9f44f9939abc338c83b3024108431d0f69
because they happened to use OUStringLiteral instances of identical length N in
both arms of the ternary operator, so did not already start to fail to compile
back then.
Change-Id: I328e25b8324d045774e811d20a639f40d6a9a960
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124040
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If3cebeadff5496ae214614b49116060d24b6082f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123696
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
... 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>
|
|
Change-Id: I46e0f73f67cffb11ab5f1cf2453450a3066eb1fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123425
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
