The Windows OLE2 implementation of the embedded object interface assumes
that the same thread is used for loading and saving the embedded
objects.
This means that in case the main thread is used for loading (e.g. from
remote UNO, but with OnMainThead=true), but a
thread is used for storing (without an explicit OnMainThead=true), then
the underlying win32 API call failed and we returned a fixed size in
EmbeddedObjectRef::GetSize().
Fix the problem by explicitly checking for RPC_E_WRONG_THREAD and adding
error handling for that case.
Change-Id: Icf1e7722d33a809fa671d1505b2a0155af040c71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115236
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
How to reproduce the problem:
1) Create an ODT file which has an OLE object, where the native data is
an OLE2 container, containing a Package stream, containing a DOCX file
2) Install some external application on Windows which registers itself
as a handler for the DOCX CSLID [ this is where writing a testcase for
this bug is challenging ].
3) Open this document via Java, using URP. Load the document with
Hidden=true and OnMainThread=true.
4) Save the document using XStorable.store().
Expected result: the native data is there.
Actual result: the native data is sometimes missing (0 bytes).
The root cause is that GetUserClassID() Win32 API call in
OleComponent::StoreOwnTmpIfNecessary() fails in some cases, and
re-trying a few times after a small sleep doesn't help.
Handle this error better by doing what
OleEmbeddedObject::SwitchOwnPersistence(XStorage, OUString) already
does: discard the old native data only if we have non-empty new native
data.
A result of the above was that an export to reqif-xhtml (sw HTML export
with FilterOptions set to xhtmlns=reqif-xhtml) wrote empty \objdata.
Change-Id: I59611601cf09597e9f7727db5bd6d7426fe17b75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114537
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
How to reproduce the problem:
1) Create an ODT file which has an OLE object, where the native data is
an OLE2 container, containing a Package stream, containing a DOCX file.
2) Install some external application on Windows which registers itself
as a handler for the DOCX CSLID [ this is where writing a testcase for
this bug is challenging ].
3) Open this document via Java, using URP. Load the document with
Hidden=true and OnMainThread=true.
4) Dispatch .uno:UpdateAll
5) Save the document using XStorable.store()
Expected result: the native data is there.
Actual result: the native data is sometimes missing (0 bytes). Typically
happens at least once if you perform the steps 4 times in a row.
The root cause is that GetUserClassID() Win32 API fails in some cases,
and re-trying a few times after a small sleep doesn't help.
Handle this error better by detecting this situation in
OleEmbeddedObject::SwitchOwnPersistence() and reusing the old native
data, similar to how svt::EmbeddedObjectRef::GetReplacement() updates
the preview image in a transactional way (only delete the old one when
we have a one one).
Finally, detect a broken OLE2 preview during reqif export, this way the
reqif export result's embedded object is editable in Word, while
\objdata was simply empty previously.
Change-Id: I4dd34ebe6ad892a14cdcfb82acc82d9edf790fb3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113814
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Before deactivating a linked OLE saved it and overwrote the
original, even when not saving the hosting document at all.
This is not intuitive from user perspective and may lead
to unexpected data loss (of the OLE content).
Reported case was especially about closing the hosted document
without saving in the understandable believe that that way the
changed OLE will not be changed on external medium.
Added mechanism for linked OLE to hold data in a hidden local
temp file, synching/writing back on hosting file save. Most
complicated was adapting the 'break link' case and ensuring
other cases to work, but looks good now from my POV
Change-Id: I7f63d667820b2d9725abc598a9dd7360be1f8d5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113793
Tested-by: Armin Le Grand <Armin.Le.Grand@me.com>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Take m_xDocHolder->GetComponent() and xModif->setModified
inside the local try..catch expression to ensure that the
reset of the linked state below (m_bIsLink and .clear())
is executed
Change-Id: I52d49569a43fd2c23dd997c7217f7552cbdcfb82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113722
Tested-by: Armin Le Grand <Armin.Le.Grand@me.com>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
So in SfxViewFrame::GetState_Impl in case SID_OBJECT hasVerbs is not
empty, so that the doVerb attempt with -9 fallback is attempted
Change-Id: If32c50fedbc2a269ac277061c76a63514d320bb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110316
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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>
Unused ever since the code was introduced in
5ea5c0afeb "#112923# embedded object for MS OLE".
(The accompanying
// TODO: use aContName and aEmbDocName in m_pOleObject->SetHostNames()
comment was removed when a307ad7ae0 "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>
...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>
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>
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>
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>
...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>
...so forbid anything else, to avoid issues like the one described in
766cdd869d "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>
Stephan Bergmann