Age | Commit message (Collapse) | Author |
|
...as discussed as an open TODO in the commit message of
fe6cce01c88d045a1fcf09acf049c34c22299b02 "Fix loplugin:simplifypointertobool for
libstdc++ std::shared_ptr". The necessary changes across the code base have
been done fully automatically with the rewriting plugin on Linux. (All those
changes apparently involve uses of macro arguments wrapped in parentheses in the
macro body, but always in conditionally-converted-to-bool contexts. In other
contexts, such automatic rewriting would add the "bool" to the macro body, which
would be wrong in general, but we apparently get away with that sloppy coding
for now.)
The parenExprs_ stack that fe6cce01c88d045a1fcf09acf049c34c22299b02 had
introduced to treat such (then-undetected, it had turned out) parenthesized
cases now turns out to not be needed after all.
Change-Id: I2021f61c2e2805be7e18b38edf8744d186cac3cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95010
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib7c3b381ce4456e3d48538ee6f762ceaf2784fe1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94973
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...where the get member function is defined on a std::__shared_ptr base class,
so loplugin:simplifypointertobool used to miss those until now. (While e.g.
using libc++ on macOS found those cases.)
366d08f2f6d4de922f6099c62bb81b49d89e0a68 "new loplugin:simplifypointertobool"
was mistaken in breaking isSmartPointerType(const clang::Type* t) out of
isSmartPointerType(const Expr* e); c874294ad9fb178df47c66875bfbdec466e39763 "Fix
detection of std::unique_ptr/shared_ptr in loplugin:redundantpointerops" had
introduced that indivisible two-step algorithm on purpose.
The amount of additional hits (on Linux) apparently asked for turning
loplugin:simplifypointertobool into a rewriting plugin. Which in turn showed
that the naive adivce to just "drop the get()" is not sufficient in places that
are not contextually converted to bool, as those places need to be wrapped in a
bool(...) functional cast now. If the expression was already wrapped in
parentheses, those could be reused as part of the functional cast, but
implementing that showed that such cases are not yet found at all by the
existing loplugin:simplifypointertobool. Lets leave that TODO for another
commit.
Besides the changes to compilerplugins/ itself, this change has been generated
fully automatically with the rewriting plugin on Linux.
Change-Id: I83107d6f634fc9ac232986f49044d7017df83e2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94888
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I3234509406989661a2e5d3866bee057c17984437
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94738
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I0dc88b1e7c6c1ac336bbfb772c8ebced5e1b432c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94737
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
this wasn't true at the time the canvas text rendering was written
but it is true now so its better now to just simplify this to using
the vcl text rendering to render the text through cairo
Change-Id: I1e63496e03e2cedc3e36e2bf10b0eab90a549629
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94736
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
As the comment already says, it's not necessary. And it is partially
responsible for tdf#133016 by splitting an area into smaller parts,
which then do not line up completely when AA-ed.
Change-Id: If35e2118a0cd9c9b315b9666165c51659a9434e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94578
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Idad3d8fbe785c7b1b8b287a3227372adb2757de8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94260
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7bd0c2a55b936896fcfe7e1a374871008a18618f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93706
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
introduced with
commit 17cd7dd708631f7af9e66860b403627416e4545e
tdf#43671 set emphasis mark of vcl::Font (windows).
but has probably never been a problem because I guess this
propertyset almost always has 0 or 1 element.
Change-Id: I17c64e376ee81cc9f92173015d2632331c63ae0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93643
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The main reason for the "home-grown" UpCast introduced with
904b3d1fceee5827076758ed2a81f80cb73493ca "Up-cast conversion constructor for
css::uno::Reference" in 2013 was probably that we could not yet rely on C++11
std::is_base_of back then. A (welcome) side effect was that the derived class
could be incomplete.
However, specializations of UpCast relying on whether or not T2 is incomplete
are obviously an ODR violation if the type is incomplete in some TUs and
complete (and derived from T1) in others. And even if UpCast had internal
linkage, it would still be brittle that its behavior depends on the completeness
of T2 at the point of the template's instantiation, and not necessarily at the
point of use.
That means we should better base that ctor on std::is_base_of (which we can do
now since 39a1edd6fec902ef378acce8af42c4d7fba280d0 "Make css::uno::Reference
upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on
Clang and GCC if the completeness requirements are not met. This change fixes
all the cases where types need to be complete now, plus any resulting
loplugin:referencecasting warnings ("the source reference is already a subtype
of the destination reference").
Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Turns out we can save about 500Mb of preprocessor input if we use
rtl_math_approxEqual from rtl/math.h instead of its C++ wrapper
rtl::math::approxEqual from rtl/math.hxx
and manage the fallout accordingly.
Before:
bin/includebloat.awk | head
sum total bytes included (excluding system headers): 19017296671
After:
$ bin/includebloat.awk | head
sum total bytes included (excluding system headers): 18535432672
Change-Id: I1691171f3a309405a7099882ad9989d147f59118
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92508
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: If14af63ab4f8fc7b9807319a2100f371ee103465
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92481
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id14fed7e5c0f588ad3c927f12251432d12c1a7c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92190
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3077e6e3a043401e66cd527c5f69b8571e8b25d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90915
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
- make all calls look like `std::isfinite`.
- change the comments referring `rtl::math::isFinite`.
Change-Id: I0cde9ceb9f20150467b454cddde5e62003cfde1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90234
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...now that macOS builds are guaranteed to have std::optional since
358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to
Xcode 11.3 and macOS 10.14.4".
The change is done mostly mechanically with
> for i in $(git grep -Fl optional); do
> sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \
> -e 's/\<o3tl::optional\>/std::optional/g' \
> -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i"
> done
> for i in $(git grep -Flw o3tl::nullopt); do
> sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i"
> done
(though that causes some of the resulting
#include <optional>
to appear at different places relative to other includes than if they had been
added manually), plus a few manual modifications:
* adapt bin/find-unneeded-includes
* adapt desktop/IwyuFilter_desktop.yaml
* remove include/o3tl/optional.hxx
* quote resulting "<"/">" as "<"/">" in officecfg/registry/cppheader.xsl
* and then solenv/clang-format/reformat-formatted-files
Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The code is from 2008, so I'm rather sure at least Skia is modern
enough to handle alpha at least as well as a mask (if not better).
Change-Id: Ic53d5740978bce106506a182100eba927a419257
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89010
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
From 52c998be025563802a5056a15352e4608311be1d.
Change-Id: I672fa3884480e251bcbd4e32587866893f5df2c3
|
|
The #ifdef on debug level got reduced to normal debug builds
as an Easy Hack in f0de4374fffe7f, but that means that the green
debug lines are now drawn in all debug builds. The frame info
debug text is at least obviously debug output, but "random" green
lines look like drawing problems, so disable them, unless
explicitly asked for.
Change-Id: I56ebc799ca72565cabee35552c4bd2641e2393c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88713
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Iaa00cff88ad756b7e084cc68fe744d387328180b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88360
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0c786bf401e514f9d86e33d8ab6366fc5dd1f425
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87887
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
check indentation of braces in namespace decls,
and the comments that often appear with them.
This is my penance for messing up the indentation with
clang-tidy-modernize-namespaces.
As such I have limited it to new-style namespaces for now,
and the check is off by default.
Change-Id: I4db7f10a81c79bc0eece8f8e3ee564da8bc7f168
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87723
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1461da594db222abbaeccfb636194b9790f5dbe8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87271
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I74a575e6ca7829ee252c0e315fc337ea223c944f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86758
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
found using 'git grep', I tried using clang-tidy, but it only
successfully found a tiny fraction of these
Change-Id: I61c7d85105ff7a911722750e759d6641d578da33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86526
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib72a83e595b80d6084be65b10a9ff20458175939
Reviewed-on: https://gerrit.libreoffice.org/85488
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I05a1d6f745e0df1385932585947aba66981209f2
Reviewed-on: https://gerrit.libreoffice.org/85490
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Iaf46b42a17bc00da0f86daeafea7b5346c4a6360
Reviewed-on: https://gerrit.libreoffice.org/85372
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Related to tdf#93870.
Change-Id: Ie0cb64c05c0fde6a774ce8558d06943870e775fe
Reviewed-on: https://gerrit.libreoffice.org/84758
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
...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>
|
|
...with a boost::optional fallback for Xcode < 10 (as std::optional is only
available starting with Xcode 10 according to
<https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS
and macOS is still Xcode 9.3 according to README.md). And mechanically rewrite
all code to use o3tl::optional instead of boost::optional.
One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per
fed7c3deb3f4ec81f78967c2d7f3c4554398cb9d "Slience bogus
-Werror=maybe-uninitialized" should no longer be necessary (and whose check
happened to no longer trigger for GCC 10 trunk, even though that compiler would
still emit bogus -Wmaybe-uninitialized for uses of boost::optional under
--enable-optimized, which made me ponder whether this switch from
boost::optional to std::optional would be a useful thing to do; I keep that
configure.ac check for now, though, and will only remove it in a follow up
commit).
Another longer-term benefit is that the code is now already in good shape for an
eventual switch to std::optional (a switch we would have done anyway once we no
longer need to support Xcode < 10).
Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses
boost::property_tree::ptree::get_child_optional returning boost::optional, so
let it keep using boost::optional for now.
After a number of preceding commits have paved the way for this change, this
commit is completely mechanical, done with
> git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g'
(before committing include/o3tl/optional.hxx, and relying on some GNU features).
It excludes some files where mention of boost::optional et al should apparently
not be changed (and the sub-repo directory stubs). It turned out that all uses
of boost::none across the code base were in combination with boost::optional, so
had all to be rewritten as o3tl::nullopt.
Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b
Reviewed-on: https://gerrit.libreoffice.org/84128
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...like 47dd2c63f649828a833543e21d4eca5866ec9ebe "Rewrite uses of
boost::optional"
Change-Id: I95373e151201563dcc9eb796f15121bc81341bfd
Reviewed-on: https://gerrit.libreoffice.org/84138
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(found by upcoming loplugin:unusedmember)
Change-Id: I518c70d3f4011bd5f0f582ca239dc6f8e49d9656
Reviewed-on: https://gerrit.libreoffice.org/83813
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib0c7988306a55740281daa75f24e0d393be9bb02
Reviewed-on: https://gerrit.libreoffice.org/83823
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I81fea38cd737a8be74e6ece333ca37cc434a1c33
Reviewed-on: https://gerrit.libreoffice.org/83765
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>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ie1f6fe98f4e8bc792f5eae1ccdd697c997707004
Reviewed-on: https://gerrit.libreoffice.org/81930
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Except directx/
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I4504e087edfd837a3a91df49e296bbf40778b030
Reviewed-on: https://gerrit.libreoffice.org/81586
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
LO has a page manager to match system memory backbuffers with
graphics memory on DX accelerated Windows. Internally this uses
an other rectangle implementation, the SurfaceRect, which had
some great comments like:
// a size of [0,0] therefore denotes a one-by-one rectangle.
In commit 230dbe2e43f3ee2cd285f9cdfe0d57e1ca08b8fe ("#144866# Add
one pixel border around textures, a bunch of drivers clobber those
with dirt), the allocation was increased by a pixel border, but
this doesn't work correctly, because now an allocation of the
page size wouldn't fit anymore into a page, because the pages size
is decreased before comparison. In the end the mixup suffered from
hard to handle off-by-one problems.
This patch fixes the bug, but eventually SurfaceRect should be
replaced by an extended basegfx::B2IBox. But since B2IBox uses two
ranges, instead of a point and a size, it would need a lot of
conversations to I2Point and I2Size objects with the current
Page::insert algorithm.
Change-Id: Ia725b4f8ed4fb270f2eb3734e492062bc7f13793
Reviewed-on: https://gerrit.libreoffice.org/80628
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
It was passed in as aArg[1] ever since d551190e8311242eadda4a3e82efff160175cb04
"INTEGRATION: CWS canvas05", but I can't find any current use of that specific
argument in canvas/source/ (assuming that all the factories are implemented
there), nor can I find any trace in the git history of it ever havig been used.
That means that Window::GetSystemDataAny is unused now and can be removed.
Change-Id: I16efe548afb5cc3e0606cffea135f7e6674d5def
Reviewed-on: https://gerrit.libreoffice.org/80295
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...given that maArguments[4] is accessed two lines further down, in both cases.
Looks like typos in b6a7c4da52acf45a7b69d1e81cf9548f8552752e "INTEGRATION: CWS
canvas05".
Change-Id: Iee8a111126f2b81c9e586fe8e3c569fbd81dd8f4
Reviewed-on: https://gerrit.libreoffice.org/80289
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I250bc68da118a994a2e0ff8ab9eb11112827756d
Reviewed-on: https://gerrit.libreoffice.org/80158
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ibf5b8022df00bb6c49b53853811b6503146dddd7
Reviewed-on: https://gerrit.libreoffice.org/79971
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib8b2bc1c5f7b27a646036ce23cae2b6a06edd038
Reviewed-on: https://gerrit.libreoffice.org/79922
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: I08da288a88c2bce1d4250ec77f17bd483e6bc09c
Reviewed-on: https://gerrit.libreoffice.org/79911
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie3267e1f888df371d281e81ead437a150aa8dc1c
Reviewed-on: https://gerrit.libreoffice.org/79796
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
none of our supported hardware uses these any more
Change-Id: Ic95d6df619a05df0bec1f5870596cb2bb3bcc6cb
Reviewed-on: https://gerrit.libreoffice.org/79476
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|