summaryrefslogtreecommitdiff
path: root/sw/source/core/unocore
AgeCommit message (Collapse)AuthorFilesLines
2020-11-07std::set->o3tl::sorted_vector in SwSoftPageBreakListNoel1-1/+1
Change-Id: I929b2eb5824580d106b2505ea6b2d0a59248a6f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104856 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-05retire most of SwModifyBjoern Michaelsen2-7/+5
only remaining uses are: - in calbck.{c,h}xx - in uwriter unittests - as a parameter of SwClientNotify all other uses have been replaced with sw::BroadcastingModify, which contains sw::BroadcastingMixin functionality. Existing code should then be moved to sw::BroadcastingMixin (only) as soon as possible. Change-Id: Ief7895597633c2fcb97e1cbc182905d75feb1567 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105320 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
2020-11-02Field, FieldType: Remove remaining calls to ModifyNotificationBjoern Michaelsen1-1/+1
Change-Id: I8a825711f3b1f1085b4da90d4d09e837161329f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105193 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
2020-11-02sw: return SwXFieldmark in SwXFieldEnumerationMichael Stahl4-11/+183
* Implement text::XTextField in SwXFieldmark * That requires overriding XTextContent, just forward to SwXBookmark * Also override XServiceInfo implementation in SwXFieldmark * Add a PropertySetInfo for SwXFieldmark, which doesn't support "Hidden" or "Condition" properties of SwXBookmark * in SwXFieldmark::setFieldType(), only allow sensible new types * fix DomainMapper_Impl assumptions that if it implements XTextField it can't be a fieldmark, which caused CppunitTest_sw_ooxmlexport10 testTdf92157 to fail with a SAXException caused by some disposed SwXTextCursor Change-Id: I1ae2e9cb99ea784040874517e4d1af7e59d24405 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105083 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-11-01std::set->o3tl::sorted_vector in ExportFramesNoel Grandin1-8/+6
Change-Id: Ic82a1aad7df2b0088a78c8d82ceb487d8b9e0571 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105133 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-30Related: tdf#98868 add SwDoc& member to SwTOXTypeCaolán McNamara1-2/+2
Change-Id: Ic1dc600e75cb4f6a7a0aa86714a87e3ec5658cb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104926 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-28std::set->o3tl::sorted_vector in swNoel Grandin3-10/+10
Change-Id: Ib647878c129171e5d633a783a262a56f4c1fb7af Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104969 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-20use tools::Long in swNoel4-4/+4
Change-Id: I44be72b3a9b14823ec37a3c799cffb4fb4d6e1de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104527 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-06tdf#97128 DOCX import: fix frame directionDaniel Arato (NISZ)1-0/+17
Frames used to be imported with zero rotation even if a w:textDirection tag explicitly called for a non-default orientation. I found no other solution to pass the incoming frame direction property on to the SwXFrame about to be created. 1. If you put the property into the GetSectionContext(), it gets overwritten when the next w:pPr tag is parsed, so all three frames will end up having the same direction. 2. If you put the property into the GetTopContextOfType(CONTEXT_PARAGRAPH) that context gets popped off the stack before control even gets to CheckUnregisteredFrameConversion(). 3. If you use PushStyleSheetProperties (which is bad in and of itself), the order will be messed up because the frames are not necessarily created in the same order as they are described in the file, so each frame gets a wrong frame direction in the end. Follow-up of commit 5a5597655a4bf12e4ca07c9c2b6f6221e217f080 (tentative fix for fdo#30474# [DOCX rotated text import failure]). Change-Id: I6e3d68fe60c6e2a5b6684c65a964dd86d0168181 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103553 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-10-05SwGetRefFieldType ctor never passed a null SwDoc*Caolán McNamara1-2/+2
ditto: SwFEShell::Copy SwEditShell::Copy SwFEShell::CopyDrawSel SwFEShell::Paste SwChartDataProvider ctor ResetInDoc family Change-Id: I2d1544c09919f0e566fadc04d3b160b18ea62fc7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103957 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-05SwDateTimeField::GetDateTime always dereferences its SwDoc*Caolán McNamara2-14/+14
ditto: SwXFrameEnumeration ctor lcl_ReAssignTOXType Change-Id: Idaa6bef29cbc4c3a08d578ef4bedcaa071547944 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103928 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-04SwXAutoStylesEnumerator always dereferences its SwDoc* argCaolán McNamara1-12/+12
ditto: SwNumFormat::UpdateNumNodes SwEditShell::CopySelToDoc Change-Id: I5f18b04e420facb703fcace20c645281d409cea6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103923 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-03use more TOOLS_WARN_EXCEPTIONNoel1-6/+5
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-09-30SwDocFac::GetDoc can return a referenceCaolán McNamara1-1/+2
and remove discovered redundant null checks Change-Id: I200fd0ad61b307c78a354b7a6929b70045fee488 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103690 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-30SwPosition::GetDoc can return a referenceCaolán McNamara2-7/+4
and remove discovered redundant null checks Change-Id: I90e2a84b260bfaf283b787db055cd1ed54dab4ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103676 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-30SwPaM::GetDoc can return a reference insteadCaolán McNamara13-215/+206
and remove discovered redundant null checks Change-Id: Iac8ad7821d9acfcc9550a96402c02ac248f16f2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103672 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-30loplugin:reducevarscope in swNoel2-4/+2
Change-Id: Ifed7220c6acf7049b2985f1911a806b37a54d794 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103646 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-30SwNode::GetDoc can return a reference insteadCaolán McNamara9-27/+27
and remove discovered redundant null checks Change-Id: I6b8bc9593434f38947e399a48888a8fa0d4f7e77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103640 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-28'Jaket' -> EnvelopeCaolán McNamara1-1/+1
Change-Id: Idcf95141ca4169fa0c1580c99a7e51a3df77f640 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103535 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-22tdf#132970 SMP bullets mangledCaolán McNamara1-8/+11
working: a) bullet preview b) writer rendering c) save to odt a) load from odt Change-Id: I2f85576389fe4f0437f81799c14dfd98c8c40b2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103129 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann2-2/+4
...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-16sw: remove dead code in lcl_FillBookmarkArray()Michael Stahl1-36/+17
Change-Id: Idb9fbac5bd1c74f8ccd434a2337daea58b624e57 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102738 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-09-15sw: don't throw if disposed in SwXRedlinePortion::getPropertyValue()Michael Stahl1-4/+9
No other SwXTextPortion method does that, so avoid it here for consistency, just return void. Change-Id: Iae9b6b12e21609e315a9f269feb0703657bbf3cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102691 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-09-07tdf#135665 DOCX: import tight wrap setting of VML shapesDaniel Arato (NISZ)1-2/+6
The wrap setting that OOXML calls "tight" and LibreOffice calls "contour" (== true) was not supported by the import code, only the export. Change-Id: I48739ffaad48e28df05fd87a9b51a14238dc47e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101932 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-03tdf#136423 make SwXDrawPage::group work with a single shapeSamuel Mehrbrodt1-1/+1
No reason this should not work (and the implementation in Draw/Impress/Calc also works this way) Change-Id: Ic5bc7420e9025b45ed848dccf68b112c0c6c2cd5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101842 Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-09-02Improve exception when shape with illegal anchor is givenSamuel Mehrbrodt1-1/+3
Change-Id: I24cb57b39511db3523f776463a832513a1aae0d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101843 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-08-28tdf#131801: sw: support of style references in ListAutoFormatVasily Melenchuk1-1/+10
ListAutoFormat property did support char attributes, but not style references ("CharStyleName"). It is important for correct formatting of pilcrow symbol or list format in some DOCX scenarios. Export to DOCX already works, but not to RTF/DOC. Change-Id: I1bf23d1e45fcc213adcf9aa6f404be803919fbee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100893 Tested-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann6-1713/+1713
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-21Fix typosAndrea Gelmini2-2/+2
Change-Id: Iaf1d4aed07d1e6fcfe2392fb65cbd2fa196bcc1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101099 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-17sw: prefix members of SwNode2LayImpl, SwRetrievedInputStreamDataManager, ...Miklos Vajna1-139/+139
... SwXDrawPage and SwXShape See tdf#94879 for motivation. Change-Id: I0cfdc1a1b7e1667dccf8db29616b895a76b8fea5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100843 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-13use OUStringLiteral in SfxItemPropertyMapEntryNoel Grandin5-1721/+1721
Change-Id: I4f05b6a35010e661ea77f3e4b83302d2ec74d227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100405 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-12sw: prefix members of SwFmDrawPage, SwNumRule, SwTableAutoFormat and ...Miklos Vajna1-6/+6
... WriterSpecificAutoFormatBlock See tdf#94879 for motivation. Change-Id: Ie740f07e1c65a6def6ba673529144d0e111b056e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100610 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-06tdf#135464 sw: ODT->DOCX: fix positioning of at-page shapes and framesMichael Stahl2-0/+28
Exporting at-page anchored flys to DOCX can result in wrong positions, because DocxSdrExport::startDMLAnchorInline() converts text::RelOrientation::FRAME to relativeFrom="column", i.e. the margin, but sw displays it as relative to the page. In fact at-page and FRAME is an invalid combination according to the table in ODF 1.3, 20.298 style:horizontal-pos, the paragraph and character relations are not valid for page-anchored flys. Since there are lots of ODT files with this invalid combination, try to fix it on import, in SwXFrame and SwXShape. Funnily, SwXShape is attached before the properties are set, while SwXFrame is attached after the properties are set. The anchor frame for at-page is always a SwPageFrame. Unfortunately there is a case where PRINT_AREA and PAGE_PRINT_AREA differ, namely the CalcClipRect() only handles PRINT_AREA so it will crop to the right margin with that but not with PAGE_PRINT_AREA, so don't map this value. Change-Id: I4d5f7f87d045ac4539b9170e55c34d4afe801f4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100130 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-08-04loplugin:simplifybool a little more aggressiveNoel Grandin1-1/+1
with expressions like !(a && b) Change-Id: Id2acec2a8d0eaaa8e5e37dbd2cae7281be36572e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100040 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-03tdf#42949 Fix IWYU warnings in include/[t-x]*/*hxxGabor Kelemen3-0/+3
Recheck after 7-0 branchoff Also drop the now unused file include/vcl/field.hxx Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I9e54c82f50d1e02a0f99858939cac999fc66f7de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99261 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-07-31loplugin:flatten in sw/core/unocoreNoel Grandin16-1332/+1331
Change-Id: If96b2484426f0d09119ca89943729c149675156f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99851 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-30tdf#38093 Writer outline folding - persistenceJim Raykowski2-1/+3
Patch 6/6 that breaks down https://gerrit.libreoffice.org/c/core/+/96672 Adds persistence attribute loext:outline-content-visible Change-Id: Ide3eeee0f127a05def4d4f493bb4b469e0877b00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99657 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-07-23Silence GCC 11 trunk -Werror=nonnull involving dynamic_castStephan Bergmann1-2/+2
...where the compiler now warns that the implicit this pointer argument could be null in a member function call made via a dynamic_cast-converted pointer (and where the code apparently relies on the dynamic_cast not to fail) Change-Id: I79482f4a853b6b47c5f9dd099a4e8377a19f7b0d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99219 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-17sw: fix crash when using anchor of at-paragraph fly ...Michael Stahl2-2/+16
... to insert fieldmark; the problem is that the anchor doesn't have SwIndex so the resulting sw::mark::Fieldmark's positions won't have SwIndex either, so they aren't updated when its dummy chars are inserted in lcl_SetFieldMarks(). Change-Id: Id6281f45aa1f1337f1ae599877f155b129389d81 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98852 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-07-14tdf#133437: sw: set generated shape name if it is missingVasily Melenchuk1-8/+7
Shape names are required for seting format name and undo/redo and correct displaying of objects in Navigator pane Change-Id: I43caf6a4d5f054283d48c46b081d43b743bd4433 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98312 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-13sw: prefix members of SwUndoField, SwUndoFieldFromAPI, ...Miklos Vajna1-17/+17
... SwUndoFieldFromDoc and SwXFrame See tdf#94879 for motivation. Change-Id: Iedf3b8d71f787036b29d0ed269e4d4d614128db9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98616 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-07-07Typo: pargraph->paragraphJulien Nabet1-1/+1
Change-Id: I7749951d829eb8aaeacdca0fd66d41cf9d6a1613 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98251 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-07-03SwTOXMark::InsertTOXMarks: SwIterator no more ...Bjoern Michaelsen1-1/+1
- remove manual SwIterator usage - moved SwTOXMark from ::Modify to ::SwClientNotify - replaced static InsertTOXMarks() with SwTOXType::CollectTextMarks() where it belongs Change-Id: Ib8289c07882a61278dedb1bc1fadc1a9237fea4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97663 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
2020-07-02Upcoming improved loplugin:staticanonymous -> redundantstatic: swStephan Bergmann6-12/+12
Change-Id: Id4e6e18b1fce848972e67ca519cbf23eab7cd109 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97701 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-27cid#1464974: Null pointer dereferences (sw/unosett)Julien Nabet1-2/+2
Change-Id: I4ea6de59ce1d1cb3133b0fb57176caee5497878f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97276 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-06-23tdf#119081 sw: fix RTF paste into outer table cellMiklos Vajna1-2/+1
Regression from commit ed654c4aa7f9f10fcb16127349009bc0c38b12e8 (Revert "fdo#43869 use the old rtf importer for paste", 2012-11-30), the direct problem is that SwXText::insertTextPortion() is now used by writerfilter, so in case it's not as good as the internal API used by the old RTF filter, we have a problem. This function calls SwXCell::CreateCursor(), which calls SwXCell::createTextCursor(), which uses Move() to go to the first content node in the cell, but that means we end up at the inner cell's XText for an outer cell. So later when we want to go to the end of the outer cell, we can't, as that would be a different XText and we throw an exception. Fix the problem by instead using createTextCursorByRange(), which immediately positions the cursor at the insert position, so the XText will be correct. FWIW, the ODF import at SwXMLImport::setTextInsertMode() also uses createTextCursorByRange() to handle this situation. Change-Id: I1db13b860bc60771d98c2b4099be73f4bf41c375 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96901 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-06-10loplugin:buriedassign in swNoel Grandin1-3/+6
limited this only fixing assignments inside "if" statements, since other things are harder to change Change-Id: If3188a3e3d5fcd94123211c97fee097ece5e2797 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95990 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-29loplugin:simplifybool in swNoel Grandin3-4/+4
Change-Id: Ib842d5a768806fc41a66802908acc8679cf7a985 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95107 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-26Fix loplugin:simplifypointertobool for libstdc++ std::shared_ptrStephan Bergmann2-4/+4
...where the get member function is defined on a std::__shared_ptr base class, so loplugin:simplifypointertobool used to miss those until now. (While e.g. using libc++ on macOS found those cases.) 366d08f2f6d4de922f6099c62bb81b49d89e0a68 "new loplugin:simplifypointertobool" was mistaken in breaking isSmartPointerType(const clang::Type* t) out of isSmartPointerType(const Expr* e); c874294ad9fb178df47c66875bfbdec466e39763 "Fix detection of std::unique_ptr/shared_ptr in loplugin:redundantpointerops" had introduced that indivisible two-step algorithm on purpose. The amount of additional hits (on Linux) apparently asked for turning loplugin:simplifypointertobool into a rewriting plugin. Which in turn showed that the naive adivce to just "drop the get()" is not sufficient in places that are not contextually converted to bool, as those places need to be wrapped in a bool(...) functional cast now. If the expression was already wrapped in parentheses, those could be reused as part of the functional cast, but implementing that showed that such cases are not yet found at all by the existing loplugin:simplifypointertobool. Lets leave that TODO for another commit. Besides the changes to compilerplugins/ itself, this change has been generated fully automatically with the rewriting plugin on Linux. Change-Id: I83107d6f634fc9ac232986f49044d7017df83e2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94888 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-05-21use for-range on Sequence in sfx2..swNoel Grandin1-5/+5
Change-Id: I09806869f2fdbae61f4c5d5c9db6859202bb63b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94609 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-19 16:09:30 +0000