Age | Commit message (Collapse) | Author |
|
to make it more obvious when we are constructing heap OUStrings
code and potentially inadvertently throwing away performance.
And fix a handful of places so revealed.
Change-Id: I0cf390f78026f8a670aaab53424cd31510633051
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107923
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6800e23ead2767d245d5da71d2d40e0f8a6d7e1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106859
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Unused ever since the code was introduced in
5ea5c0afebd272d5f44e6524c0f67b5317639919 "#112923# embedded object for MS OLE".
(The accompanying
// TODO: use aContName and aEmbDocName in m_pOleObject->SetHostNames()
comment was removed when a307ad7ae029a0a62404996a63954e7026001ce3 "OLE: show
title of parent document in MSO" started to use the aEmbDocName parameter, which
had previously been unused too.)
Change-Id: I0fbb20dbf526a3fdbdc4a3e76e64fa80e8460480
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106571
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
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>
|
|
Change-Id: If177567a6e5ac934dec11a4b873005f563d77689
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105664
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I963aa5fb892a0be36212fd0587b69f217f017947
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105469
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: Icead3bb5715a08bc2a2dfbb16c074d1b19e316a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103855
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...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>
|
|
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: Ia481a860be174b817106ac13eccb5e53ee070aec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102577
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I90d4e3db3eefa41f8492cfe23c5088ea93134afc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101890
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
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>
|
|
See tdf#74608 for motivation.
Change-Id: I11ad7cf96d65332e418f1854803d62a30bacc7e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99163
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: I52734cc1420ae7915da3191cf94ac61287a0983a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99162
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
Change-Id: I2f22d455d2a936a85750eaab1fda215ebb6d9d48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98182
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I77dc12356ee45b1dee9acaf8a73dea81588822d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94554
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie93ac69592c3625b8e2e5db3619ce24597a07a7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93722
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
instead of using the heavyweight Sequence datastructures
Change-Id: Ica6b30490f2a1b4367acbf0341ecc86701c21926
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93641
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibaf5e1a4db1088322cf8c5e127d328b140406197
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92196
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I768ccc1d98a0785806986a6ffc70de057991e08a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90009
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I28b007cff3a99bc40901ecdeaecacf42b4521574
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89058
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Files which could become clang-format conformant with
under 5-percent lines of change relative to the total
count of lines in the file are found by using bin/find-clang-format.py,
and fixed with /opt/lo/bin/clang-format -i <path-of-the-file>
There will be follow-up patches to fix all 'under-5-percent' files.
Change-Id: I06087a1385ca9da6a28d36ea4c0d2e40bdbf8f03
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88774
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
To avoid duplication.
Change-Id: I0ee7c26d5d55bd868ead04c77e7f4ef2582f90e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88138
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
In some places the integers end with L which denotes that the number is in long long format.
This representation was not required .
Change-Id: Ia8ae328ee943780ccbfb7ce15013f3ac0365a3db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86842
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
found by a more aggressive variant of loplugin:unusedvariables.
This is my first pass, committing the simplest and most obviously
unnecessary vars
Change-Id: I9676a6e39a101937097788548764506c93811c57
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87414
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia9c736042a07a17377db6d88c5bcd2b468e98777
Reviewed-on: https://gerrit.libreoffice.org/85471
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibe6192b536d1a60443ab7b20ed68c4ea412f0a76
Reviewed-on: https://gerrit.libreoffice.org/85151
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...plus loplugin:consttobool and loplugin:fakebool fallout
Change-Id: Ie3d8121815c080b13bea6d9deca1eb138ca56138
Reviewed-on: https://gerrit.libreoffice.org/84515
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...plus follow-up loplugin:implicitboolconversion and loplugin:redundantcast
Change-Id: I9fc9c5cb46fbb50da87ff80af64cb0dfda3e5f90
Reviewed-on: https://gerrit.libreoffice.org/83207
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...so forbid anything else, to avoid issues like the one described in
766cdd869d7d983e9e171a3eae0629cb9a0206ff "This code wants to add the numeric
SvxRotateMode value". Some remaining places that apparently do want to convert
some numeric value to sal_Unicode have been augmented with an explicit cast.
Change-Id: I6200a84e250e697bc88694bd71142ca1d9a13651
Reviewed-on: https://gerrit.libreoffice.org/81132
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Replace them with default initialization or calloc
Change-Id: I747f53c2ced2d0473fd5a5ede4f8520a0633dcc1
Reviewed-on: https://gerrit.libreoffice.org/80805
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It started out as a wrapper around character literals, but has by now become a
wrapper around arbitrary single characters. Besides updating the documentation,
this change is a mechanical
for i in $(git grep -Fl OUStringLiteral1); do sed -i -e s/OUStringLiteral1/OUStringChar/g "$i"; done
Change-Id: I1b9eaa4b3fbc9025ce4a4bffea3db1c16188b76f
Reviewed-on: https://gerrit.libreoffice.org/80892
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Except for test/ which seems to be unused anyway
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I9d0b75dbb260f05390b513be75a4bdd24647c91b
Reviewed-on: https://gerrit.libreoffice.org/80077
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I2da126a38db61d2a0f36f8f2d38b0dddeb26c9d4
Reviewed-on: https://gerrit.libreoffice.org/79929
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Id1a82cea4444255fdb693e126b7571a406094624
Reviewed-on: https://gerrit.libreoffice.org/79916
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic28b4bdd401342d92b33913f7dab0ca875f8aab3
Reviewed-on: https://gerrit.libreoffice.org/79573
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Iec6a9ff8b62ac1986cca205435273b64b71f33cd
Reviewed-on: https://gerrit.libreoffice.org/79539
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4671d0f13e67b1272fd7c24bb6a2a7679c75f20b
Reviewed-on: https://gerrit.libreoffice.org/78797
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
We are moving the isMobile() check to a higher layer,
to avoid changing a published API method
This is the follow-up of the commit feae0c186e700f6a48c3fad124fb4795ad1a8f83
Change-Id: Ia84baa36d66d5832e00e6466f5206631df0de443
Reviewed-on: https://gerrit.libreoffice.org/78277
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
embeddedobj/source/commonembedding/embedobj.cxx will have
a follow-up patch, which also removes the -1 case.
It is left out because it has many call-sites,
and inheritance/override relations.
Change-Id: Iaf00530916f3772f7aec151cbd358f255b7aab24
Reviewed-on: https://gerrit.libreoffice.org/78272
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Disabled editing of all embedded objects.
[ Miklos: motivation is that the UI is complex and the small mobile
screen is not suitable to expose this functionality as-is. Disable till
a more compact UI can be exposed. ]
Change-Id: Id1c598c84adc12b8b52d006992d85dcae5601ad9
Reviewed-on: https://gerrit.libreoffice.org/78270
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
in cppuhelper, desktop, drawinglayer, embeddedobj, extensions
Change-Id: I4c970f08c0723299f79c9e18bc71b7372a7092e4
Reviewed-on: https://gerrit.libreoffice.org/77636
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
in embeddedobj and filter
Change-Id: I2da3fa1df8782e449852358d1c86f5e4bc79ea1a
Reviewed-on: https://gerrit.libreoffice.org/77627
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
regression from
commit 5043421fdc527d18d18121ec5fe2d4e009c8191a
Date: Fri Jul 19 14:05:10 2019 +0200
loplugin:referencecasting in embeddedobj
OSpecialEmbeddedObject is playing games and effectively "unimplementing"
an interface it's superclass implements by doing custom stuff in
OSpecialEmbeddedObject::queryInterface.
So lets rather implement this in a more direct and obvious way.
Change-Id: I341b8e0b6acafac80cbd55f745811b73d2593585
Reviewed-on: https://gerrit.libreoffice.org/77580
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This is a bit custom, since it's not a Microsoft filter. At the moment
this affects only Insert -> Object -> OLE Object -> from file.
Change-Id: If79602742a533db1b04e11a90890f8768186046d
Reviewed-on: https://gerrit.libreoffice.org/77520
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
At the moment this affects only Insert -> Object -> OLE Object -> from
file.
Change-Id: I8d1c6456481610491916e3be3766b0bb04dfa296
Reviewed-on: https://gerrit.libreoffice.org/77489
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Fails with commit 88afec70112c95a016e92e26c1d06d7dd002e4e8 (embeddedobj:
respect config for Insert -> Object -> OLE Object -> from file,
2019-08-14) reverted.
Change-Id: I64f81642260f6eab5a86219d94553f09b67b3555
Reviewed-on: https://gerrit.libreoffice.org/77461
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Tools -> Options -> Load/Save -> Microsoft Office has config options to
decide that Word/Excel/PowerPoint formats are loaded into our doc models
(default) or handled via external OLE applications instead.
This is used in the MSO import/export filters, but in case the UI is
used to insert a new file as an embedded object, then we ignored this
setting, and the embedding type depended on if we found an import filter
for the data or not (if yes, load it; handle externally otherwise).
Fix this inconsistency by checking for the usual MSO import filter names
and respect the existing configuration in those cases, so the user can
choose to not handle these formats internally if wanted.
Change-Id: I6bce8b5467768ef3f21d97b4e0fe3f4d18d9466b
Reviewed-on: https://gerrit.libreoffice.org/77449
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Id3d255d48a8a72f760dae3c372e0e1a97d0aa508
Reviewed-on: https://gerrit.libreoffice.org/76681
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I11a80e540b2a7da8d8037ba45e176d5c4d85374c
Reviewed-on: https://gerrit.libreoffice.org/75951
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|