Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for
operator call arguments. (The "rather than copy, pass subView()" diagnostic is
already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly
for operator call arguments.)
(And many call sites don't even require an explicit [u16]string_view, esp. with
the recent ad48b2b02f "Optimized OString operator
+= overloads". Just some test code in sal/qa/ that explicitly tests the
O[U]String functionality had to be excluded.)
Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
MacrosTest::loadFromDesktop itself asserts on its return value.
Thus, the additional checks in unit tests are redundant, and only create
noise unrelated to the tested functionality.
SwModelTestBase::load calls SwModelTestBase::loadURL which calls loadFromDesktop from within.
Change-Id: I30061bbc6e13e05f0cfbf17a7910926070b996f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111547
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Rather provide a stub implementation of PDFiumLibrary::get(), so other
code can call it unconditionally.
This is meant to allow removing the 10 stub functions in
VectorGraphicSearch later.
Also fix up CppunitTest_xmlsecurity_signing to pass in the
disable-pdfium case by avoiding the known-problematic checks.
Change-Id: I748fcc5c623c5ce937bd2980bfdfaadbdf6cedf7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111564
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for
details.
(Turned some affected variables in included files into inline variables, to
avoid GCC warnings about unused variables.)
Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
And add a testcase with an odd PDF which were not handled by the old
tokenizer but is handled by pdfium.
Signature verification is happening implicitly while a document is
opened, so it makes sense to use the more battle-tested pdfium to do
this verification, instead of own code. (The APIs are somewhat
low-level, so we can easily keep using our crypto stack for digest
verification and our own certificate validation.) Signature creation
still happens with the same own code, though.
Change-Id: Ia64e84ab497422245e4ffd8a80a6a728cea84ff7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105766
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
And use it in xmlsecurity, instead of the upstream scopers, to
standardize on a single set of pdfium wrappers.
Change-Id: Iec4baf34a607b23f1b9de8c4b969801c5973c1ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103636
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Most of the initial pdfio was moved to vcl as vcl::filter::PDFDocument.
A small part was left here, because it depended on NSS. Then later the
NSS bits were moved to svl::crypto::Signing. The rest is just a small
amount of code, keeping that separate from PDFSignatureHelper, which is
its only user makes little sense.
With this, vcl::filter::PDFDocument is an implementation detail of
PDFSignatureHelper during signature verification.
Change-Id: I6230f9e46deeff7159970f88dbb3bd2de0e9ce7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103350
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Towards making vcl::filter::PDFDocument an implementation detail of
PDFSignatureHelper during signature verification: so pdfverify, cppunit
tests and the UI shares more code.
Change-Id: Ifdf2905773ce26c2314683ff770419350ce74e0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103274
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
...from which an OUString can cheaply be instantiated. This is the OUString
equivalent of 4b9e440c51 "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>
I.e. it's OK to add incremental updates for annotation/commenting
purposes and that doesn't invalite existing signatures. Everything else
does.
Change-Id: I4607c242b3c6f6b01517b02407e9e7a095e2e069
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102057
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
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>
Otherwise, if a test like testPreserveMacroTemplateSignature10::TestBody from
xmlsecurity/qa/unit/signing/signing.cxx happens to be executed after
testPreserveMacroSignatureODB::TestBody from
xmlsecurity/qa/unit/signing/signing2.cxx during CppunitTest_xmlsecurity_signing,
it would SIGABRT with something like
> warn:sfx.view:1935717:1935717:sfx2/source/view/frmload.cxx:489: DBG_UNHANDLED_EXCEPTION in static void (anonymous namespace)::SfxFrameLoader_Impl::impl_handleCaughtError_nothrow(const com::sun::star::uno::Any &, const ::comphelper::NamedValueCollection &) exception: com.sun.star.lang.DisposedException message: Frame disposed /home/sbergman/lo/core/framework/source/services/frame.cxx:362
> warn:legacy.osl:1935717:1935717:vcl/source/window/window.cxx:273: Window ( 19SfxFrameWindow_Impl()) with live children destroyed: 23SfxFrameViewWindow_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl()
> Window ( 19SfxFrameWindow_Impl()) with live children destroyed: 23SfxFrameViewWindow_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl()
at
> #7 0x00007ff59b2599e9 in SalAbort(rtl::OUString const&, bool) (rErrorText="Window ( 19SfxFrameWindow_Impl()) with live children destroyed: 23SfxFrameViewWindow_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow("..., bDumpCore=true) at vcl/source/app/salplug.cxx:303
> #8 0x00007ff59b08c751 in Application::Abort(rtl::OUString const&) (rErrorText="Window ( 19SfxFrameWindow_Impl()) with live children destroyed: 23SfxFrameViewWindow_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow("...) at vcl/source/app/svapp.cxx:281
> #9 0x00007ff59a846f98 in vcl::Window::dispose() (this=0x4ea35d0) at vcl/source/window/window.cxx:274
> #10 0x00007ff5954ff853 in SfxFrameWindow_Impl::dispose() (this=0x4ea35d0) at sfx2/source/view/frame2.cxx:82
> #11 0x00007ff59aad5161 in VclReferenceBase::disposeOnce() (this=0x4ea3818) at vcl/source/outdev/vclreferencebase.cxx:38
> #12 0x00007ff591c3815b in VclPtr<OutputDevice>::disposeAndClear() (this=0x7ffd92f67810) at include/vcl/vclptr.hxx:206
> #13 0x00007ff591cbaeb8 in VCLXWindow::dispose() (this=0x52fb4c0) at toolkit/source/awt/vclxwindow.cxx:920
> #14 0x00007ff59300e147 in (anonymous namespace)::XFrameImpl::setComponent(com::sun::star::uno::Reference<com::sun::star::awt::XWindow> const&, com::sun::star::uno::Reference<com::sun::star::frame::XController> const&) (this=0x4f02260, xComponentWindow=empty uno::Reference, xController=empty uno::Reference) at framework/source/services/frame.cxx:1514
> #15 0x00007ff5930104ee in (anonymous namespace)::XFrameImpl::close(unsigned char) (this=0x4f02260, bDeliverOwnership=1 '\001') at framework/source/services/frame.cxx:1692
> #16 0x00007ff593016633 in (anonymous namespace)::XFrameImpl::implts_checkSuicide() (this=0x4f02260) at framework/source/services/frame.cxx:3189
> #17 0x00007ff59300ffb4 in (anonymous namespace)::XFrameImpl::removeActionLock() (this=0x4f02260) at framework/source/services/frame.cxx:2683
> #18 0x00007ff592fa892f in framework::ActionLockGuard::freeResource() (this=0x7ffd92f68bd0) at framework/source/inc/loadenv/actionlockguard.hxx:123
> #19 0x00007ff592f9e2de in framework::LoadEnv::impl_reactForLoadingState() (this=0x7ffd92f68ac8) at framework/source/loadenv/loadenv.cxx:1637
> #20 0x00007ff592f9d9fc in framework::LoadEnv::impl_setResult(bool) (this=0x7ffd92f68ac8, bResult=false) at framework/source/loadenv/loadenv.cxx:515
> #21 0x00007ff592f9d851 in framework::LoadEnv::impl_loadContent() (this=0x7ffd92f68ac8) at framework/source/loadenv/loadenv.cxx:1160
> #22 0x00007ff592f9a502 in framework::LoadEnv::start() (this=0x7ffd92f68ac8) at framework/source/loadenv/loadenv.cxx:395
> #23 0x00007ff592f98261 in framework::LoadEnv::startLoading(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&, rtl::OUString const&, int, LoadEnvFeatures) (this=0x7ffd92f68ac8, sURL="file:///xmlsecurity/qa/unit/signing/data/tdf42316.ott", lMediaDescriptor=uno::Sequence of length 2 = {...}, xBaseFrame=uno::Reference to (class framework::Desktop *) 0x18b3c48, sTarget="_default", nSearchFlags=0, eFeature=LoadEnvFeatures::NONE) at framework/source/loadenv/loadenv.cxx:300
> #24 0x00007ff592f96bdc in framework::LoadEnv::loadComponentFromURL(com::sun::star::uno::Reference<com::sun::star::frame::XComponentLoader> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (xLoader=uno::Reference to (class framework::Desktop *) 0x18b3c58, xContext=uno::Reference to (class cppu::(anonymous namespace)::ComponentContext *) 0xa6aeb0, sURL="file:///xmlsecurity/qa/unit/signing/data/tdf42316.ott", sTarget="_default", nSearchFlags=0, lArgs=uno::Sequence of length 2 = {...}) at framework/source/loadenv/loadenv.cxx:169
> #25 0x00007ff592ff8ce2 in framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x18b3be0, sURL="file:///xmlsecurity/qa/unit/signing/data/tdf42316.ott", sTargetFrameName="_default", nSearchFlags=0, lArguments=uno::Sequence of length 2 = {...}) at framework/source/services/desktop.cxx:593
> #26 0x00007ff592ff8da5 in non-virtual thunk to framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () at workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/lang/XComponent.hpp:136
> #27 0x00007ff593d7bb28 in unotest::MacrosTest::loadFromDesktop(rtl::OUString const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x18a6d80, rURL="file:///xmlsecurity/qa/unit/signing/data/tdf42316.ott", rDocService="", rExtraArgs=uno::Sequence of length 1 = {...}) at unotest/source/cpp/macros_test.cxx:61
> #28 0x00007ff5956b132d in testPreserveMacroTemplateSignature10::TestBody() (this=0x18a6d30) at xmlsecurity/qa/unit/signing/signing.cxx:1243
Change-Id: If2c45a8fc8d907b12f4d92c77f524d50d9e928cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100344
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It seems all 3 places derive from unotest::MacrosTest, so extract the
common code there.
Change-Id: I71a2474a7d6b1623f50575f9e9c43580ba076330
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100185
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This was duplicated under xmlsecurity and made it hard to have test code
outside xmlsecurity, even if the core of the pdf signing is nowadays
under svl/.
Change-Id: If5ce8269bb72f503263727d8255fe856742dfa60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96745
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
... to configuration and UI.
The new default is ODF 1.3 Extended, which is now ODFVER_LATEST and
stored as value "3" in configuration.
Adapt a few places related to DocumentDigitalSignatures etc. to new
default.
Change-Id: I420da4f7787cc864c6bd88470d61b146b9399aa1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93177
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Most of these are calls to
DocumentDigitalSignatures::createWithVersion(), where it doesn't make a
difference if "1.2" or "1.3" is passed in but maybe it will be different
with "1.4".
There is another ctor createDefault() which looks appropriate for
non-ODF contexts and can also be used when no actual signing or
verifying is done.
In cases where there's an actual document its Storage has the version.
Change-Id: Id636bbf965d9f96c7ed5f50774c509032525b2b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93091
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
This was supposed to be implemented by commit
a7bf6488eb
"ODF1.3: import new OpenPGP encryption markup"
but it turns out that the ODF 1.3 cs01 schema differs from the
implementation:
in ODF 1.3 cs01 we have
<manifest:encrypted-key>
<manifest:encryption-method .../>
<manifest:keyinfo>
<manifest:PGPData>
</manifest:PGPData>
</manifest:keyinfo>
<manifest:CipherData>
</manifest:CipherData>
</manifest:encrypted-key>
whereas the implementation expects
<manifest:keyinfo>
<manifest:encrypted-key>
<manifest:encryption-method .../>
<manifest:PGPData>
</manifest:PGPData>
<manifest:CipherData>
</manifest:CipherData>
</manifest:encrypted-key>
</manifest:keyinfo>
Ideally the inner manifest:keyinfo should be manifest:KeyInfo but
not sure if that really matters.
Change-Id: I407321c857e7b3ed9f4d04568ca2ea116764b3da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94309
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
to find places where we are converting stuff to unique_ptr
instead of using std::make_shared.
As a bonus, this tends to find places where we are using shared_ptr
where we can instead be using unique_ptr avoiding the locking overhead.
Change-Id: I1b57bbc4a6c766b48bba8e25a55161800e149f62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93207
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
As already stated in the comments of the signing unit tests,
disabling macro security will not only ignore the signatures, but
actually drop the macro signature, as these are never evaluated
and as a result can't be restored for the new document.
Change-Id: Ie41a9e72d3367c2eed58a52387bb67d8c41abff3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90435
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
...following up on 314f15bff0 "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>
This extends the filter comparison from commit c3a1c83ff5
("tdf#42316 preserve macro signature of templates").
The original patch just stripped "_template" from the source
filter to find equal document types, which just enables the
"template => document" case. This patch also strips the
"_template" from the target filter, which fixes the "document
or template => template" cases.
This also extends the signing save tests:
* OTT 1.2 => OTT 1.2 - preserve
* ODT 1.2 => OTT 1.2 - preserve
* OTT 1.0 => OTT 1.0 - preserve
* ODT 1.0 => OTT 1.0 - preserve
* OTT 1.0 => OTT 1.2 - drop
Change-Id: Ie297258a4d9f9aa4beb25786c6ba240b6f16f49b
Reviewed-on: https://gerrit.libreoffice.org/80654
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
look for places we should be using std::as_const on for-range
loops over uno::Sequence, to avoid triggering a copy
Change-Id: I7efb641bf09d37c87946f03428ee4eec90298c8a
Reviewed-on: https://gerrit.libreoffice.org/77441
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Ilmari Lauhakangas