Age | Commit message (Collapse) | Author |
|
we can just take a "const &".
(found by running clang-tidy with the
performance-unnecessary-copy-initialization warning)
Change-Id: I20fd208c65303da78170b1ac06c638fdf3aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176267
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: Ia765a03e033acb82e367873380d289587ea87d6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167449
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: Iddf9d40ca63f2f3ce7d48aaf881a3abb10f88bbf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166975
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... for ODF wholesome encryption.
4.3 <manifest:file-entry>
For directories, the manifest file should contain a <manifest:file-entry> element only if a directory contains a document or a sub document.
Because the "encrypted-package" is not a document but a package, we
should probably omit the file-entry for the root document.
ZipPackage::writeTempFile() always generates the root document becuase
it's needed for GPG properties, and ManifestExport filters it out.
A bit tricky to implement, because there isn't a clean distinction
between the package and the root document/storage in the package module,
in particular there's no other place than the root storage to store the
MediaType property.
Change-Id: Id7e72a64e2faa074dce80cd5fefb2fa189e2e3ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160717
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I1424ad5deb65f6c72f414a51a40fbd1138c284d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151432
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
...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: I59b1b3f817a9028f132456ea5094f38f88674d00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133768
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I076f16d0536b534abf0ced4d76051eadb4c0e033
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114949
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3e8bfdf717dd8896ab16e396f671651ca4f7f01c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103932
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I88fdaa74c4944f9ffc81db6df08a29283362375a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103647
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8fdf9833dede6f4c9ba4bbb76b9ab9b6b419f155
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100722
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
we're not in DOS anymore, Dorothy
Change-Id: I79926e0d694163940ba7ebf20419724dd0a486f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100721
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I54f0e2864cb4ef00fea8f9e4369a1f76721e7503
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97369
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia7b4f69361b6cc29f6e5c0093b13cf0b48e25ba3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95576
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: I8d8a3e13932b004678b305f9a6883062854f9201
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90140
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.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>
|
|
Change-Id: I81b54f6db69491492b2bc16f48b2296ad96e137d
Reviewed-on: https://gerrit.libreoffice.org/77529
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2f6bc2467fa7689d186bc2bc45d2071ea0a38e63
Reviewed-on: https://gerrit.libreoffice.org/75998
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Use range-based loops, STL and comphelper functions
Change-Id: If6d190cf72b8653c1c3fbe9a6a6e47f10f1a6765
Reviewed-on: https://gerrit.libreoffice.org/75255
Tested-by: Jenkins
Reviewed-by: Arkadiy Illarionov <qarkai@gmail.com>
|
|
Change-Id: I465a2479f347303e6d4faa39cb0a0f05aec3bf07
Reviewed-on: https://gerrit.libreoffice.org/70719
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Id20e0bc42e39f868a7c5d49d756f2ad5e14a86c0
Reviewed-on: https://gerrit.libreoffice.org/66637
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Id2df31daa596a18c79af5fc6ea162deb6e24d5af
Reviewed-on: https://gerrit.libreoffice.org/62958
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
XGraphicObjectResolver was used to get the GraphicObject URL from
an storage (package) URL. This isn't possible anymore in LO 6.1
since creating GraphicObject from uniqueID was removed for its
lifecycle issues. XGraphicObjectResolver is now deprecated and
when the "resolveGraphicObjectURL" is called, it throws a
RuntimeExeption.
In places where XGraphicObjectResolver was used, we now use the
XGraphicStorageHandler as the alternative. Both share a common
implementation so previously we could cast one to the other at
any time. Now only XGraphicStorageHandler is used.
GraphicObjectResolver was removed and replaced by the alternative
GraphicStorageHandler for instance creation - where needed.
Change-Id: I5d3f759c6f95b7dbe2d93688d99c8aa4899ffa84
Reviewed-on: https://gerrit.libreoffice.org/53279
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I0577de02000c6aeb45bf1e950b9212beadacb05b
Reviewed-on: https://gerrit.libreoffice.org/50334
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
As we want to get rid of GraphicObject URLs for the more robust
image life-cycle handling, it was necessary to change the way
bitmap table stores and handles images, so that they always
store a Graphic object (wrapped in UNO object that provides the
XGraphic and XBitmap interface).
In addition this changes loading and saving from ODF (xmloff) and
OOXML (oox) filters so they don't depend on GraphicObject URL
anymore, but load or save directly to / from XGraphic or XBitmap.
Change-Id: I2b88e10056e7d6c920249d59188f86b1a5a32d21
Reviewed-on: https://gerrit.libreoffice.org/49074
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I4057fe05983fb2b63b592ffd325894c12b9cb5b2
|
|
Change-Id: I0052b29660fb6157f7e98c4e124f030ba439d304
Reviewed-on: https://gerrit.libreoffice.org/43417
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic6da38a47f2c2f2e350a15bad2b2731ed12409a9
Reviewed-on: https://gerrit.libreoffice.org/41853
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Icc388182b9b7b6a6617793be09217f06bed7332d
Reviewed-on: https://gerrit.libreoffice.org/40527
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib0304de5d873ac833dcc121235b8de494a1bb3bf
Reviewed-on: https://gerrit.libreoffice.org/37999
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.
Most changes have been done automatically by the rewriting loplugin:dynexcspec
(after enabling the rewriting mode, to be committed shortly). The way it only
removes exception specs from declarations if it also sees a definition, it
identified some dead declarations-w/o-definitions (that have been removed
manually) and some cases where a definition appeared in multiple include files
(which have also been cleaned up manually). There's also been cases of macro
paramters (that were used to abstract over exception specs) that have become
unused now (and been removed).
Furthermore, some code needed to be cleaned up manually
(avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
configurations available that would actually build that code. Missing @throws
documentation has not been applied in such manual clean-up.
Change-Id: I3408691256c9b0c12bc5332de976743626e13960
Reviewed-on: https://gerrit.libreoffice.org/33574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Icc4d9919cedadc00f1420939564dd095fab74cca
|
|
Change-Id: I96634c18ba6600f8f7d5d04a162dcd7e1e312923
Reviewed-on: https://gerrit.libreoffice.org/30474
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If03d9797fddd88662cf7d0ba2a70c2841983b37b
|
|
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
|
|
Change-Id: Ib0360b395fafe3c8123a0cc0fd0cbfd581fa5414
|