/o3tl/

name='h' onchange='this.form.submit();'> LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/sw/source/core/layout/objectformattertxtfrm.cxx
AgeCommit message (Collapse)Author
2024-10-28crashtesting: crash on loading ooo71160-2.docCaolán McNamara
since: commit 2d6addb180ad30383f4aaec198c22ccbf936fa87 CommitDate: Mon Oct 21 15:16:57 2024 +0200 tdf#163486 sw: PVS: identical sub-expressions Change-Id: I601a72a8a39f3591d1110f65a027e89923befaca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175702 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-10-21tdf#163486 sw: PVS: identical sub-expressionsMichael Stahl
Copypasta in commit c799de145f7e289f31e3669646e5bd12814e6c5e, we want to compare the rows where the 2 objects are anchored. Change-Id: Ifdf267b8d70d6410ce50a507783d284ac128c1aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175326 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins
2024-09-16cid#1607161 Overflowed constantCaolán McNamara
make this an assert, it will crash and burn anyway if its not > 0 Change-Id: Id4780efbae45e984a162df182c3297536546bf04 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173425 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-05-04WaE: C6011 Dereferencing NULL pointer warningsCaolán McNamara
Change-Id: I68acd56b28b0f989a4010cd939f2452970d158ff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167103 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-29tdf#154863 Fix crashes when moving images in a large documentMatt K
The problem is that when moving images around the code tries to do things with anchored text frames that have already gone through destruction. The fix is to check if those frames have the destruction bit set before using them, thus avoiding the crashes. Also, there is an assert that was firing and removing it seems to have no negative effect in interacting with the file. Change-Id: I899171ef3b5113f479725b0421f469c36e40e26c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162151 Reviewed-by: Matt K <mattkse@gmail.com> Tested-by: Matt K <mattkse@gmail.com>
2024-01-14Let SwAnchoredObject::GetFrameFormat return pointer, and drop HasFrameFormatMike Kaganski
In commit 19062c98da5b2e9edc7a99068fa06a83c7578826, it was important to check if objects have frame format before using GetFrameFormat. Thic change makes it simpler amd more obvious. Also, it allows to avoid two calls to GetUserCall, by obtaining the pointer once and checking it. Change-Id: I980fcba9e369e107f3d062e8cab0a34e02384290 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162044 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-04-27forcepoint#93 fix crash on layout of specific rtfCaolán McNamara
Change-Id: Id81729de2efd6f65f1b51bdb437ca21a260eaf6e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132143 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-28Recheck sw/ cxx files with IWYUGabor Kelemen
See tdf#42949 for motivation Change-Id: I8a8df68946297fad517b753d73e4373203a45ed6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132150 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-03-02sw: oops forgot to remove this commentMichael Stahl
Change-Id: I1e12def63a6353a9eab3f073ef35ba305ff32649 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130829 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-03-02sw: really prevent footnote frame against delete while it's movedMichael Stahl
This reverts commit fe5d3fbfe63fe8b433776bd3a0508dd712b868b0 It turns out that checking a single column's IsMovingFootnotes() is not enough - as frames can move both forwards and backwards the entire chain of columns would need to be checked. (Most callers of MoveLowerFootnotes() move forwards, but one place in tabfrm.cxx moves from a follow to master.) But it turns out that this is probably the wrong way in any case: most likely the intention in FormatAnchorFrameAndItsPrevs() is to format previous frames in the same layout environment, so if there is a section or column inside a footnote then this upper should be formatted, while if the footnote is inside a section or column this upper should not be formatted; this should make calls during MoveFootnotes_() safe as it should prevent the formatting of frames in the footnote boss moving a footnote that is already being moved. So tweak the fix in commit fa1bcc22921941b2cd8a0b32fe0d15655d12d607 a little to make it more general. Also it was previously possible that for a section with columns, both the section branch and the column branch was taken, which seems supperfluous. Change-Id: I39487640322339fe4d511e845d9c6bced2ba9dad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130544 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-02-24sw: prevent footnote frame against delete while it's movedMichael Stahl
Change-Id: Ifebe53956ca0a7d3653469256c895a666cfffbf8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130439 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-07-16Only change SwLayAction::m_bAgain via SetAgainCaolán McNamara
no logic change intended Change-Id: Ib0174f8040faa3efde7b9c5ba9b062bac5a35da3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118983 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-05-07tdf#138518 sw: layout: unbreak fdo80206-1.docMichael Stahl
The 7 flys on the para on page 3 create ~15 extra pages with one paragraph each. Argh! One of the bPageHasFlysAnchoredBelowThis checks was inverted. How dumb of me. (regression from c799de145f7e289f31e3669646e5bd12814e6c5e) Still doesn't look good but now it looks same as in 7.0. Change-Id: Ib10c46f48746362d8d679c147ddc8b85157be508 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115242 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins
2021-05-07tdf#138518 sw: layout: fix assert on ooo43913-1.docMichael Stahl
Assertion `rAnchoredObjPage.GetPhyPageNum() == _nFromPageNum' failed. Because not only the fly's anchor frame moves forward in FormatAnchorFrameForCheckMoveFwd(), but also the fly itself, apparently because it's in a table: 0 SwAnchoredObject::SetPageFrame(SwPageFrame*) (this=0x5a1d3d8, _pNewPageFrame=0x8cfbeb0) at sw/source/core/layout/anchoredobject.cxx:162 1 SwPageFrame::MoveFly(SwFlyFrame*, SwPageFrame*) (this=0x8cbd8c0, pToMove=0x5a1d280, pDest=0x8cfbeb0) at sw/source/core/layout/flylay.cxx:985 2 lcl_ArrangeLowers(SwLayoutFrame*, tools::Long, bool) (pLay=0x8cf80c0, lYStart=179488, bInva=false) at sw/source/core/layout/tabfrm.cxx:5000 3 SwCellFrame::Format(OutputDevice*, SwBorderAttrs const*) (this=0x8cf80c0, pAttrs=0x8ce78c0) at sw/source/core/layout/tabfrm.cxx:5359 4 SwLayoutFrame::MakeAll(OutputDevice*) (this=0x8cf80c0) at sw/source/core/layout/calcmove.cxx:1036 5 SwFrame::PrepareMake(OutputDevice*) (this=0x8cf80c0, pRenderContext=0x5b7fcf0) at sw/source/core/layout/calcmove.cxx:375 6 SwFrame::Calc(OutputDevice*) const (this=0x8cf80c0, pRenderContext=0x5b7fcf0) at sw/source/core/layout/trvlfrm.cxx:1792 7 SwFrame::MakePos() (this=0x8cebdb0) at sw/source/core/layout/calcmove.cxx:627 8 SwTextFrame::MakePos() (this=0x8cebdb0) at sw/source/core/text/frmform.cxx:340 9 SwContentFrame::MakeAll(OutputDevice*) (this=0x8cebdb0) at sw/source/core/layout/calcmove.cxx:1412 10 SwFrame::PrepareMake(OutputDevice*) (this=0x8cebdb0, pRenderContext=0x5b7fcf0) at sw/source/core/layout/calcmove.cxx:286 11 SwFrame::Calc(OutputDevice*) const (this=0x8cebdb0, pRenderContext=0x5b7fcf0) at sw/source/core/layout/trvlfrm.cxx:1792 12 SwTextFrame::CalcFollow(o3tl::strong_int<int, Tag_TextFrameIndex>) (this=0x5ae2c60, nTextOfst=...) at sw/source/core/text/frmform.cxx:279 13 SwTextFrame::AdjustFollow_(SwTextFormatter&, o3tl::strong_int<int, Tag_TextFrameIndex>, o3tl::strong_int<int, Tag_TextFrameIndex>, unsigned char) (this=0x5ae2c60, rLine=..., nOffset=..., nEnd=..., nMode=1 '\001') at sw/source/core/text/frmform.cxx:611 14 SwTextFrame::FormatAdjust(SwTextFormatter&, WidowsAndOrphans&, o3tl::strong_int<int, Tag_TextFrameIndex>, bool) (this=0x5ae2c60, rLine=..., rFrameBreak=..., nStrLen=..., bDummy=false) at sw/source/core/text/frmform.cxx:1166 15 SwTextFrame::Format_(SwTextFormatter&, SwTextFormatInfo&, bool) (this=0x5ae2c60, rLine=..., rInf=..., bAdjust=false) at sw/source/core/text/frmform.cxx:1613 16 SwTextFrame::Format_(OutputDevice*, SwParaPortion*) (this=0x5ae2c60, pRenderContext=0x5b7fcf0, pPara=0x8d07490) at sw/source/core/text/frmform.cxx:1720 17 SwTextFrame::Format(OutputDevice*, SwBorderAttrs const*) (this=0x5ae2c60, pRenderContext=0x5b7fcf0) at sw/source/core/text/frmform.cxx:1910 18 SwContentFrame::MakeAll(OutputDevice*) (this=0x5ae2c60) at sw/source/core/layout/calcmove.cxx:1525 19 SwFrame::PrepareMake(OutputDevice*) (this=0x5ae2f80, pRenderContext=0x5b7fcf0) at sw/source/core/layout/calcmove.cxx:321 20 SwFrame::Calc(OutputDevice*) const (this=0x5ae2f80, pRenderContext=0x5b7fcf0) at sw/source/core/layout/trvlfrm.cxx:1792 21 SwObjectFormatterTextFrame::FormatAnchorFrameAndItsPrevs(SwTextFrame&) (_rAnchorTextFrame=...) at sw/source/core/layout/objectformattertxtfrm.cxx:905 22 SwObjectFormatterTextFrame::FormatAnchorFrameForCheckMoveFwd() (this=0x8ce5720) at sw/source/core/layout/objectformattertxtfrm.cxx:919 23 SwObjectFormatterTextFrame::DoFormatObjs() (this=0x8ce5720) at sw/source/core/layout/objectformattertxtfrm.cxx:368 24 SwObjectFormatter::FormatObjsAtFrame(SwFrame&, SwPageFrame const&, SwLayAction*) (_rAnchorFrame=..., _rPageFrame=..., _pLayAction=0x0) at sw/source/core/layout/objectformatter.cxx:160 25 SwContentFrame::CalcLowers(SwLayoutFrame&, SwLayoutFrame const&, long, bool) (rLay=..., rDontLeave=..., nBottom=192048, bSkipRowSpanCells=true) at sw/source/core/layout/tabfrm.cxx:1534 26 lcl_RecalcRow(SwRowFrame&, tools::Long) (rRow=..., nBottom=192048) at sw/source/core/layout/tabfrm.cxx:1653 27 SwTabFrame::MakeAll(OutputDevice*) (this=0x8cf5f80, pRenderContext=0x5b7fcf0) at sw/source/core/layout/tabfrm.cxx:2425 It looks like the _nFromPageNum is always from the SwObjectFormatter::mrPageFrame anyway because that's a precondition of the mpPgNumAndTypeOfAnchors->Collect() being called, so just rely on that to get the correct page. (regression from c799de145f7e289f31e3669646e5bd12814e6c5e) Change-Id: Ibdffb2121cffbc04320d17a29ab2e160dec4250b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115188 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-04-22tdf#138518 sw: layout: avoid moving flys forward prematurelyMichael Stahl
(regression from b9ef71476fd70bc13f50ebe80390e0730d1b7afb "tdf#134298 sw: layout: remove left-over page frame without content") When updating the 3rd ToX, the change to remove empty page frames causes one page frame to be deleted. On the subsequent layout, things generally move backward, but there are some fly-related hiccups; the first problem is visible on page 7. Commit eb85de8e6b61fb3fcb6c03ae0145f7fe5478bccf "sw: layout: if fly's anchor moves forward, move fly off SwPageFrame" helps quite a bit, but not completely; now the first problem happens on page 54, when SwTextFrame 1261 and its fly 3132 are formatted. Frame 1261 moves forward to page 55, and then SwObjectFormatterTextFrame::CheckMovedFwdCondition() returns true and so SwMovedFwdFramesByObjPos::Insert() is called to prevent frame 1261 from moving back to page 54. But the reason why it moved forward is that there are 3 flys on page 54 that are anchored on frames in the next-chain of 1261, namely 1275, 1283 and 1284; if these flys weren't on the page then 1261 would fit. While the move forward cannot be easily prevented in the situation, it's possible to avoid the entry into the SwMovedFwdFramesByObjPos map, by detecting that there are flys on the page that would should forward *before* the current one does. With this fix and the above mentioned commit to get the flys off the page, frame 1261 will eventually move back to page 54 again. Change-Id: I83e44d65a0b889a49a313b0cd8b08efce4c3afa7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114478 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-03-26loplugin:flattenNoel
Change-Id: Ib7a895fba66f8dc9b6501e61631c02694053b7fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113157 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-03-16tdf#122894 skipping anchor in column in footnoteCaolán McNamara
a trawl of crash testing document didn't show up another example and it doesn't seem possible to create this scenario directly in out UI Change-Id: Ie65a51bf609e8bacd261f368f0b8037431c116ed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112567 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-26tdf#135198 tdf#138050 sw editing: fix text box position syncDaniel Arato (NISZ)
Follow-up to commit c9eb53f200225f2ee6ca695e1326843a487aee51 (tdf#135198 sw editing: text box fell out of its shape) Every time a shape is repositioned, make sure the text box inside the shape follows the shape. The previous solution to this bug, the one implemented in SwObjectFormatterTextFrame::DoFormatObjs, was a little more cumbersome. This one should produce fewer regressions, I hope. Change-Id: I3e88eb8616cd299cabb7b74b188ab7220746ec89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106421 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-11-24tdf#42949 Fix new IWYU warnings in directory swGabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I4bb84c3f401aba8a3dede9cec3a7f2187a2ba02a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106473 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-14Revert "tdf#137881 sw: fix text box size regression"Xisco Fauli
This reverts commit f2eef84ff03660cbb46a76c317e640e054ed0a56. Reason for revert: https://bugs.documentfoundation.org/show_bug.cgi?id=135198#c9 This also reverts part of 768cfcee178b284be6d96d384364e59e40ecb375 without breaking tdf#137960 nor tdf#137964 Change-Id: Ifa418e66b8a45c6204babfae6513ca67aed93289 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105545 Reviewed-by: Dániel Arató <arato.daniel@nisz.hu> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-11-12tdf#137960 tdf#137964 sw: fix Shift-ArrowKey text box movementDaniel Arato (NISZ)
A text box and its including shape are now going to keep their positions in sync along the horizontal (X) axis as well as the vertical (Y) axis. Moreover, Shift-UpArrow, Shift-DownArrow, Shift-LeftArrow and Shift-RightArrow are all going to work the same as the plain arrow keys, they are just going to move the text a larger distance. Change-Id: I49482a101d97927715f47efbf0f58808ea6a8547 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105328 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-11-09tdf#137881 sw: fix text box size regressionDaniel Arato (NISZ)
from commit c9eb53f200225f2ee6ca695e1326843a487aee51 (tdf#135198 sw editing: text box fell out of its shape). The height of the bottom text box frame from the tdf#117921 sample file grew unreasonably large. This is countered by only activating the previous fix if it is strictly needed, i.e. when a shape and its text box drift apart from each other. The test file is derived from the one used for tdf#117921. Change-Id: Ied01c6089efe586b73de559f89f08b958f4b62d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105238 Tested-by: László Németh <nemeth@numbertext.org> Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-11-03extract cleanup piece to its own functionCaolán McNamara
this is from a failed campaign against tdf#122894 Change-Id: I639d65394cadca6ca70613dfd13691fd7b5f5104 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105191 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-30crashtesting: assert on undo creation on export of tdf105134-1.docx to pdfCaolán McNamara
since... commit c9eb53f200225f2ee6ca695e1326843a487aee51 (HEAD, refs/bisect/bad) Date: Wed Oct 14 15:46:23 2020 +0200 tdf#135198 sw editing: text box fell out of its shape I don't think layout should add into the undo stack Change-Id: I92e154dbe2396ff4085fffd7e962e43d2c61c073 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105045 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-27tdf#135198 sw editing: text box fell out of its shapeDaniel Arato (NISZ)
Without this patch if a shape anchored to a paragraph and containing a text box was moved upwards beyond the vertical position of its anchor, the text box failed to keep its position in sync with the shape. This is fixed by telling the text box the absolute vertical position of the corresponding shape after the latter is moved. Note: Other fix is associated to the shortcut keys Shift-Arrow Up/Shift-Arrow Down for moving text frames with bigger steps vertically. Now it's not possible to use these keys, but that was bad with text boxes, because it moved only the text content of the text box. Note: this patch fixes the vertical position of the text box of textbox-wps-only.docx of the unit test textboxWpsOnly. Change-Id: Ib66b13cae455462c616fed6bbd088433c83e61a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104520 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-10crashtesting: assert the condition making tdf122894-1.doc crashCaolán McNamara
sometimes it doesn't happen to crash, but its always dereferencing a deleted frame Change-Id: I056808398c97c5de12542c6c342e7d9d7e5195d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102334 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-01loplugin:flatten in sw/core/layoutNoel Grandin
Change-Id: I67fd1a269d960174b88c57da4a0588f5d9252660 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99885 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-04rename GetOfst -> GetOffsetNoel Grandin
Change-Id: I9c0968bd93f41f983468ee7ba8a20e27c4866b32 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87954 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-08Fix typoAndrea Gelmini
Change-Id: I4e4a1b24d6b19ab62d9f0d73bcd74492bc955beb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86379 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-22Extend loplugin:external to warn about classesStephan Bergmann
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-14tdf#42949 Fix IWYU warnings in sw/source/core/[e-l]*/*cxxGabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I173b3aaca84a707799f0ee78cddcbd70524897bc Reviewed-on: https://gerrit.libreoffice.org/82561 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-07-21crashtesting: failures on swfootnoteframe_colunlock_heap_use_after_free.sampleCaolán McNamara
undo forcepoint80 hackery and try a different solution Change-Id: I52b5f9b41074e122bd32e70967e198ce9f86aec7 Reviewed-on: https://gerrit.libreoffice.org/76072 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-10-10forcepoint#74 crash in layoutCaolán McNamara
Change-Id: Iad5770b512d7c49483ac823aa4f51212f281bbca Reviewed-on: https://gerrit.libreoffice.org/61628 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-09-12loplugin:useuniqueptr in SwObjectFormatterNoel Grandin
Change-Id: I549173b942de19eb3ff1e74fdee6e72de720988f Reviewed-on: https://gerrit.libreoffice.org/60373 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-06-08sw_redlinehide: trivial conversions in layout/Michael Stahl
Change-Id: I5ce4590af52b3bfc08f89915999e86f4973fa9e3
2017-10-31RotateFlyFrame2: Unified FrameAreaDefinitionArmin Le Grand
Isolated all Frame AreaDefinition and it's layout flags to SwFrameAreaDefinition class which is now base for SwFrame. Adapted calls to get/set and WriteAccess hekper classes accordingly. This allows much deeper understanding what Writer is doing when layouting it's frames and needed when reaction on such changes is necessary Change-Id: I96220a1d140e69c76cc63023aae26e4ed17f3504
2017-10-07sw: always use "" for includes in current source's directoryMike Kaganski
Change-Id: Ida715fad0c4587a9566184180bf159da12470dd7 Reviewed-on: https://gerrit.libreoffice.org/43207 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-08-17remove UL/L suffixes from integer constants on the RHS of expressionsNoel Grandin
Change-Id: I899a8126c9d971601fea6c77eca165718aea0ac5 Reviewed-on: https://gerrit.libreoffice.org/41237 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-08-17remove UL/L suffixes from integer constants in initialiser/call expressionsNoel Grandin
Change-Id: Iae081567c4fa5b88edbd12cf2fbafd2b8f31b300 Reviewed-on: https://gerrit.libreoffice.org/41214 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-22tdf#101821 sw: fix layout footnote use-after-freeMichael Stahl
After inserting a header in the bugdoc, during SwFrame::Calc of a SwTextFrame that is in a footnote, it decides move forward to the next page. This deletes the SwFootnoteFrame and SwFootnoteContFrame that lcl_FormatContentOfLayoutFrame() are iterating over. For want of a more elegant solution, use a big hammer to prevent the problem and try to clean up so that no empty SwFootnoteFrame and SwFootnoteContFrame remain (as that is known to crash in other places, see commit c9fb347642729017ad0c613fe26310befd021db8) Invalid read of size 8 at 0x414E1F96: SwFrame::GetNext() (frame.hxx:485) by 0x41AFDD07: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:646) by 0x41AFDCC0: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:642) by 0x41AFDCC0: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:642) by 0x41AFDEA7: SwObjectFormatterTextFrame::FormatAnchorFrameAndItsPrevs(SwTextFrame&) (objectformattertxtfrm.cxx:696) by 0x41AAA680: SwFlyAtContentFrame::MakeAll(OutputDevice*) (flycnt.cxx:415) by 0x41A7F211: SwFrame::PrepareMake(OutputDevice*) (calcmove.cxx:346) by 0x41B75758: SwFrame::Calc(OutputDevice*) const (trvlfrm.cxx:1761) by 0x41AA8927: SwFlyFrame::Calc(OutputDevice*) const (fly.cxx:2559) by 0x41ADB36B: SwLayAction::FormatLayoutFly(SwFlyFrame*) (layact.cxx:1414) by 0x41AF9658: SwObjectFormatter::FormatObj_(SwAnchoredObject&) (objectformatter.cxx:321) by 0x41AFCB6E: SwObjectFormatterTextFrame::DoFormatObj(SwAnchoredObject&, bool) (objectformattertxtfrm.cxx:126) by 0x41AF9A6A: SwObjectFormatter::FormatObjsAtFrame_(SwTextFrame*) (objectformatter.cxx:443) by 0x41AFD275: SwObjectFormatterTextFrame::DoFormatObjs() (objectformattertxtfrm.cxx:328) by 0x41AF924A: SwObjectFormatter::FormatObjsAtFrame(SwFrame&, SwPageFrame const&, SwLayAction*) (objectformatter.cxx:191) by 0x41ADC213: SwLayAction::FormatContent(SwPageFrame const*) (layact.cxx:1633) by 0x41AD88DE: SwLayAction::InternalAction(OutputDevice*) (layact.cxx:760) by 0x41AD7080: SwLayAction::Action(OutputDevice*) (layact.cxx:351) by 0x41ADE32E: SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*) (layact.cxx:2133) by 0x41FFC97E: SwViewShell::LayoutIdle() (viewsh.cxx:711) Address 0x505541a8 is 72 bytes inside a block of size 272 free'd at 0x4C2F21A: operator delete(void*) (vg_replace_malloc.c:576) by 0x41AD371A: SwFootnoteFrame::~SwFootnoteFrame() (ftnfrm.hxx:52) by 0x41B5B74C: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:391) by 0x41A97294: SwFlowFrame::CutTree(SwFrame*) (flowfrm.cxx:406) by 0x41A979AE: SwFlowFrame::MoveSubTree(SwLayoutFrame*, SwFrame*) (flowfrm.cxx:592) by 0x41ACFB69: SwContentFrame::MoveFootnoteCntFwd(bool, SwFootnoteBossFrame*) (ftnfrm.cxx:2756) by 0x41A9B78E: SwFlowFrame::MoveFwd(bool, bool, bool) (flowfrm.cxx:1813) by 0x41A85864: SwContentFrame::MakeAll(OutputDevice*) (calcmove.cxx:1681) by 0x41A7F211: SwFrame::PrepareMake(OutputDevice*) (calcmove.cxx:346) by 0x41B75758: SwFrame::Calc(OutputDevice*) const (trvlfrm.cxx:1761) by 0x41AFDCFB: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:644) by 0x41AFDCC0: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:642) by 0x41AFDCC0: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:642) by 0x41AFDCC0: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:642) by 0x41AFDEA7: SwObjectFormatterTextFrame::FormatAnchorFrameAndItsPrevs(SwTextFrame&) (objectformattertxtfrm.cxx:696) by 0x41AAA680: SwFlyAtContentFrame::MakeAll(OutputDevice*) (flycnt.cxx:415) by 0x41A7F211: SwFrame::PrepareMake(OutputDevice*) (calcmove.cxx:346) by 0x41B75758: SwFrame::Calc(OutputDevice*) const (trvlfrm.cxx:1761) by 0x41AA8927: SwFlyFrame::Calc(OutputDevice*) const (fly.cxx:2559) by 0x41ADB36B: SwLayAction::FormatLayoutFly(SwFlyFrame*) (layact.cxx:1414) by 0x41AF9658: SwObjectFormatter::FormatObj_(SwAnchoredObject&) (objectformatter.cxx:321) by 0x41AFCB6E: SwObjectFormatterTextFrame::DoFormatObj(SwAnchoredObject&, bool) (objectformattertxtfrm.cxx:126) by 0x41AF9A6A: SwObjectFormatter::FormatObjsAtFrame_(SwTextFrame*) (objectformatter.cxx:443) by 0x41AFD275: SwObjectFormatterTextFrame::DoFormatObjs() (objectformattertxtfrm.cxx:328) by 0x41AF924A: SwObjectFormatter::FormatObjsAtFrame(SwFrame&, SwPageFrame const&, SwLayAction*) (objectformatter.cxx:191) by 0x41ADC213: SwLayAction::FormatContent(SwPageFrame const*) (layact.cxx:1633) by 0x41AD88DE: SwLayAction::InternalAction(OutputDevice*) (layact.cxx:760) by 0x41AD7080: SwLayAction::Action(OutputDevice*) (layact.cxx:351) by 0x41ADE32E: SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*) (layact.cxx:2133) by 0x41FFC97E: SwViewShell::LayoutIdle() (viewsh.cxx:711) Change-Id: I656cc2303eeccd5eef68ad3b8e81bb0fd47b94fb
2017-03-20convert RndStdIds to scoped enumNoel Grandin
Change-Id: I029ad67dfcbc40f3953adf485957efcbd97f23d0 Reviewed-on: https://gerrit.libreoffice.org/35328 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-03-11Fix typosAndrea Gelmini
Change-Id: I8afde16343288888d9b1806fae6cba3514812d02 Reviewed-on: https://gerrit.libreoffice.org/35062 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>