Age | Commit message (Collapse) | Author |
|
Change-Id: I29d50f536779c28570c8920ad34d0770934af0c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111261
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: Icf55ddda055d11b649e7607c2cdd8b6d6ddfefbc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110483
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...by re-enabling the code temporarily #if'ed-out in
a528392e71bc70136021be4e3d83732fccbb885e "Fixed/improved
loplugin:cppunitassertequals" (and which then triggers lots of other
lopglugin:cppunitassertequal CPPUNIT_ASSERT -> CPPUNIT_ASSERT_EQUAL warnings).
For two css::uno::Reference equality comparisons in cppu/qa/test_any.cxx, it
was more straightforward to rewrite them with an explicit call to operator ==
(which silences loplugin:cppunitassertequal) than to adapt them to
CPPUNIT_ASSERT_EQUAL's requirement for arguments of identical types.
In sc/qa/unit/ucalc_pivottable.cxx, ScDPItemData needs toString, which has been
implemented trivially for now, but might want to combine that with the
DEBUG_PIVOT_TABLE-only ScDPItemData::Dump.
Change-Id: Iae6d09cf69bd4e52fe4411bba9e50c48e696291c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110546
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
reasonably sane code like
s.ReadUInt32(a).ReadUInt32(b).ReadUInt32(c).ReadUInt32(d);
if (s.good())
// use a, b, c d;
stopped working.
FWIW on a short read we retain whatever was in the variable before the
read, rather than overwrite it with new random data, so
sal_uInt32 a(0xdead); s.ReadUInt32(a); assert(s.good() || a == 0xdead);
the msoffice ppt/escher/xls/doc filters especially speculatively parse
and rely on a variables preinit value in the case of a short read.
commit b345a2bab0d6f981049951a86b172ce49ce7d4c2
cid#1470786 Uncaught exception
commit 71aec4726a94dcde1169fd293dbecfeb0e840e6d
ofz#29528 uncaught exception
commit bed03603f6cae264abb9e5b58aa2ab00448d92ff
ofz#29414 uncaught exception
commit 684885a99a1eb7ad943e9736166d4bb1468663be
ofz#29443 uncaught exception
commit 93574ac7768d247ed754ecda322e54e4bd447e43
ofz#29251 Abrt
commit 413db68d95bd39d34e6a6b81a7c5c9478ced0514
ofz#29152 short read
commit f400e883044143f999c460375a293647b4a57244
ofz#29151 short read
commit 96ea80a725dfe4ef38993f78917c243f13e3beb5
ofz#29129 Abrt on uncaught exception
commit 646a635efe6eecbc3d1dd3a7cbb02a278c6f3be5
ofz#28931 Indirect-leak
commit b0e573f18629d28fe3179c12d0d434653f92fc93
ofz#29030 Abrt in xlsfuzzer
commit 95407c39168d186ee44e67b1a6a4bcf592c58b84
ofz#28902 uncaught exception
commit 45175d655ad3773df1c006182108cf25e87b1091
oss-fuzz: tgafuzzer doesn't pass sanity check
commit b82fc702bae9d6190bda1b4818a47cfa197df6d8
oss-fuzz: psdfuzzer doesn't pass sanity check
commit e7c76d604a4694e6568bf10c2a06a786f1096319
oss-fuzz: epsfuzzer doesn't pass sanity check
commit 901e5e7c9170184e286ea3e46fce406136aa9572
oss-fuzz: xlsfuzzer doesn't pass sanity check
commit 127bfab61c297df06fd8e71e709bc4362cb89d21
oss-fuzz: pngfuzzer doesn't pass sanity check
commit 77387ae00ae27e3f8bcdf7bccf97fb2db8f196b7
oss-fuzz: mtpfuzzer doesn't pass sanity check
commit 974ffa79b0fef4ca76558bb8b16bce84af3aaf6c
oss-fuzz: xlsxfuzzer doesn't pass sanity check
commit 6d6d104cbb382d0045e1f04b12d268992fa5c624
oss-fuzz: bmpfuzzer doesn't pass sanity check
commit a7d1d107ec58d3b00b4019c89edddcff71ca6ff3
oss-fuzz: qpwfuzzer doesn't pass sanity check
commit 898993aa62276f59480df8af1da4bad530829b56
oss-fuzz: pcxfuzzer doesn't pass sanity check
throw/catch parts of
commit 8c9a4ff511a3b1d84a7a6d08a1b153c07f164abb
throw exception in SvStream when reading past end of file
Change-Id: Ic49c249768b17b64d8e868655dbc05b31906c2e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109621
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Revert the addition of the latter.
Change-Id: I93636a901cde401b0b7d923e052887f57dd58212
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109315
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
For instance, if SotExchange::GetFormat() is passed a flavor with MIME
type
"application/x-openoffice-objectdescriptor-xml;windows_formatname=\"Star
Object Descriptor (XML)\";typename=\"LibreOffice 7.2 Spreadsheet\"" we
do want to recognize it as SotClipboardFormatId::OBJECTDESCRIPTOR,
even if the MIME type in the entry for it in the array in
ImplFormatArray_Impl only has the windows_formatname parameter.
This is part of fixing
https://github.com/CollaboraOnline/online/issues/849, but it will help
for corresponding problems with LibreOffice on macOS, too.
Note that on Linux, SotExchange::GetFormat() gets called with a flavor
with a MIME type that does *not* have all the extra parameters
(classname, typename, displayname, viewaspect, width, height, posx,
posy) (See the GitHub issue mentioned above.) This change does not
remove any checks for classname, typename, etc. There are/were no such
checks in SotExchange::GetFormat().
But, in the (much different) code path for macOS (and iOS), with my
work in process in vcl, SotExchange::GetFormat() gets called with a
flavor with a MIME type that *does* contain those extra parameters. I
don't see the point in introducing checks of the "sanity" of those
into SotExchange::GetFormat().
Change-Id: Ie65ed1ab922cdaa6557eb65d980b9e886d3c6971
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109254
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
there is no need for all this indirection.
Change-Id: Ie44723b54313b1103fe33a00ed014e2b28a59638
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109225
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2d99a13822b07d98e03d7e7de91ca44ab4f8599d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108266
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Step #5: #6 0xc1f47cf in __cxa_throw (/tmp/not-out/xlsxfuzzer+0xc1f47cf)
Step #5: #7 0x4602309 in SvStream::ReadUInt32(unsigned int&) (/tmp/not-out/xlsxfuzzer+0x4602309)
Step #5: #8 0x33d288f in ReadClsId(SvStream&, SvGUID&) (/tmp/not-out/xlsxfuzzer+0x33d288f)
Step #5: #9 0x33d328d in StgHeader::Load(SvStream&) (/tmp/not-out/xlsxfuzzer+0x33d328d)
Step #5: #10 0x33d3204 in StgHeader::Load(StgIo&) (/tmp/not-out/xlsxfuzzer+0x33d3204)
Step #5: #11 0x33d5d8d in StgIo::Load() (/tmp/not-out/xlsxfuzzer+0x33d5d8d)
Step #5: #12 0x33b2e01 in Storage::Init(bool) (/tmp/not-out/xlsxfuzzer+0x33b2e01)
Step #5: #13 0x33b33c8 in Storage::Storage(SvStream&, bool) (/tmp/not-out/xlsxfuzzer+0x33b33c8)
Step #5: #14 0x9b3d5b1 in OLESimpleStorage::OLESimpleStorage(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&,
Change-Id: Ibc03107373f5558f47894fffc34169218e4aff12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108151
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
since it has two completely different paths of control
Change-Id: I89b739d318d52245208a4bda1230f69d19f3ae0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108104
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to avoid chasing weird problems where we read past the end
of file, which leads to random data in the variable we read into.
I expect a couple of possible regressions from this change
(1) memory leaks caused by non-exception-safe memory handling.
Of which there should not be much because we're pretty good
about using smart pointer classes these days.
(2) Broken files which used to load, will no longer do so.
These will have to be debugged by putting a breakpoint
on the SvStreamEOFException constructor, and examining
the backtrace to see where we should be catching and ignoring
the exception to make the code continue to handle such broken
files.
Change-Id: I351be031bb083a3484a9a1b650a58892700e6fb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105936
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3e22c2000da03f6f3345353846213203993aa865
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107192
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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: I2c375689049fcb65ca56cfcf5c5f61f8108c38bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105710
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: Iefe922c2e0d605114d54673d63eccc5e4abd545d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102143
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I18f5b7c5da513d386f8ac848835b0410ebc7d95b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104629
Reviewed-by: Dante DM <dante19031999@gmail.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaab26ade1109daf732e58a2f3741cc43243e374c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102023
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I786548bef39fa711aabcff32b592b3fdc4a6f9fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101486
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6a300169d33bdc36e4c7e720a7afc336a86eea68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100962
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia69fb105c6cc661ac94a360d47655b3faa9d6bb8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100618
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I75602277a5a26b012a12f2c4f4b7ff5bb663b0b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98474
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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: I3e751a59eb6d5f95a331627d0fcd776b193b05b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97667
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and update pches accordingly
Change-Id: I411712532fd85961bffe6678416fcdc1d9c7f53d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92617
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I917752edb50020f9acb203038ce65f1ea25afa64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92312
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 1de7e818a417a412678013c100b4bf73fd8858ac.
Change-Id: Ie1100fd1af636a0538f589845b9391ba40dbf12a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90417
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
"Find explicit casts from signed to unsigned integer in comparison against
unsigned integer, where the cast is presumably used to avoid warnings about
signed vs. unsigned comparisons, and could thus be replaced with
o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx)
o3tl::make_unsigned requires its argument to be non-negative, and there is a
chance that some original code like
static_cast<sal_uInt32>(n) >= c
used the explicit cast to actually force a (potentially negative) value of
sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the
cast to avoid a false "signed vs. unsigned comparison" warning in a case where
n is known to be non-negative. It appears that restricting this plugin to non-
equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=)
is a useful heuristic to avoid such false positives. The only remainging false
positive I found was 0288c8ffecff4956a52b9147d441979941e8b87f "Rephrase cast
from sal_Int32 to sal_uInt32".
But which of course does not mean that there were no further false positivies
that I missed. So this commit may accidentally introduce some false hits of the
assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan
--enable-dbgutil) `make check && make screenshot`.
It is by design that o3tl::make_unsigned only accepts signed integer parameter
types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses
which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in
include/oox/helper/helper.hxx is used with both signed and unsigned types, so
needs a little oox::detail::make_unsigned helper function for now. (The
ultimate fix being to get rid of the macro in the first place.)
Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I6b21f25738458a1d85905a3a02eb17c51a626b0d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85932
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ia133c1a7549d81f2e88e34ab7e6c9ea578c745ae
Reviewed-on: https://gerrit.libreoffice.org/85702
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
order had been changed in svx/source/sidebar/paragraph/ParaLineSpacingControl.hxx
so initialization list was fine
Indeed mpActLineDistFld depends on mpLineDistAtMetricBox
Change-Id: I974e68892fe7ab900774bbe912c51ec56ba4ee43
Reviewed-on: https://gerrit.libreoffice.org/83577
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...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>
|
|
tweak the plugin to be more permissive, then validate by hand
afterwards
Change-Id: I40c5c911fe6ff7e45baaca372abf7dac211d9654
Reviewed-on: https://gerrit.libreoffice.org/81942
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
if one side of the expression is a compile-time-constant, we don't need
to worry about side-effects on the other side
Change-Id: Iee71ea51b327ef244bf39f128f921ac325d74e2b
Reviewed-on: https://gerrit.libreoffice.org/81589
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
E.g. #ifdef LIBO_INTERNAL_ONLY is always true for code that builds
with our PCHs.
Change-Id: I3cf311ea3621b909105754cfea2cb0116b8b67f5
Reviewed-on: https://gerrit.libreoffice.org/80961
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The code to create these "linked files" added by:
commit 6f2f7e3091504e8e58d9be603ed3739f6f2cd68e
Author: Mathias Bauer <mba@openoffice.org>
Date: Fri Jul 6 14:03:59 2001 +0000
#89377#: new StorageMode for creating unpacked files
use of creating them then introduced in:
commit 53fe2691a3fb65110e7f5aee2919f7d8d559ff02
Author: Mathias Bauer <mba@openoffice.org>
Date: Fri Jul 6 13:55:57 2001 +0000
#88062#: some optimizations
that use then commented out in:
commit 762dd2b15bfd201b2271b460efa72a5b68d6fb2a
Author: Kurt Zenker <kz@openoffice.org>
Date: Mon Oct 4 19:53:11 2004 +0000
and the unused code to create them removed in:
commit 8a91528a3e03fe6e2923c33327b687ecf57adb0b
Author: Stephan Bergmann <sbergman@redhat.com>
Date: Thu May 7 10:37:27 2015 +0200
StorageMode::CreateUnpacked is never used
It seems to me that there is no need to keep support for reading them as they
seem to have been temporary files rather than something still existant
Change-Id: I783cae63dc078a7e843729d3ca13f45c18168f4c
Reviewed-on: https://gerrit.libreoffice.org/80943
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@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>
|
|
and improve the WriteOString method, we can avoid the strlen here, we
already have the length
One change in behaviour to be noted - if the string contains
trailing zero bytes, which ARE INCLUDED IN THE STRING LENGTH,
i.e. I'm not talking about the normal terminating zero, then this
patch changes behaviour because we will now write those zeros to
the stream.
Change-Id: I4668b9b9eb877f820b1dc70d6cd10ba2623bc0a2
Reviewed-on: https://gerrit.libreoffice.org/80597
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaf1bbe37449d4e0cfa817909d56d4bffe1e5a184
Reviewed-on: https://gerrit.libreoffice.org/79893
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Before this patch, copy in Calc, Paste in Writer produced an embedded
sheet. I suspect is it not what the people usually want; working with
the embedded sheets in Writer is non-intuitive, I suspect people will be
happier with a normal table which they can style etc. appropriately.
OTOH - this is a general change, so it might have some unwanted
side-effects; let's see what if we get bugreports :-)
tdf#127673 was related; but in my view, we shouldn't create the embedded
objects in the first place.
Change-Id: I73710168d8924fdd6275d65e20cf55f38971a3f9
Reviewed-on: https://gerrit.libreoffice.org/79606
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
|
|
Change-Id: I7b3a22584bb2e4d501f509ffcd80929feed23a4c
Reviewed-on: https://gerrit.libreoffice.org/79360
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
To complete this:
https://gerrit.libreoffice.org/#/c/78312/
This is a massive replace for
".." instead of "..." between words.
It passed "make check" on Linux.
Change-Id: I144d8061fca9f545c762941551e59dffdd3650e8
Reviewed-on: https://gerrit.libreoffice.org/78357
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: Ieb0116321bbddd804db6d1789ea3521c5b220840
Reviewed-on: https://gerrit.libreoffice.org/77807
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I40e2a1be0ce7df627d3820192d24821ddd7c3e2f
Reviewed-on: https://gerrit.libreoffice.org/77527
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia44a9dd214b5b09ed6f9c39b8057c41ae03897f1
Reviewed-on: https://gerrit.libreoffice.org/77285
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: If50079060effe857d5c4659a82c827ce16548c46
Reviewed-on: https://gerrit.libreoffice.org/76646
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Use range-based loops, STL and comphelper functions
Change-Id: I612d36abcc09a91c60f7212de6747a1a1bdcfc69
Reviewed-on: https://gerrit.libreoffice.org/76056
Tested-by: Jenkins
Reviewed-by: Arkadiy Illarionov <qarkai@gmail.com>
|
|
Change-Id: Id4e3d9d1bbfd47181299568afec45e996eb1eed5
Reviewed-on: https://gerrit.libreoffice.org/76071
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
"an OLE", to complete:
https://gerrit.libreoffice.org/#/c/75983/
Change-Id: Idd5b9286348b4fa1e3382983c72b010654a1f4c2
Reviewed-on: https://gerrit.libreoffice.org/76038
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|