summaryrefslogtreecommitdiff
path: root/svl
AgeCommit message (Collapse)AuthorFilesLines
2022-04-01add Initialization Vectors to password storageCaolán McNamara2-51/+138
old ones default to the current all zero case and continue to work as before Change-Id: I6fe3b02fafcce1b5e7133e77e76a5118177d77af Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131974 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 192fa1e3bfc6269f2ebb91716471485a56074aea)
2022-04-01make hash encoding match decodingCaolán McNamara2-9/+45
Seeing as old versions of the hash may be in the users config, add a StorageVersion field to the office config Passwords section which defaults to 0 to indicate the old hash is in use. Try the old varient when StorageVersion is 0. When a new encoded master password it set write StorageVersion of 1 to indicate a new hash is in use and use the new style when StorageVersion is 1. Change-Id: I3174c37a5891bfc849984e0ec5c2c392b9c6e7b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132080 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-01-29fix loading file with very large number of stylesNoel Grandin1-12/+12
where nCurrentPosition was wrapping around Change-Id: I839215f3138d58884f03509b6341147ef28edb4c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129108 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> (cherry picked from commit 7f3682ecb8a40fe85b6525be9e73d49d76bb308b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129074 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2021-11-13sw, out of order undo: allow multiple actions from other viewsMiklos Vajna1-5/+13
Previously we assumed that the action to be executed is always exactly the top of the undo stack minus 1 element. Extend this, so that in case an other view appends two or more elements to the undo stack, we still find our undo action. Obviously only do this if all those undo actions are independent from us. This requires replacing the swap in svl/ with a move-out + move a range down + move in construct. (cherry picked from commit 39f231360013e944a8713248359662b9f282d902) Conflicts: sw/source/core/undo/docundo.cxx Change-Id: Ic12d32d6eb5e77618d99eddb4fa096802f32d655 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125102 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-11-11sw, out of order undo: allow a subset of a non-empty redo listMiklos Vajna1-2/+2
Specifically, we used to not allow out of order undo at all if the redo list was non-empty. This relaxes that condition a bit. Out of order undo is OK with a non-empty redo list, in case all undo actions in the redo list are either 1) owned by the current view or 2) independent from the undo action to be executed I.e. if view1 has lots of type undo actions and an view2 adds a single type undo action on top of it, then allow view 1 to execute multiple of its typing undo actions, not just a single one. (cherry picked from commit 2875c65946e59f5dd7968155463bf00bd71d440b) Conflicts: sw/source/core/undo/docundo.cxx Change-Id: I2f5d9404a9994ed74b65233d2a315976c27b28b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125039 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-11-11sw: allow undo of typing in 2 views independent from each otherMiklos Vajna1-0/+10
Undoing out of order is dangerous by default, so limit this to a very specific case as a start, that allows growing in follow-up commits. For now, allow out of order undo if: 1) redo stack is empty 2) we're in LOK mode (different views represent different users) 3) we undo a single action (count is 1) 4) the top undo action doesn't belong to the current view 5) the top and the previous undo actions are independent Which only requires that SwUndoInsert::UndoImpl() is independent for two different paragraphs, which seems to be the case. Independent undo actions opt in for this, currently the only such allowed undo action is SwUndoInsert ("typing"), which adds characters to a single text node. Even those are only considered independent if they operate on different text nodes. On the positive side, this allows out of order undo in the frequent case where two users collaborate on a long document and they just type some new content into the document at different paragraphs. (cherry picked from commit 8e8e72f08b01a284cf1a90b888d48acfb6a33d2e) Conflicts: sw/source/core/inc/UndoManager.hxx sw/source/uibase/shells/basesh.cxx Change-Id: Ibb4551e8f7046b4947491b8bf751eaa0cbb2d060 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124955 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-11-10Resolves: tdf#145386 Use "Default" for LANGUAGE_PROCESS_OR_USER_DEFAULTEike Rathke1-1/+1
There's no, specifically not in Writer, handling of the LCID 0x0400 LANGUAGE_PROCESS_OR_USER_DEFAULT language/locale concept other than the number formatter mapping it to LANGUAGE_SYSTEM. Use the LANGUAGE_SYSTEM "Default" string in UI (status bar, status menu, language list) but keep the LCID, and don't append the resolved locale string as it is also displayed both in the Font Western and CJK listboxes. This ends up as two list entries, like * Default - English (UK) first entry * Default last entry of which the second would be selected. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124449 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins (cherry picked from commit 0f3c19ee61ec371aa32d9f51c3555d3ea8ae9eeb) Conflicts: svtools/source/misc/langtab.cxx Change-Id: I8d9e4171bee6bbe9d1c9dcfb7a5fa8fc92ea1a2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124204 Tested-by: Jenkins Tested-by: Michael Meeks <michael.meeks@collabora.com> Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124450 Reviewed-by: Eike Rathke <erack@redhat.com> Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2021-09-30Resolves: tdf#116184 Check that there is no trailing number behind a matchEike Rathke1-2/+3
... without being separated by a blank so the match is rejected if it doesn't possibly form a date+time input and input can be accepted as decimal fraction. Change-Id: Iabd1d216366ecb8454c59822ce58f112bfa6091e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122024 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins (cherry picked from commit eb0b4ab2d3b86d77ee0edb652d4486343e5b3b1f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122055 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-08-16Resolves: tdf#143664 {de-*} accept "Mär" and "Mrz" for MarchEike Rathke1-0/+16
Change-Id: I82c094687137995a634450cb4f617909859d1688 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119916 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins (cherry picked from commit 4961dbaecc9e5cac57d99d2ea9d265a90daa4a8b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119859 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-07-11Remove warning while buildingdante1-1/+1
Operator >>= from any does not guarantee initialization, so compiler warns you. Value defaluted at 0. Change-Id: Icecc765be73bb653f0167958e319a1417df6ac86 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108485 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> (cherry picked from commit edc7a8a372a689802a583092ff0da0f60b6dbf97) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118584 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-07-11Resolves: tdf#143165 Date input must match separator, D,M,Y not part ofEike Rathke1-2/+17
Change-Id: Iae464fd0fc6c480b9a16ccb2f8eb635812c6eeff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118408 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins (cherry picked from commit 89a3caee73c476133af804d9a0a650e72e711d95) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118421 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-06-14Assert on valid order of which ids in ranges on SfxItemSet creationMike Kaganski3-345/+172
This allows to make sure we actually use sorted which ranges, and then it's safe to call SfxItemSet::MergeRange when needed. Also this change relaxes the previous requirement that ranges must be separated by at least one; this allows to have adjacent ranges, like in RES_FRMATR_BEGIN, RES_FRMATR_END-1, RES_GRFATR_BEGIN, RES_GRFATR_END-1, where RES_FRMATR_END is equal to RES_GRFATR_BEGIN. Allowing this makes possible to (1) self-document the ranges, so it's clear which ranges are included; and (2) be safe in case when these constants would change, so that the one merged range would not unexpectedly contain everything inserted between RES_FRMATR_END and RES_GRFATR_BEGIN. Change-Id: Iaad0f099b85059b3aa318a347aa7fbd3f6d455c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116909 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117106 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2021-05-16Resolves: tdf#142186 Accept 123.45 fractional input on weird formats like 0"."Eike Rathke1-5/+23
... or 0"."0 where the literal "." is also the decimal separator but can only occur in the integer part. Change-Id: I95093fdddf7759346f2869ee322222de3d130e55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115338 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins (cherry picked from commit 3561978410579c5222889eb7dce68f917b550334) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115277 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-03-16xls save: fix writing inline calendar modifiers as format code, don'tEike Rathke1-3/+6
E.g. ja-JP GGGE [~gregorian]YYYY saved as OOXML ended up as [$-411]ggge\ gregorianyyyy which when reloaded became GGGE GREGoRianYYYY displaying 令和3 R033Ro03ian2021 (whatever Xcl might have done with that). Change-Id: If8a7d5b837b69c32afacc7a8d7646fedc84ab87a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112510 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins (cherry picked from commit 3e73d3475711b790cc80b9a286c5d454f3929384) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112519 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-03-04xmlsecurity: improve handling of multiple X509Data elementsMichael Stahl1-4/+12
Combine everything related to a certificate in a new struct X509Data. The CertDigest is not actually written in the X509Data element but in xades:Cert, so try to find the matching entry in XSecController::setX509CertDigest(). There was a confusing interaction with PGP signatures, where ouGpgKeyID was used for import, but export wrote the value from ouCertDigest instead - this needed fixing. The main point of this is enforcing a constraint from xmldsig-core 4.5.4: All certificates appearing in an X509Data element MUST relate to the validation key by either containing it or being part of a certification chain that terminates in a certificate containing the validation key. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111254 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 9e82509b09f5fe2eb77bcdb8fd193c71923abb67) xmlsecurity: improve handling of multiple certificates per X509Data It turns out that an X509Data element can contain an arbitrary number of each of its child elements. How exactly certificates of an issuer chain may or should be distributed across multiple X509Data elements isn't terribly obvious. One thing that is clear is that any element that refers to or contains one particular certificate has to be a child of the same X509Data element, although in no particular order, so try to match the 2 such elements that the parser supports in XSecController::setX509Data(). Presumably the only way it makes sense to have multiple signing certificates is if they all contain the same key but are signed by different CAs. This case isn't handled currently; CheckX509Data() will complain there's not a single chain and validation of the certificates will fail. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111500 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 5af5ea893bcb8a8eb472ac11133da10e5a604e66) xmlsecurity: add EqualDistinguishedNames() Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111545 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 1d3da3486d827dd5e7a3bf1c7a533f5aa9860e42) xmlsecurity: avoid exception in DigitalSignaturesDialog::getCertificate() Fallback to PGP if there's no X509 signing certificate because CheckX509Data() failed prevents the dialog from popping up. To avoid confusing the user in this situation, the dialog should show no certificate, which is already the case. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111664 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 90b725675c2964f4a151d802d9afedd8bc2ae1a7) xmlsecurity: fix crash in DocumentDigitalSignatures::isAuthorTrusted() If the argument is null. This function also should use EqualDistinguishedNames(). Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111667 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit ca98e505cd69bf95d8ddb9387cf3f8e03ae4577d) Change-Id: I9633a980b0c18d58dfce24fc59396a833498a77d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111901 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-19Clarify DdeData::GetExternalFormat return typeStephan Bergmann2-15/+12
The implementation (in svl/source/svdde/ddedata.cxx) returns any of: * {CF_TEXT=1, CF_BITMAP=2, CF_METFILEPICT=3} from the Windows API; * the return value of Windows API's RegisterClipboardFormatW, which is UINT from the Windows API (i.e., 32-bit unsigned int); * a enum SotClipboardFormatId value, whose underlying type is sal_uInt32. So the natural choice is sal_uInt32 here. (Windows API's UINT would also do, but cannot be used in include/svl/svdde.hxx, which is used on all platforms.) That in turn shows that DdeService's aFormats and HasCbFormat should also use sal_uInt32. (And then, simplify some of the std algorithms use in svl/source/svdde/ddesvr.cxx.) Change-Id: I593d0a7df78bfdd08ce2de04c3da2078d973e262 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106151 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-19svl/source/svdde/ddedata.cxx is only compiled on Windows anywayStephan Bergmann1-4/+0
(cf. svl/Library_svl.mk) Change-Id: Iff41c9c56c1e0ca52ea93268ddfa76b6630d2eb4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106124 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-17loplugin:stringviewparam extend to constructorsNoel1-6/+6
Change-Id: Ia573921566ec6079b843cbcc0401d9d0f5c62089 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105969 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-16tdf#123936 Formatting files in module svl with clang-formatPhilipp Hofer12-201/+129
Change-Id: Iaaac34428ef0e5b8f09f6cbcad16ea5bab145321 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105714 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-11-12New loplugin:stringviewparamStephan Bergmann1-1/+1
...to "Find functions that take rtl::O[U]String parameters that can be generalized to take std::[u16]string_view instead." (Which in turn can avoid costly O[U]String constructions, see e.g. loplugin:stringview and subView.) Some of those functions' call sites, passing plain char string literals, needed to be adapted when converting them. Change-Id: I644ab546d7a0ce9e470ab9b3196e3e60d1e812bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105622 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-11loplugin:stringviewNoel2-2/+2
Add new methods "subView" to O(U)String to return substring views of the underlying data. Add a clang plugin to warn when replacing existing calls to copy() would be better to use subView(). Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11make tools::Long 64-bit on Windows platformNoel Grandin2-8/+8
This is only for the 64-bit windows platform. I don't see the point in messing with the 32-bit platforms, they are (a) become more and more rare (b) unlikely to even have enough available process memory to load extremely large calc spreadsheets The primary problem we are addressing here is bringing Windows-64bit up to same capability as Linux-64bit when it comes to handling very large spreadsheets, which is caused by things like tools::Rectangle using "long", which means that all the work done to make Libreoffice on 64-bit Linux capable of loading large spreadsheets is useless on Windows, where long is 32-bit. The operator<< for tools::Rectangle needs to be inside the tools namespace because of an interaction with the cppunit printing template stuff that I don't understand. SalPoint changed to use sal_Int32, since it needs to be the same definition as the Windows POINT structure. Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-03remove pimpl in SfxBroadcaster/SfxListenerNoel Grandin2-82/+55
and provide an optimised copy constructor, we can avoid a bunch of work. Change-Id: I3a373fbbfab02455e6a65e9036b3629366174379 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105205 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-02move SwCondCollCondChg on top of SfxHintBjoern Michaelsen1-1/+0
... and get rid of ModifyNotifications along the way. Change-Id: I10fc9d24743d50cef771ff63dae004d31dce1846 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105195 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
2020-10-31remove pimpl from FSStorageNoel Grandin2-154/+40
Change-Id: If2db85b2fde3ffdd8aa033de74773327e70d3011 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105082 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-21new tools::Degree10 strong typedefNoel Grandin1-45/+14
partly to flush some use of "long" out the codebase, but also to make it obvious which units are being used for angle values. Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-19use tools::Long in svlNoel7-20/+23
Change-Id: Ic63d3c0ebd1e58d7bab5b0fd6313cabddc16eb98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104517 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-14Resolves: tdf#137453 Implicit conversion from sal_uInt64 to sal_Int32 is bad..Eike Rathke1-13/+14
Change-Id: I5681249808cf623d3b7df09988f285268ea8d85f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104255 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-10-08use sal_Int32 for style-sheet indexNoel Grandin3-47/+43
instead of a mix of unsigned and sal_uInt16. Change-Id: Ice56d58d22856daa6645577610368ba19a849176 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104076 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-06loplugin:const* make some params and methods constNoel1-1/+1
Change-Id: If7fbb25037343e18081a8ee7064840d75e9a45a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104010 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-04loplugin:reducevarscope in store..svtoolsNoel2-6/+3
Change-Id: Iaa6c6eac15cb73fc2a76ba1c5241297c94d297cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103839 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-03use more TOOLS_WARN_EXCEPTIONNoel1-2/+1
Change-Id: I8b5cde993c13e0b7c8c830b1ff698933a6b7cfd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103863 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-02Use the new single-instance="true" attribute in svlStephan Bergmann2-5/+3
Change-Id: Iedd4348f3ea896dc613e0062a1a9cb5904c8bbb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103844 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-01tdf#136728: Revert "tdf#136238 speed up deleting large cross page table"Xisco Fauli1-8/+4
This reverts commit da5c289a9cae5d914937f235694fd5b0cb92547f. Change-Id: Ic6a77ec2cd3b502fb4e94159a0424340850590df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103665 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-26Related: tdf#136985 SfxStringListItem::GetString() crash in empty caseCaolán McNamara1-3/+2
probably since... commit a573b8b21688d9681f4fa129ec37cf89954e9d1c Date: Sat May 21 16:14:56 2011 -0430 Replace List for std::vector in SfxStringListItem. Change-Id: I7060b5693ba08fa5f70cc5cb3ae1b7a4722a31a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103408 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-23Read MOSDocumentLockFile UTF-16 string data with same endiannessStephan Bergmann1-2/+10
...as MSODocumentLockFile::WriteEntryToStream has written it to (i.e., always as UTF-16LE, assuming that is actually the right format to use). The discrepancy between writing and reading the string data appears to be present ever since the code's introduction in 5db1e20b8b0942dac2d50f3cd34532bb61147020 "Introduce new lockfile handler for MSO like lockfiles". This caused CppunitTest_svl_lockfiles to fail on (big-endian) s390x Linux with > svl/qa/unit/lockfiles/test_lockfiles.cxx:578:(anonymous namespace)::LockfileTest::testWordLockFileRT > equality assertion failed > - Expected: LockFile Test > - Actual : 䰀漀挀欀䘀椀氀攀 吀攀猀琀 etc. Change-Id: I97267aa14a3a926e7fd7bb1d2ce7d2de05d52a64 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103238 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-23Convert attribute value to UTF-8 when passing it to libxml2Stephan Bergmann1-1/+2
Using toUtf8, requiring the OUString to actually contain well-formed data, but which is likely OK for this test-code--only function, and is also what similar dumpAsXml functions e.g. in editeng/source/items/textitem.cxx already use. This appears to have been broken ever since the code's introduction in 553f10c71a2cc92f5f5890e24948f5277e3d2758 "add dumpAsXml() to more pool items", and it would typically only have written the leading zero or one (depending on the architecture's endianness) characters. (I ran across it on big-endian s390x, where CppunitTest_sd_tiledrendering SdTiledRenderingTest::testTdf104405 failed because of > Entity: line 2: parser error : Input is not proper UTF-8, indicate encoding ! > Bytes: 0xCF 0x22 0x2F 0x3E > ation=""/><SfxPoolItem whichId="4017" typeName="13SvxBulletItem" presentation="% > ^ apparently reported from within libxml2.) Change-Id: I4b116d3be84098bd8b8a13b6937da70a1ee02c7f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103236 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-09-23tdf#128136: Build curl, nss, and xmlsec for iOS, tooTor Lillqvist1-2/+2
We must link nss statically, including the three dylibs that normally are loaded at run-time, because including bare dylibs in an iOS appp on the App Store is not OK. See https://developer.apple.com/forums/thread/125796 . For linking the softokn3 library statically, NSS already had code, behind NSS_STATIC_SOFTOKEN ifdefs. Introduce two more macros: NSS_STATIC_FREEBL for the freebl library and NSS_STATIC_PKCS11 for the nssckbi library. Turn off parallelism for the sub-make building nss. There seems to be race conditions or something when running simultaneous instances of the nsinstall.py script or the nsinstall program in nss (used when building nss for the build platform). When cross-compiling from macOS, use python3 to run the nsinstall.py script, as it is Python 3. Change-Id: Idd427b5ebf21f802b3feb0d5a3d259317ba8fc67 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103106 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103218 Tested-by: Jenkins
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann6-12/+17
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "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>
2020-09-10Remove some DBG_UTIL debug codeStephan Bergmann1-72/+2
...that had originally started to get introduced with 159a4c3c75e3a7aecbf1656f3254331892098ba7 "tdf#84881: WiP: Fill in more fields of the TimeStampReq" saying: "Temporarily, dump the TimeStampReq object to a file for inspection in a DBG_UTIL build." (I came across this when wondering why such PDFWRITER.cms.data and PDFWRITER.hash.data files kept popping up in my source/build trees.) Change-Id: I28beabe912beb112e1c71c8e3b559e161b22849b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102393 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Jenkins
2020-09-10tdf#136238 speed up deleting large cross page tableNoel Grandin1-4/+8
Goes from more than 30s to less than 1s on my pc. We were getting stuck inside the loop in sw::UndoManager::AddUndoAction, because the RemoveOldestUndoAction was continually doing nothing because it was hitting the if ( IsInListAction() { assert(!"SfxUndoManager::RemoveOldestUndoActions: cannot remove a not-yet-closed list action!"); return; } code. Which means that there is some bug here, but I'm not sure what. We are deep inside the delete logic at that point, and it doesn't seem unreasonable to opportunistically delete some of the UNDO list at that point. So the real fix is just the conversion from a while loop to an if-check. Change-Id: Ie2707009dd6574b996421f67d952ab9fdaaaf6aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102378 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-07Make the OUString ctors taking raw sal_Unicode pointer/non-const array explicitStephan Bergmann2-3/+3
...and in turn add OUString::operator = and OUString::operator += overloads that take a std::u16string_view. Without making the ctors explicit, the operator overloads would have caused ambiguities when called with raw sal_Unicode pointers/non-const arrays, as those can convert to both OUString and to std::u16string_view. But the std::u16string_view operator overloads will generally be useful when changing OUStringLiteral similarly to 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which point many existing uses of OUStringLiteral will be replaced with uses of std::u16string_view. Implementing this change turned up a need for an operator = overload for OUStringNumber, which has thus been added. No such need turned up for a corresponding operator += overload, but which can easily be added when the need arises. It also revealed that the operator == overloads between an OUString and a raw sal_Unicode pointer/non-const array were implemented rather inefficiently, creating a temporary OUString from the raw argument. Those have been improved. Preceding commits have already taken care of many dubious or simply unnecessary implicit uses of the now-explicit OUString ctors. This commit makes explicit the few remaining reasonable uses. (And in some cases needed to change variable initialization syntax from using parentheses to using curly braces, to avoid the most vexing parse issue. And needed to explicitly add OUString ctors from char16 const[2] string literal lvalues in a conditional expression in writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary because MSVC apparently still insists on doing array-to-pointer decay there.) All of this only affects LIBO_INTERNAL_ONLY. Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-04TabPage no longer needs to inherit from VclBuilderContainerCaolán McNamara1-1/+4
Change-Id: Iaab26ade1109daf732e58a2f3741cc43243e374c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102023 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-04Make many OUString functions take std::u16string_view parametersStephan Bergmann1-1/+1
...instead of having individual overloads for OUString, OUStringLiteral, and literal char16_t const[N]. (The variants taking OUString are still needed for !LIBO_INTERNAL_ONLY, though. The variants taking ASCII-only literal char const[N] are also left in place.) This nicely reduces the number of needed overloads. std::u16string_view allows to pass as arguments: * OUString * OUStringLiteral * OUStringChar (with the necessary conversion added now) * OUStringNumber * u"..." char16_t string literals * u"..."sv std::u16string_view literals * std::u16string, plain char16_t*, and more A notable exceptions is OUStringConcat, which now needs to be wrapped in OUString(...), see the handful of places that needed to be adapted. One caveat is the treatment of embedded NUL characters, as std::u16string_view(u"x\0y") constructs a view of size 1, while only u"x\0y"sv constructs a view of size 3 (which matches the old behavior of overloads for literal char16_t const[N] via the ConstCharArrayDetector<>::TypeUtf16 machinery). See the new checkEmbeddedNul in sal/qa/rtl/strings/test_oustring_stringliterals.cxx. The functions that have been changed are generally those that: * already take a string of determined length, so that using std::u16string_view, which is always constructed with a determined length, is no pessimization (e.g., there are operator == overloads taking plain pointers, which do not need to determine the string length upfront); * could not benefit from the fact that the passed-in argument is an OUString (e.g., the corresponding operator = overload can reuse the passed-in OUString's rtl_uString pData member); * do not run into overload resolution ambiguity issues, like the comparison operators would do. One inconsistency that showed up is that while the original replaceAll(OUString const &, OUString const &, sal_Int32 fromIndex = 0) overload takes an optional third fromIndex argument, the existing replaceAll overloads taking OUStringLiteral and literal char16_t const[N] arguments did not. Fixing that required a new (LIBO_INTERNAL_ONLY) rtl_uString_newReplaceAllFromIndexUtf16LUtf16L (with test code in sal/qa/rtl/strings/test_strings_replace.cxx). Another issue was posed by test code in sal/qa/rtl/strings/test_oustring_stringliterals.cxx that used the RTL_STRING_UNITTEST-only OUString(Except*CharArrayDetector) ctors to verify that certain function calls should not compile (and would compile under RTL_STRING_UNITTEST by taking those Except*CharArrayDetector converted to OUString as arguments). Those problematic "should fail to compile" tests have been converted into a new CompilerTest_sal_rtl_oustring. Change-Id: Id72e8c4cc338258cadad00ddc6ea5b9da2e1f780 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102020 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-03Make ImpSvNumberformatScan::GetColor constMike Kaganski6-28/+27
Change-Id: Idbcce18029944ab884cdde03e21190cbb574a00f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102005 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2020-09-03Simplify standard color initializationMike Kaganski2-50/+30
Change-Id: Ife1c8365298fec713713739073b91d601b459e6e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101990 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann4-22/+22
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>
2020-08-27remove some unused includes and update pchesCaolán McNamara1-1/+1
Change-Id: I786548bef39fa711aabcff32b592b3fdc4a6f9fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101486 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-27expand out StringSet typedefNoel Grandin2-6/+4
Change-Id: If7791d51d055ad918b54a52bee3f13a79c5468f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101435 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-19update pchesCaolán McNamara1-3/+1
Change-Id: I6a300169d33bdc36e4c7e720a7afc336a86eea68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100962 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-26 03:19:49 +0000